- 03 Dec, 2017 9 commits
-
-
David S. Miller authored
Vivien Didelot says: ==================== net: dsa: cross-chip FDB support DSA can have interconnected switches. For instance, the ZII Dev Rev B board described in arch/arm/boot/dts/vf610-zii-dev-rev-b.dts has a switch fabric composed of 3 switch devices like this: lan4 lan6 CPU (eth1) | lan5 | lan7 | | | | | [0 1 2 3 4 6 5]---[6 0 1 2 3 4 5]---[9 0 1 2 3 4 5 6 7 8] | | | | | | | lan0 | lan2 lan3 lan8 | optical4 lan1 optical3 One current issue with DSA is cross-chip FDB. If we add a static MAC address on lan3, only its parent switch 1 (the one in the middle) will be programmed. That is not correct in a cross-chip environment, because the DSA ports connecting to switch 1 of adjacent switch 0 (on the left) and switch 2 (on the right) must be programmed too. Without this patchset, a dump of the hardware FDB of switches 0, 1 and 2 after programming a MAC address on lan3 looks like this (*): # bridge fdb add 11:22:33:44:55:66 dev lan3 # cat /sys/kernel/debug/mv88e6xxx/sw*/atu/0 | grep -v FID 0 ff:ff:ff:ff:ff:ff MC_STATIC n 0 1 2 3 4 5 6 0 11:22:33:44:55:66 MC_STATIC_MGMT_PO n 0 - - - - - - 0 ff:ff:ff:ff:ff:ff MC_STATIC n 0 1 2 3 4 5 6 0 ff:ff:ff:ff:ff:ff MC_STATIC n 0 1 2 3 4 5 6 7 8 9 With this patchset applied, adjacent DSA ports get programmed too: # bridge fdb add 11:22:33:44:55:66 dev lan3 # cat /sys/kernel/debug/mv88e6xxx/sw*/atu/0 | grep -v FID 0 11:22:33:44:55:66 MC_STATIC_MGMT_PO n - - - - - 5 - 0 ff:ff:ff:ff:ff:ff MC_STATIC n 0 1 2 3 4 5 6 0 11:22:33:44:55:66 MC_STATIC_MGMT_PO n 0 - - - - - - 0 ff:ff:ff:ff:ff:ff MC_STATIC n 0 1 2 3 4 5 6 0 11:22:33:44:55:66 MC_STATIC_MGMT_PO n - - - - - - - - - 9 0 ff:ff:ff:ff:ff:ff MC_STATIC n 0 1 2 3 4 5 6 7 8 9 In order to do that, the first commit introduces a dsa_towards_port() helper which returns the local port of a switch which must be used to reach an arbitrary switch port (local or from an adjacent switch.) The second patch uses this helper to configure the port reaching the target port for every switches of the fabric. (*) a patch for squashed debugfs interface which applies on top of this patchset is available here: https://github.com/vivien/linux/commit/f8e6ba34c68a72d3bf42f4dea79abacb2e61a3cc.patch ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Vivien Didelot authored
When a MAC address is added to or removed from a switch port in the fabric, the target switch must program its port and adjacent switches must program their local DSA port used to reach the target switch. For this purpose, use the dsa_towards_port() helper to identify the local switch port which must be programmed. Signed-off-by:
Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by:
-
Vivien Didelot authored
Add a new helper returning the local port used to reach an arbitrary switch port in the fabric. Its only user at the moment is the dsa_upstream_port helper, which returns the local port reaching the dedicated CPU port, but it will be used in cross-chip FDB operations. Signed-off-by:
-
David S. Miller authored
Vivien Didelot says: ==================== net: dsa: simplify switchdev prepare phase This patch series brings no functional changes. It removes the unused switchdev_trans arguments from the dsa_switch_ops for both MDB and VLAN operations, and provides functions to prepare and add these objects for a given bitmap of ports. ==================== Signed-off-by: -
Vivien Didelot authored
This patch brings no functional changes. It moves out the MDB code iterating on a multicast group into new dsa_switch_mdb_{prepare,add}_bitmap() functions. This gives us a better isolation of the two switchdev phases. Signed-off-by: -
Vivien Didelot authored
This patch brings no functional changes. It moves out the VLAN code iterating on a list of VLAN members into new dsa_switch_vlan_{prepare,add}_bitmap() functions. This gives us a better isolation of the two switchdev phases. Signed-off-by: -
Vivien Didelot authored
The DSA switch MDB ops pass the switchdev_trans structure down to the drivers, but no one is using them and they aren't supposed to anyway. Remove the trans argument from MDB prepare and add operations. Signed-off-by:
-
Vivien Didelot authored
The DSA switch VLAN ops pass the switchdev_trans structure down to the drivers, but no one is using them and they aren't supposed to anyway. Remove the trans argument from VLAN prepare and add operations. At the same time, fix the following checkpatch warning: WARNING: line over 80 characters #74: FILE: drivers/net/dsa/dsa_loop.c:177: + const struct switchdev_obj_port_vlan *vlan) Signed-off-by: -
Paolo Abeni authored
After commit 3a927bc7 ("ovs: propagate per dp max headroom to all vports") the need_headroom for the internal vport is updated accordingly to the max needed headroom in its datapath. That avoids the pskb_expand_head() costs when sending/forwarding packets towards tunnel devices, at least for some scenarios. We still require such copy when using the ovs-preferred configuration for vxlan tunnels: br_int / \ tap vxlan (remote_ip:X) br_phy \ NIC where the route towards the IP 'X' is via 'br_phy'. When forwarding traffic from the tap towards the vxlan device, we will call pskb_expand_head() in vxlan_build_skb() because br-phy->needed_headroom is equal to tun->needed_headroom. With this change we avoid updating the internal vport needed_headroom, so that in the above scenario no head copy is needed, giving 5% performance improvement in UDP throughput test. As a trade-off, packets sent from the internal port towards a tunnel device will now experience the head copy overhead. The rationale is that the latter use-case is less relevant performance-wise. Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Acked-by:
Pravin B Shelar <pshelar@ovn.org> Signed-off-by:
-
- 01 Dec, 2017 26 commits
-
-
David S. Miller authored
Grygorii Strashko says: ==================== net: ethernet: ti: cpsw/ale clean up and optimization This is set of non critical clean ups and optimizations for TI CPSW and ALE drivers. Rebased on top on net-next. ==================== Signed-off-by: -
Grygorii Strashko authored
ALE ports number includes the Host port and ext Ports, and ALE ports numbering starts from 0, so correct corresponding port checks in cpsw_ale_control_set/get(). Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
Grygorii Strashko authored
Use cpsw_ale_create in cpsw_ale_create(). This also makes cpsw_ale_destroy() function nop, so remove it. Signed-off-by:
-
Grygorii Strashko authored
Move static initialization from cpsw_ale_start() to cpsw_ale_create() as it does not make much sence to perform static initializtion in cpsw_ale_start() which is called everytime netif[s] is opened. Signed-off-by:
-
Grygorii Strashko authored
The ale->params.ale_ports parameter can be used to deriver values for all ale entry mask bits: port_mask_bits, port_mask_bits, port_num_bits. Hence, calculate above values and drop all hardcoded values. For port_num_bits calcualtion use order_base_2() API. Signed-off-by:
-
Grygorii Strashko authored
ALE is enabled from cpsw_ale_start() now, but disabled only from cpsw_ale_destroy() which introduces inconsitance as cpsw_ale_start() is called when netif[s] is opened, but cpsw_ale_destroy() is called when driver is removed. Hence, move ALE disabling in cpsw_ale_stop(). Signed-off-by:
-
Grygorii Strashko authored
Switch to use writel_relaxed/readl_relaxed() IO API instead of raw version as it is recommended. Signed-off-by:
-
Grygorii Strashko authored
TI OMAP/Sitara SoCs have fixed number of ALE ports 3, which includes Host port also. Hence, use fixed value instead of value calcualted from DT, which can be set by user and might not reflect actual HW configuration. Signed-off-by:
-
Grygorii Strashko authored
Move mac_hi/lo defines in common header cpsw.h and re-use them for netcp_ethss.c. Signed-off-by:
-
Grygorii Strashko authored
CPSW platform data struct cpsw_platform_data and struct cpsw_slave_data are used only incide cpsw.c module, so move these definitions there. Signed-off-by:
-
Grygorii Strashko authored
Switch to use writel_relaxed/readl_relaxed() IO API instead of raw version as it is recommended. Signed-off-by:
-
Grygorii Strashko authored
Drop unused variable "poll" from cpsw_update_channels_res(). Signed-off-by:
-
Heiner Kallweit authored
Remove generic settings for callbacks config_aneg and read_status from drivers. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
read_status and config_aneg are the only mandatory callbacks and most of the time the generic implementation is used by drivers. So make the core fall back to the generic version if a driver doesn't implement the respective callback. Also currently the core doesn't seem to verify that drivers implement the mandatory calls. If a driver doesn't do so we'd just get a NPE. With this patch this potential issue doesn't exit any longer. Signed-off-by:
-
David S. Miller authored
William Tu says: ==================== ip6_gre: add erspan native tunnel for ipv6 The patch series add support for ERSPAN tunnel over ipv6. The first patch refectors the existing ipv4 gre implementation and the second refactors the ipv6 gre's xmit code. Finally the last patch introduces erspan protocol. change in v5: - add cover-letter description change in v4: - rebase on top of net-next - use log_ecn_error in ip6_tnl_rcv change in v3: - add inline for functions in header - rebase on top of net-next change in v2: - remove inline - fix some indent - fix errors reports by clang and scan-build ==================== Signed-off-by: -
William Tu authored
The patch adds support for ERSPAN tunnel over ipv6. Signed-off-by:
William Tu <u9012063@gmail.com> Signed-off-by:
-
William Tu authored
This patch refactors the ip6gre_xmit_{ipv4, ipv6}. It is a prep work to add the ip6erspan tunnel. Signed-off-by: -
William Tu authored
Move two erspan functions to header file, erspan.h, so ipv6 erspan implementation can use it. Signed-off-by:
-
David S. Miller authored
Scott Branden says: ==================== net: ethtool: add support for ETH_RESET_AP Add support to reset appplication processors inside SmartNICs by defining new ETH_RESET_AP bit. And use new ETH_RESET_AP bit in bnxt ethernet driver. ==================== Signed-off-by: -
Scott Branden authored
Add ETH_RESET_AP support handling to reset the internal Application Processor(s) of the SmartNIC card. Signed-off-by:
Scott Branden <scott.branden@broadcom.com> Acked-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Scott Branden authored
Add ETH_RESET_AP to reset the application processor(s) inside the NIC interface. Current ETH_RESET_MGMT supports a management processor inside this NIC. This is typically used for remote NIC management purposes. Application processors exist inside some SmartNICs to run various applications inside the NIC processor - be it a simple algorithm without an OS to as complex as hosting multiple VMs. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
David S. Miller authored
Sowmini Varadhan says: ==================== rds-tcp netns delete related fixes Patchset contains cleanup and bug fixes. Patch 1 is the removal of some redundant code/functions. Patch 2 and 3 are fixes for corner cases identified by syzkaller. I've not been able to reproduce the actual use-after-free race flagged in the syzkaller reports, thus these fixes are based on code inspection plus manual testing to make sure the modified code paths are executed without problems in the commonly encountered timing cases. ==================== Signed-off-by: -
Sowmini Varadhan authored
The rds_tcp_kill_sock() function parses the rds_tcp_conn_list to find the rds_connection entries marked for deletion as part of the netns deletion under the protection of the rds_tcp_conn_lock. Since the rds_tcp_conn_list tracks rds_tcp_connections (which have a 1:1 mapping with rds_conn_path), multiple tc entries in the rds_tcp_conn_list will map to a single rds_connection, and will be deleted as part of the rds_conn_destroy() operation that is done outside the rds_tcp_conn_lock. The rds_tcp_conn_list traversal done under the protection of rds_tcp_conn_lock should not leave any doomed tc entries in the list after the rds_tcp_conn_lock is released, else another concurrently executiong netns delete (for a differnt netns) thread may trip on these entries. Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
Sowmini Varadhan <sowmini.varadhan@oracle.com> Acked-by:
Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by:
-
Sowmini Varadhan authored
Commit 8edc3aff ("rds: tcp: Take explicit refcounts on struct net") introduces a regression in rds-tcp netns cleanup. The cleanup_net(), (and thus rds_tcp_dev_event notification) is only called from put_net() when all netns refcounts go to 0, but this cannot happen if the rds_connection itself is holding a c_net ref that it expects to release in rds_tcp_kill_sock. Instead, the rds_tcp_kill_sock callback should make sure to tear down state carefully, ensuring that the socket teardown is only done after all data-structures and workqs that depend on it are quiesced. The original motivation for commit 8edc3aff ("rds: tcp: Take explicit refcounts on struct net") was to resolve a race condition reported by syzkaller where workqs for tx/rx/connect were triggered after the namespace was deleted. Those worker threads should have been cancelled/flushed before socket tear-down and indeed, rds_conn_path_destroy() does try to sequence this by doing /* cancel cp_send_w */ /* cancel cp_recv_w */ /* flush cp_down_w */ /* free data structures */ Here the "flush cp_down_w" will trigger rds_conn_shutdown and thus invoke rds_tcp_conn_path_shutdown() to close the tcp socket, so that we ought to have satisfied the requirement that "socket-close is done after all other dependent state is quiesced". However, rds_conn_shutdown has a bug in that it *always* triggers the reconnect workq (and if connection is successful, we always restart tx/rx workqs so with the right timing, we risk the race conditions reported by syzkaller). Netns deletion is like module teardown- no need to restart a reconnect in this case. We can use the c_destroy_in_prog bit to avoid restarting the reconnect. Fixes: 8edc3aff ("rds: tcp: Take explicit refcounts on struct net") Signed-off-by:
-
Sowmini Varadhan authored
A side-effect of Commit c14b0366 ("rds: tcp: set linger to 1 when unloading a rds-tcp") is that we always send a RST on the tcp connection for rds_conn_destroy(), so rds_tcp_conn_paths_destroy() is not needed any more and is removed in this patch. Signed-off-by:
-
Jon Maloy authored
When sending node local messages the code is using an 'mtu' of 66060 bytes to avoid unnecessary fragmentation. During situations of low memory tipc_msg_build() may sometimes fail to allocate such large buffers, resulting in unnecessary send failures. This can easily be remedied by falling back to a smaller MTU, and then reassemble the buffer chain as if the message were arriving from a remote node. At the same time, we change the initial MTU setting of the broadcast link to a lower value, so that large messages always are fragmented into smaller buffers even when we run in single node mode. Apart from obtaining the same advantage as for the 'fallback' solution above, this turns out to give a significant performance improvement. This can probably be explained with the __pskb_copy() operation performed on the buffer for each recipient during reception. We found the optimal value for this, considering the most relevant skb pool, to be 3744 bytes. Acked-by:
Ying Xue <ying.xue@ericsson.com> Signed-off-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
-
- 30 Nov, 2017 5 commits
-
-
David S. Miller authored
Rafal Ozieblo says: ==================== Receive packets filtering for macb driver This patch series adds support for receive packets filtering for Cadence GEM driver. Packets can be redirect to different hardware queues based on source IP, destination IP, source port or destination port. To enable filtering, support for RX queueing was added as well. ==================== Signed-off-by: -
Rafal Ozieblo authored
This patch allows filtering received packets to different hardware queues (aka ntuple). Signed-off-by:
Rafal Ozieblo <rafalo@cadence.com> Signed-off-by:
-
Rafal Ozieblo authored
Added statistics per queue: - qX_rx_packets - qX_rx_bytes - qX_rx_dropped - qX_tx_packets - qX_tx_bytes - qX_tx_dropped Signed-off-by:
-
Rafal Ozieblo authored
To be able for packet reception on different RX queues some configuration has to be performed. This patch checks how many hardware queue does GEM support and initializes them. Signed-off-by:
-
Shrikrishna Khare authored
There are several reasons for increasing the receive ring sizes: 1. The original ring size of 256 was chosen about 10 years ago when vmxnet3 was first created. At that time, 10Gbps Ethernet was not prevalent and servers were dominated by 1Gbps Ethernet. Now 10Gbps is common place, and higher bandwidth links -- 25Gbps, 40Gbps, 50Gbps -- are starting to appear. 256 Rx ring entries are simply not enough to keep up with higher link speed when there is a burst of network frames coming from these high speed links. Even with full MTU size frames, they are gone in a short time. It is also more common to have a mix of frame sizes, and more likely bi-modal distribution of frame sizes so the average frame size is not close to full MTU. If we consider average frame size of 800B, 1024 frames that come in a burst takes ~0.65 ms to arrive at 10Gbps. With 256 entires, it takes ~0.16 ms to arrive at 10Gbps. At 25Gbps or 40Gbps, this time is reduced accordingly. 2. On a hypervisor where there are many VMs and CPU is over committed, i.e. the number of VCPUs is more than the number of VCPUs, each PCPU is in effect time shared between multiple VMs/VCPUs. The time granularity at which this multiplexing occurs is typically coarser than between processes on a guest OS. Trying to time slice more finely is not efficient, for example, if memory cache is barely warmed up when switching from one VM to another occurs. This CPU overcommit adds delay to when the driver in a VM can service incoming packets. Whether CPU is over committed really depends on customer workloads. For certain situations, it is very common. For example, workloads of desktop VMs and product testing setups. Consolidation and sharing is what drives efficiency of a customer setup for such workloads. In these situations, the raw network bandwidth may not be very high, but the delays between when a VM is running or not running can also be relatively long. Signed-off-by:
Shrikrishna Khare <skhare@vmware.com> Acked-by:
Jin Heo <heoj@vmware.com> Acked-by:
Guolin Yang <gyang@vmware.com> Acked-by:
Boon Ang <bang@vmware.com> Signed-off-by:
-
