- 25 Sep, 2020 27 commits
-
-
Yufeng Mo authored
In hns3_process_hw_error(), the hardware error detection of the ROCEE AXI RESP error type is added. When this error occurs, the client needs to be notified of this error and take corresponding operation. Signed-off-by:
Yufeng Mo <moyufeng@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Yufeng Mo authored
If a variable is assigned a value before it is used, it's no need to assign an initial value to the variable. So remove these redundant operations. Signed-off-by:
-
Yufeng Mo authored
Remove some unnecessary parameters of hclge_title_idx_print(), and rename this function for readability. Signed-off-by:
-
Florian Westphal authored
Since commit cfde141e ("mptcp: move option parsing into mptcp_incoming_options()"), the 3rd function argument is no longer used. Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
David S. Miller authored
Geliang Tang says: ==================== mptcp: RM_ADDR/ADD_ADDR enhancements This series include two enhancements for the MPTCP path management, namely RM_ADDR support and ADD_ADDR echo support, as specified by RFC sections 3.4.1 and 3.4.2. 1 RM_ADDR support include 9 patches (1-3 and 8-13): Patch 1 is the helper for patch 2, these two patches add the RM_ADDR outgoing functions, which are derived from ADD_ADDR's corresponding functions. Patch 3 adds the RM_ADDR incoming logic, when RM_ADDR suboption is received, close the subflow matching the rm_id, and update PM counter. Patch 8 is the main remove routine. When the PM netlink removes an address, we traverse all the existing msk sockets to find the relevant sockets. Then trigger the RM_ADDR signal and remove the subflow which using this local address, this subflow removing functions has been implemented in patch 9. Finally, patches 10-13 are the self-tests for RM_ADDR. 2 ADD_ADDR echo support include 7 patches (4-7 and 14-16). Patch 4 adds the ADD_ADDR echo logic, when the ADD_ADDR suboption has been received, send out the same ADD_ADDR suboption with echo-flag, and no HMAC included. Patches 5 and 6 are the self-tests for ADD_ADDR echo. Patch 7 is a little cleaning up. Patch 14 and 15 are the helpers for patch 16. These three patches add the ADD_ADDR retransmition when no ADD_ADDR echo is received. ==================== Signed-off-by: -
Geliang Tang authored
This patch implemented the retransmition of ADD_ADDR when no ADD_ADDR echo is received. It added a timer with the announced address. When timeout occurs, ADD_ADDR will be retransmitted. Suggested-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Suggested-by:
Paolo Abeni <pabeni@redhat.com> Acked-by:
Geliang Tang <geliangtang@gmail.com> Reviewed-by:
-
Geliang Tang authored
This patch added a new helper sk_stop_timer_sync, it deactivates a timer like sk_stop_timer, but waits for the handler to finish. Acked-by:
-
Geliang Tang authored
Add a new struct mptcp_pm_add_entry to describe add_addr's entry. Acked-by:
-
Geliang Tang authored
This patch added the remove addr and subflow test cases and two new functions. The first function run_remove_tests calls do_transfer with two new arguments, rm_nr_ns1 and rm_nr_ns2, for the numbers of addresses should be removed during the transfer process in namespace 1 and namespace 2. If both these two arguments are 0, we do the join test cases with "mptcp_connect -j" command. Otherwise, do the remove test cases with "mptcp_connect -r" command. The second function chk_rm_nr checks the RM_ADDR related mibs's counters. The output of the test cases looks like this: 11 remove single subflow syn[ ok ] - synack[ ok ] - ack[ ok ] rm [ ok ] - sf [ ok ] 12 remove multiple subflows syn[ ok ] - synack[ ok ] - ack[ ok ] rm [ ok ] - sf [ ok ] 13 remove single address syn[ ok ] - synack[ ok ] - ack[ ok ] add[ ok ] - echo [ ok ] rm [ ok ] - sf [ ok ] 14 remove subflow and signal syn[ ok ] - synack[ ok ] - ack[ ok ] add[ ok ] - echo [ ok ] rm [ ok ] - sf [ ok ] 15 remove subflows and signal syn[ ok ] - synack[ ok ] - ack[ ok ] add[ ok ] - echo [ ok ] rm [ ok ] - sf [ ok ] Suggested-by:Matthieu Baerts <matthieu.baerts@tessares.net> Suggested-by:
-
Geliang Tang authored
This patch added a new cfg, named cfg_remove in mptcp_connect. This new cfg_remove is copied from cfg_join. The only difference between them is in the do_rnd_write function. Here we slow down the transfer process of all data to let the RM_ADDR suboption can be sent and received completely. Otherwise the remove address and subflow test cases don't work. Suggested-by:
-
Geliang Tang authored
This patch added a new helper named mptcp_destroy_common containing the shared code between mptcp_destroy() and mptcp_sock_destruct(). Suggested-by:
-
Geliang Tang authored
This patch added two new mibs for RM_ADDR, named MPTCP_MIB_RMADDR and MPTCP_MIB_RMSUBFLOW, when the RM_ADDR suboption is received, increase the first mib counter, when the local subflow is removed, increase the second mib counter. Suggested-by:
-
Geliang Tang authored
This patch implemented the local subflow removing function, mptcp_pm_remove_subflow, it simply called mptcp_pm_nl_rm_subflow_received under the PM spin lock. We use mptcp_pm_remove_subflow to remove a local subflow, so change it's argument from remote_id to local_id. We check subflow->local_id in mptcp_pm_nl_rm_subflow_received to remove a subflow. Suggested-by:
-
Geliang Tang authored
This patch implements the remove announced addr and subflow logic in PM netlink. When the PM netlink removes an address, we traverse all the existing msk sockets to find the relevant sockets. We add a new list named anno_list in mptcp_pm_data, to record all the announced addrs. In the traversing, we check if it has been recorded. If it has been, we trigger the RM_ADDR signal. We also check if this address is in conn_list. If it is, we remove the subflow which using this local address. Since we call mptcp_pm_free_anno_list in mptcp_destroy, we need to move __mptcp_init_sock before the mptcp_is_enabled check in mptcp_init_sock. Suggested-by:
-
Geliang Tang authored
The re-check of pm->accept_subflow with pm->lock held was missing, this patch fixed it. Suggested-by:
-
Geliang Tang authored
This patch added the ADD_ADDR related mibs counter check function chk_add_nr(). This function check both ADD_ADDR and ADD_ADDR with echo flag. The output looks like this: 07 unused signal address syn[ ok ] - synack[ ok ] - ack[ ok ] add[ ok ] - echo [ ok ] 08 signal address syn[ ok ] - synack[ ok ] - ack[ ok ] add[ ok ] - echo [ ok ] 09 subflow and signal syn[ ok ] - synack[ ok ] - ack[ ok ] add[ ok ] - echo [ ok ] 10 multiple subflows and signal syn[ ok ] - synack[ ok ] - ack[ ok ] add[ ok ] - echo [ ok ] 11 remove subflow and signal syn[ ok ] - synack[ ok ] - ack[ ok ] add[ ok ] - echo [ ok ] Reviewed-by: -
Geliang Tang authored
This patch added two mibs for ADD_ADDR, MPTCP_MIB_ADDADDR for receiving of the ADD_ADDR suboption with echo-flag=0, and MPTCP_MIB_ECHOADD for receiving the ADD_ADDR suboption with echo-flag=1. Reviewed-by:
-
Geliang Tang authored
When the ADD_ADDR suboption has been received, we need to send out the same ADD_ADDR suboption with echo-flag=1, and no HMAC. Suggested-by:
-
Geliang Tang authored
This patch added the RM_ADDR option parsing logic: We parsed the incoming options to find if the rm_addr option is received, and called mptcp_pm_rm_addr_received to schedule PM work to a new status, named MPTCP_PM_RM_ADDR_RECEIVED. PM work got this status, and called mptcp_pm_nl_rm_addr_received to handle it. In mptcp_pm_nl_rm_addr_received, we closed the subflow matching the rm_id, and updated PM counter. Suggested-by:
-
Geliang Tang authored
This patch added a new signal named rm_addr_signal in PM. On outgoing path, we called mptcp_pm_should_rm_signal to check if rm_addr_signal has been set. If it has been, we sent out the RM_ADDR option. Suggested-by:
-
Geliang Tang authored
This patch renamed addr_signal and the related functions with the explicit word "add". Suggested-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== mlx5-updates-2020-09-22 This series includes mlx5 updates 1) Add support for Connection Tracking offload in NIC mode. Supporting CT offload in NIC mode on Mellanox cards is useful for scenarios where the dual port NIC serves as a gateway between 2 networks and forwards traffic between these networks. Since the traffic is not terminated on the host in this case, no use of SRIOV VFs and/or switchdev mode is required. Today Mellanox NIC cards already support offloading of packet forwarding between physical ports without going to the host so combining it with CT offloading allows users to create a gateway with forwarding and CT (Including NAT) offloading capabilities in non-switchdev mode. To support connection tracking in non-Switchdev mode (Single NIC mode), we need to make use of the current Connection tracking infrastructure implemented on top of E-Switch and the mlx5 generic flow table chains APIs, to make it work on non-Eswitch steering domain e.g. NIC RX domain, the following was performed: 1.1) Refactor current flow steering chains infrastructure and updates TC nic mode implementation to use flow table chains. 1.2) Refactor current Connection Tracking (CT) infrastructure to not assume E-switch backend, and make the CT layer agnostic to underlying steering mode (E-Switch/NIC) 1.3) Plumbing to support CT offload in NIC mode. 2) Trivial code cleanups. ==================== Signed-off-by: -
David S. Miller authored
Ioana Ciornei says: ==================== dpaa2-mac: add PCS support through the Lynx module This patch set aims to add PCS support in the dpaa2-eth driver by leveraging the Lynx PCS module. The first two patches are some missing pieces: the first one adding support for 10GBASER in Lynx PCS while the second one adds a new function - of_mdio_find_device - which is helpful in retrieving the PCS represented as a mdio_device. The final patch adds the glue logic between phylink and the Lynx PCS module: it retrieves the PCS represented as an mdio_device and registers it to Lynx and phylink. From that point on, any PCS callbacks are treated by Lynx, without dpaa2-eth interaction. Changes in v2: - move put_device() after destroy - 3/3 ==================== Signed-off-by: -
Ioana Ciornei authored
Include PCS support in the dpaa2-eth driver by integrating it with the new Lynx PCS module. There is not much to talk about in terms of changes needed in the dpaa2-eth driver since the only steps necessary are to find the MDIO device representing the PCS, register it to the Lynx PCS module and then let phylink know if its existence also. After this, the PCS callbacks will be treated directly by Lynx, without interraction from dpaa2-eth's part. Signed-off-by:
Ioana Ciornei <ioana.ciornei@nxp.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Russell King authored
Add a helper function which finds the mdio_device structure given a device tree node. This is helpful for finding the PCS device based on a DTS node but managing it as a mdio_device instead of a phy_device. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Ioana Ciornei authored
Add support in the Lynx PCS module for the 10GBASE-R mode which is only used to get the link state, since it offers a single fixed speed. Signed-off-by:
-
Vladimir Oltean authored
Currently, ocelot switchdev passes the skb directly to the function that enqueues it to the list of skb's awaiting a TX timestamp. Whereas the felix DSA driver first clones the skb, then passes the clone to this queue. This matters because in the case of felix, the common IRQ handler, which is ocelot_get_txtstamp(), currently clones the clone, and frees the original clone. This is useless and can be simplified by using skb_complete_tx_timestamp() instead of skb_tstamp_tx(). Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
- 24 Sep, 2020 13 commits
-
-
David S. Miller authored
Florian Fainelli says: ==================== net: dsa: b53: Configure VLANs while not filtering These two patches allow the b53 driver which always configures its CPU port as egress tagged to behave correctly with VLANs being always configured whenever a port is added to a bridge. Vladimir provides a patch that aligns the bridge with vlan_filtering=0 receive path to behave the same as vlan_filtering=1. Per discussion with Nikolay, this behavior is deemed to be too DSA specific to be done in the bridge proper. This is a preliminary series for Vladimir to make configure_vlan_while_filtering the default behavior for all DSA drivers in the future. Thanks! Changes in v3: - added Vladimir's Acked-by tag to patch #2 - removed unnecessary if_vlan.h inclusion in patch #2 - reworded commit message to be accurate with the code changes Changes in v2: - moved the call to dsa_untag_bridge_pvid() into net/dsa/tag_brcm.c since we have a single user for now ==================== Signed-off-by: -
Florian Fainelli authored
Update the B53 driver to support VLANs while not filtering. This requires us to enable VLAN globally within the switch upon driver initial configuration (dev->vlan_enabled). We also need to remove the code that dealt with PVID re-configuration in b53_vlan_filtering() since that function worked under the assumption that it would only be called to make a bridge VLAN filtering, or not filtering, and we would attempt to move the port's PVID accordingly. Now that VLANs are programmed all the time, even in the case of a non-VLAN filtering bridge, we would be programming a default_pvid for the bridged switch ports. We need the DSA receive path to pop the VLAN tag if it is the bridge's default_pvid because the CPU port is always programmed tagged in the programmed VLANs. In order to do so we utilize the dsa_untag_bridge_pvid() helper introduced in the commit before within net/dsa/tag_brcm.c. Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
Currently the bridge untags VLANs present in its VLAN groups in __allowed_ingress() only when VLAN filtering is enabled. But when a skb is seen on the RX path as tagged with the bridge's pvid, and that bridge has vlan_filtering=0, and there isn't any 8021q upper with that VLAN either, then we have a problem. The bridge will not untag it (since it is supposed to remain VLAN-unaware), and pvid-tagged communication will be broken. There are 2 situations where we can end up like that: 1. When installing a pvid in egress-tagged mode, like this: ip link add dev br0 type bridge vlan_filtering 0 ip link set swp0 master br0 bridge vlan del dev swp0 vid 1 bridge vlan add dev swp0 vid 1 pvid This happens because DSA configures the VLAN membership of the CPU port using the same flags as swp0 (in this case "pvid and not untagged"), in an attempt to copy the frame as-is from ingress to the CPU. However, in this case, the packet may arrive untagged on ingress, it will be pvid-tagged by the ingress port, and will be sent as egress-tagged towards the CPU. Otherwise stated, the CPU will see a VLAN tag where there was none to speak of on ingress. When vlan_filtering is 1, this is not a problem, as stated in the first paragraph, because __allowed_ingress() will pop it. But currently, when vlan_filtering is 0 and we have such a VLAN configuration, we need an 8021q upper (br0.1) to be able to ping over that VLAN, which is not symmetrical with the vlan_filtering=1 case, and therefore, confusing for users. Basically what DSA attempts to do is simply an approximation: try to copy the skb with (or without) the same VLAN all the way up to the CPU. But DSA drivers treat CPU port VLAN membership in various ways (which is a good segue into situation 2). And some of those drivers simply tell the CPU port to copy the frame unmodified, which is the golden standard when it comes to VLAN processing (therefore, any driver which can configure the hardware to do that, should do that, and discard the VLAN flags requested by DSA on the CPU port). 2. Some DSA drivers always configure the CPU port as egress-tagged, in an attempt to recover the classified VLAN from the skb. These drivers cannot work at all with untagged traffic when bridged in vlan_filtering=0 mode. And they can't go for the easy "just keep the pvid as egress-untagged towards the CPU" route, because each front port can have its own pvid, and that might require conflicting VLAN membership settings on the CPU port (swp1 is pvid for VID 1 and egress-tagged for VID 2; swp2 is egress-taggeed for VID 1 and pvid for VID 2; with this simplistic approach, the CPU port, which is really a separate hardware entity and has its own VLAN membership settings, would end up being egress-untagged in both VID 1 and VID 2, therefore losing the VLAN tags of ingress traffic). So the only thing we can do is to create a helper function for resolving the problematic case (that is, a function which untags the bridge pvid when that is in vlan_filtering=0 mode), which taggers in need should call. It isn't called from the generic DSA receive path because there are drivers that fall neither in the first nor second category. Signed-off-by:
-
David S. Miller authored
Andrew Lunn says: ==================== PHY subsystem kernel doc The first patches fix existing warnings in the kerneldoc for the PHY subsystem, and then the 2nd extend the kernel documentation for the major structures and functions in the PHY subsystem. v2: Drop the other fixes which have already been merged. s/phy/PHY/g TBI TypOs ==================== Signed-off-by: -
Andrew Lunn authored
Add kerneldoc for the core PHY data structures, a few inline functions and exported functions which are not already documented. v2 Typos g/phy/PHY/s Signed-off-by:
-
Andrew Lunn authored
Add missing parameter documentation, or fixup wrong parameter names. Reviewed-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: dsa: bcm_sf2: Additional DT changes This patch series includes some additional changes to the bcm_sf2 in order to support the Device Tree firmwares provided on such platforms. ==================== Signed-off-by: -
Florian Fainelli authored
We need to include MDIO address 0, which is how our Device Tree blobs indicate where to find the external BCM53125 switches. Signed-off-by:
-
Florian Fainelli authored
While the switch driver is written such that port 5 or 8 could be CPU ports, the use case on Broadcom STB chips is to use port 8 exclusively. The platform firmware does make port 5 comply to a proper DSA CPU port binding by specifiying an "ethernet" phandle. This is undesirable for now until we have an user-space configuration mechanism (such as devlink) which could support dynamically changing the port flavor at run time. Signed-off-by:
-
David S. Miller authored
George Cherian says: ==================== octeontx2: Add support for VLAN based flow distribution This series add support for VLAN based flow distribution for octeontx2 netdev driver. This adds support for configuring the same via ethtool. Following tests have been done. - Multi VLAN flow with same SD - Multi VLAN flow with same SDFN - Single VLAN flow with multi SD - Single VLAN flow with multi SDFN All tests done for udp/tcp both v4 and v6 ==================== Reviewed-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
George Cherian authored
Add support to control rx-flow-hash based on VLAN. By default VLAN plus 4-tuple based hashing is enabled. Changes can be done runtime using ethtool To enable 2-tuple plus VLAN based flow distribution # ethtool -N <intf> rx-flow-hash <prot> sdv To enable 4-tuple plus VLAN based flow distribution # ethtool -N <intf> rx-flow-hash <prot> sdfnv Signed-off-by:
George Cherian <george.cherian@marvell.com> Signed-off-by:
Sunil Goutham <sgoutham@marvell.com> Signed-off-by:
-
George Cherian authored
Added support for PF/VF drivers to choose RSS flow key algorithm with VLAN tag included in hashing input data. Only CTAG is considered. Signed-off-by:
-
Mauro Carvalho Chehab authored
kernel-doc expects the function prototype to be just after the kernel-doc markup, as otherwise it will get it all wrong: ./net/core/dev.c:10036: warning: Excess function parameter 'dev' description in 'WAIT_REFS_MIN_MSECS' Fixes: 0e4be9e5 ("net: use exponential backoff in netdev_wait_allrefs") Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by:
Francesco Ruggeri <fruggeri@arista.com> Signed-off-by:
-
