- 01 Dec, 2020 38 commits
-
-
Jakub Kicinski authored
Ido Schimmel says: ==================== mlxsw: Add support for 802.1ad bridging 802.1ad, also known as QinQ, is an extension to the 802.1q standard, which is concerned with passing possibly 802.1q-tagged packets through another VLAN-like tunnel. The format of 802.1ad tag is the same as 802.1q, except it uses the EtherType of 0x88a8, unlike 802.1q's 0x8100. Currently, mlxsw supports bridging with VLAN-unaware (802.1d) bridges and with VLAN-aware bridges whose VLAN protocol is 802.1q. This set adds support for VLAN-aware bridges whose VLAN protocol is 802.1ad. From mlxsw perspective, 802.1ad support entails two main changes: 1. Ports member in an 802.1ad bridge need to be configured to classify 802.1ad packets as tagged and all other packets as untagged 2. When pushing a VLAN at ingress (PVID), its EtherType needs to be 0x88a8 instead of 802.1q's 0x8100 The rest stays the same as with 802.1q bridges. A follow-up patch set will add support for QinQ with VXLAN, also known as QinVNI. Currently, linking of a VXLAN netdev to an 802.1ad bridge is vetoed and an error is returned to user space. Patch set overview: Patches #1-#2 add the registers required to configure the two changes described above. Patch #3 changes the device to only treat 802.1q packets as tagged by default, as opposed to both 802.1q and 802.1ad packets. This is more inline with the behavior supported by the driver. Patch #4 adds the ability to configure the EtherType when pushing a PVID at ingress. Patch #5 performs small refactoring to allow for code re-use in the next patch. Patch #6 adds support for 802.1ad bridging and allows mlxsw ports and their uppers to join such a bridge. Patch #7 changes the bridge driver to notify about changes to its VLAN protocol, so that these could be vetoed by mlxsw in the next patch. Patches #8-#9 teach mlxsw to veto unsupported 802.1ad configurations and add a corresponding selftest to make sure such configurations are indeed vetoed. ==================== Link: https://lore.kernel.org/r/20201129125407.1391557-1-idosch@idosch.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Danielle Ratson authored
Test that each veto that was added in the previous patch, is indeed vetoed. $ ./q_in_q_veto.sh TEST: create 802.1ad vlan upper on top of a front panel [ OK ] TEST: create 802.1ad vlan upper on top of a bridge port [ OK ] TEST: create 802.1ad vlan upper on top of a lag [ OK ] TEST: create 802.1ad vlan upper on top 802.1q bridge [ OK ] TEST: create 802.1ad vlan upper on top 802.1ad bridge [ OK ] TEST: create 802.1q vlan upper on top 802.1ad bridge [ OK ] TEST: create vlan upper on top of front panel enslaved to 802.1ad bridge [ OK ] TEST: create vlan upper on top of lag enslaved to 802.1ad bridge [ OK ] TEST: enslave front panel with vlan upper to 802.1ad bridge [ OK ] TEST: enslave lag with vlan upper to 802.1ad bridge [ OK ] TEST: IP address addition to 802.1ad bridge [ OK ] TEST: switch bridge protocol [ OK ] Signed-off-by:
Danielle Ratson <danieller@nvidia.com> Reviewed-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
-
Danielle Ratson authored
After adding support for QinQ, a.k.a 802.1ad protocol, there are a few scenarios that should be vetoed. The vetoes are motivated by various ASIC limitations. For example, a port that is member in a 802.1ad bridge cannot have 802.1q uppers as the port needs to be configured to treat 802.1q packets as untagged packets. Veto all those unsupported scenarios and return suitable messages. Signed-off-by:
-
Danielle Ratson authored
Drivers that support bridge offload need to be notified about changes to the bridge's VLAN protocol so that they could react accordingly and potentially veto the change. Add a new switchdev attribute to communicate the change to drivers. Signed-off-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
Ivan Vecera <ivecera@redhat.com> Signed-off-by:
-
Amit Cohen authored
802.1ad, also known as QinQ is an extension to the 802.1q standard, which is concerned with passing possibly 802.1q-tagged packets through another VLAN-like tunnel. The format of 802.1ad tag is the same as 802.1q, except it uses the EtherType of 0x88a8, unlike 802.1q's 0x8100. Add support for 802.1ad protocol. Most of the configuration is the same as 802.1q. The difference is that before a port joins an 802.1ad bridge it needs to be configured to recognize 802.1ad packets as tagged and other packets (e.g., 802.1q) as untagged. VXLAN is not currently supported with 802.1ad bridge, so return an error with an appropriate extack message. Signed-off-by:
Amit Cohen <amcohen@nvidia.com> Reviewed-by:
-
Amit Cohen authored
The code in mlxsw_sp_bridge_8021q_port_{join, leave}() can be used also for 802.1ad bridge. Move the code to functions called mlxsw_sp_bridge_vlan_aware_port_{join, leave}() and call them from mlxsw_sp_bridge_8021q_port_{join, leave}() respectively to enable code reuse. Signed-off-by: -
Amit Cohen authored
Currently, when pushing a PVID at ingress, mlxsw always uses 802.1q EtherType. Make this EtherType configurable by extending mlxsw_sp_port_pvid_set() with an EtherType argument. This is a preparation for QinQ support, that needs to push a PVID with 802.1ad EtherType. Signed-off-by:
-
Amit Cohen authored
By default, the device considers both 802.1ad and 802.1q packets as tagged, but this is not supported by the driver. It only supports VLAN and bridge devices that use 802.1q protocol. Instead, configure the device to only treat 802.1q packets as tagged packets. Signed-off-by:
-
Amit Cohen authored
et_vlan field is used to configure which EtherType is used when VLAN is pushed at ingress (for untagged packets or for QinQ push mode). It will be used to configure tagging with ether_type1 (i.e., 0x88A8) for QinQ mode. Signed-off-by:
-
Amit Cohen authored
SPVC configures the port to identify packets as untagged / single tagged / double tagged packets based on the packet EtherTypes. It will be used to classify 802.1q packets as untagged and 802.1ad packets as tagged when received by ports member in a 802.1ad bridge. Signed-off-by:
-
Jakub Kicinski authored
Huazhong Tan says: ==================== net: hns3: updates for -next This series includes some updates for the HNS3 ethernet driver. #1~#6: add some updates related to the checksum offload. #7: add support for multiple TCs' MAC pauce mode. ==================== Link: https://lore.kernel.org/r/1606535510-44346-1-git-send-email-tanhuazhong@huawei.comSigned-off-by:
-
Yonglong Liu authored
Bellow HNAE3_DEVICE_VERSION_V3, MAC pause mode just support one TC, when enabled multiple TCs, force enable PFC mode. HNAE3_DEVICE_VERSION_V3 can support MAC pause mode on multiple TCs, so when enable multiple TCs, just keep MAC pause mode, and enable PFC mode just according to the user settings. Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Huazhong Tan authored
For the device whose version is above V3(include V3), the hardware can do checksum offload for the non-tunnel udp packet, who has a dest port as the IANA assigned. So add a check for devcie's verion in hns3_tunnel_csum_bug(). Signed-off-by:
-
Huazhong Tan authored
Since TX hardware checksum and RX completion checksum have been supported now, so add related information in hns3_dbg_bd_info(). Signed-off-by:
-
Huazhong Tan authored
For the device who has the capability to handle udp tunnel checksum segmentation, add support for it. Signed-off-by:
-
Huazhong Tan authored
Currently, device V1 and V2 do not support segmentation offload for UDP based tunnel packet who needs outer UDP checksum offload, so there is a workaround in the driver to set the checksum of the outer UDP checksum as zero. This is not what the user wants, so remove this feature for device V1 and V2, add support for it later(when the device has the ability to do that). Signed-off-by:
-
Huazhong Tan authored
For the device that supports TX hardware checksum, the hardware can calculate the checksum from the start and fill the checksum to the offset position, which reduces the operations of calculating the type and header length of L3/L4. So add this feature for the HNS3 ethernet driver. The previous simple BD description is unsuitable, rename it as HW TX CSUM. Signed-off-by:
-
Huazhong Tan authored
In some cases (for example ip fragment), hardware will calculate the checksum of whole packet in RX, and setup the HNS3_RXD_L2_CSUM_B flag in the descriptor, so add support to utilize this checksum. Signed-off-by:
-
Lukas Bulwahn authored
For IPV6_2292PKTOPTIONS, do_ipv6_getsockopt() stores the user pointer optval in the msg_control field of the msghdr. Hence, sparse rightfully warns at ./net/ipv6/ipv6_sockglue.c:1151:33: warning: incorrect type in assignment (different address spaces) expected void *msg_control got char [noderef] __user *optval Since commit 1f466e1f ("net: cleanly handle kernel vs user buffers for ->msg_control"), user pointers shall be stored in the msg_control_user field, and kernel pointers in the msg_control field. This allows to propagate __user annotations nicely through this struct. Store optval in msg_control_user to properly record and propagate the memory space annotation of this pointer. Note that msg_control_is_user is set to true, so the key invariant, i.e., use msg_control_user if and only if msg_control_is_user is true, holds. The msghdr is further used in the six alternative put_cmsg() calls, with msg_control_is_user being true, put_cmsg() picks msg_control_user preserving the __user annotation and passes that properly to copy_to_user(). No functional change. No change in object code. Signed-off-by:Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20201127093421.21673-1-lukas.bulwahn@gmail.comSigned-off-by:
-
Marco Elver authored
It turns out that usage of skb extensions can cause memory leaks. Ido Schimmel reported: "[...] there are instances that blindly overwrite 'skb->extensions' by invoking skb_copy_header() after __alloc_skb()." Therefore, give up on using skb extensions for KCOV handle, and instead directly store kcov_handle in sk_buff. Fixes: 6370cc3b ("net: add kcov handle to skb extensions") Fixes: 85ce50d3 ("net: kcov: don't select SKB_EXTENSIONS when there is no NET") Fixes: 97f53a08 ("net: linux/skbuff.h: combine SKB_EXTENSIONS + KCOV handling") Link: https://lore.kernel.org/linux-wireless/20201121160941.GA485907@shredder.lan/Reported-by:
Ido Schimmel <idosch@idosch.org> Signed-off-by:
Marco Elver <elver@google.com> Link: https://lore.kernel.org/r/20201125224840.2014773-1-elver@google.comSigned-off-by:
-
Vlad Buslov authored
Functions tfilter_notify_chain() and tcf_get_next_proto() are always called with rtnl lock held in current implementation. Moreover, attempting to call them without rtnl lock would cause a warning down the call chain in function __tcf_get_next_proto() that requires the lock to be held by callers. Remove the 'rtnl_held' argument in order to simplify the code and make rtnl lock requirement explicit. Signed-off-by:
Vlad Buslov <vladbu@nvidia.com> Link: https://lore.kernel.org/r/20201127151205.23492-1-vladbu@nvidia.comSigned-off-by:
-
Jakub Kicinski authored
Merge tag 'linux-can-next-for-5.11-20201130' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2020-11-30 Gustavo A. R. Silva's patch for the pcan_usb driver fixes fall-through warnings for Clang. The next 5 patches target the mcp251xfd driver and are by Ursula Maplehurst and me. They optimizie the TEF and RX path by reducing number of SPI core requests to set the UINC bit. The remaining 8 patches target the m_can driver. The first 4 are various cleanups for the SPI binding driver (tcan4x5x) by Sean Nyekjaer, Dan Murphy and me. Followed by 4 cleanup patches by me for the m_can and m_can_platform driver. * tag 'linux-can-next-for-5.11-20201130' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: can: m_can: m_can_class_unregister(): move right after m_can_class_register() can: m_can: m_can_plat_remove(): remove unneeded platform_set_drvdata() can: m_can: remove not used variable struct m_can_classdev::freq can: m_can: Kconfig: convert the into menu can: tcan4x5x: tcan4x5x_can_probe(): remove probe failed error message can: tcan4x5x: remove mram_start and reg_offset from struct tcan4x5x_priv can: tcan4x5x: rename parse_config() function can: tcan4x5x: tcan4x5x_clear_interrupts(): remove redundant return statement can: mcp251xfd: tef-path: reduce number of SPI core requests to set UINC bit can: mcp251xfd: move struct mcp251xfd_tef_ring definition can: mcp251xfd: struct mcp251xfd_priv::tef to array of length 1 can: mcp25xxfd: rx-path: reduce number of SPI core requests to set UINC bit can: mcp251xfd: mcp25xxfd_ring_alloc(): add define instead open coding the maximum number of RX objects can: pcan_usb_core: fix fall-through warnings for Clang ==================== Link: https://lore.kernel.org/r/20201130141432.278219-1-mkl@pengutronix.deSigned-off-by:
-
Tom Rix authored
The macro use will already have a semicolon. Signed-off-by:
Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20201127165734.2694693-1-trix@redhat.comSigned-off-by:
-
Jakub Kicinski authored
Paolo Abeni says: ==================== mptcp: avoid workqueue usage for data The current locking schema used to protect the MPTCP data-path requires the usage of the MPTCP workqueue to process the incoming data, depending on trylock result. The above poses scalability limits and introduces random delays in MPTCP-level acks. With this series we use a single spinlock to protect the MPTCP data-path, removing the need for workqueue and delayed ack usage. This additionally reduces the number of atomic operations required per packet and cleans-up considerably the poll/wake-up code. ==================== Link: https://lore.kernel.org/r/cover.1606413118.git.pabeni@redhat.comSigned-off-by:
-
Paolo Abeni authored
We have some tasks triggered by the subflow receive path which require to access the msk socket status, specifically: mptcp_clean_una() and mptcp_push_pending() We have almost everything in place to defer to the msk release_cb such tasks when the msk sock is owned. Since the worker is no more used to clean the acked data, for fallback sockets we need to explicitly flush them. As an added bonus we can move the wake-up code in __mptcp_clean_una(), simplify a lot mptcp_poll() and move the timer update under the data lock. The worker is now used only to process and send DATA_FIN packets and do the mptcp-level retransmissions. Acked-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Reviewed-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
-
Paolo Abeni authored
Extending the data_lock scope in mptcp_incoming_option we can use that to protect both snd_una and wnd_end. In the typical case, we will have a single atomic op instead of 2 Acked-by:
-
Paolo Abeni authored
Move the TX skbs allocation in mptcp_sendmsg() scope, and tentatively pre-allocate a skbs number proportional to the sendmsg() length. Use the ssk tx skb cache to prevent the subflow allocation. This allows removing the msk skb extension cache and will make possible the later patches. Acked-by:
-
Paolo Abeni authored
Such spinlock is currently used only to protect the 'owned' flag inside the socket lock itself. With this patch, we extend its scope to protect the whole msk receive path and sk_forward_memory. Given the above, we can always move data into the msk receive queue (and OoO queue) from the subflow. We leverage the previous commit, so that we need to acquire the spinlock in the tx path only when moving fwd memory. recvmsg() must now explicitly acquire the socket spinlock when moving skbs out of sk_receive_queue. To reduce the number of lock operations required we use a second rx queue and splice the first into the latter in mptcp_lock_sock(). Additionally rmem allocated memory is bulk-freed via release_cb() Acked-by:
-
Paolo Abeni authored
This leverages the previous commit to reserve the wmem required for the sendmsg() operation when the msk socket lock is first acquired. Some heuristics are used to get a reasonable [over] estimation of the whole memory required. If we can't forward alloc such amount fallback to a reasonable small chunk, otherwise enter the wait for memory path. When sendmsg() needs more memory it looks at wmem_reserved first and if that is exhausted, move more space from sk_forward_alloc. The reserved memory is not persistent and is released at the next socket unlock via the release_cb(). Overall this will simplify the next patch. Acked-by:
-
Paolo Abeni authored
This allows invoking an additional callback under the socket spin lock. Will be used by the next patches to avoid additional spin lock contention. Acked-by:
-
Jakub Kicinski authored
Camelia Groza says: ==================== dpaa_eth: add XDP support Enable XDP support for the QorIQ DPAA1 platforms. Implement all the current actions (DROP, ABORTED, PASS, TX, REDIRECT). No Tx batching is added at this time. Additional XDP_PACKET_HEADROOM bytes are reserved in each frame's headroom. After transmit, a reference to the xdp_frame is saved in the buffer for clean-up on confirmation in a newly created structure for software annotations. DPAA_TX_PRIV_DATA_SIZE bytes are reserved in the buffer for storing this structure and the XDP program is restricted from accessing them. The driver shares the egress frame queues used for XDP with the network stack. The DPAA driver is a LLTX driver so no explicit locking is required on transmission. ==================== Link: https://lore.kernel.org/r/cover.1606322126.git.camelia.groza@nxp.comSigned-off-by:
-
Camelia Groza authored
For XDP TX, even tough we start out with correctly aligned buffers, the XDP program might change the data's alignment. For REDIRECT, we have no control over the alignment either. Create a new workaround for xdp_frame structures to verify the erratum conditions and move the data to a fresh buffer if necessary. Create a new xdp_frame for managing the new buffer and free the old one using the XDP API. Due to alignment constraints, all frames have a 256 byte headroom that is offered fully to XDP under the erratum. If the XDP program uses all of it, the data needs to be move to make room for the xdpf backpointer. Disable the metadata support since the information can be lost. Acked-by:
Madalin Bucur <madalin.bucur@oss.nxp.com> Signed-off-by:
Camelia Groza <camelia.groza@nxp.com> Reviewed-by:
Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by:
-
Camelia Groza authored
Explicitly point that the current workaround addresses skbs. This change is in preparation for adding a workaround for XDP scenarios. Acked-by:
-
Camelia Groza authored
After transmission, the frame is returned on confirmation queues for cleanup. For this, store a backpointer to the xdp_frame in the private reserved area at the start of the TX buffer. No TX batching support is implemented at this time. Acked-by:
-
Camelia Groza authored
Use an xdp_frame structure for managing the frame. Store a backpointer to the structure at the start of the buffer before enqueueing for cleanup on TX confirmation. Reserve DPAA_TX_PRIV_DATA_SIZE bytes from the frame size shared with the XDP program for this purpose. Use the XDP API for freeing the buffer when it returns to the driver on the TX confirmation path. The frame queues are shared with the netstack. The DPAA driver is a LLTX driver so no explicit locking is required on transmission. This approach will be reused for XDP REDIRECT. Acked-by:
-
Camelia Groza authored
Implement the ndo_change_mtu callback to prevent users from setting an MTU that would permit processing of S/G frames. The maximum MTU size is dependent on the buffer size. Acked-by:
-
Camelia Groza authored
Implement the XDP_DROP and XDP_PASS actions. Avoid draining and reconfiguring the buffer pool at each XDP setup/teardown by increasing the frame headroom and reserving XDP_PACKET_HEADROOM bytes from the start. Since we always reserve an entire page per buffer, this change only impacts Jumbo frame scenarios where the maximum linear frame size is reduced by 256 bytes. Multi buffer Scatter/Gather frames are now used instead in these scenarios. Allow XDP programs to access the entire buffer. The data in the received frame's headroom can be overwritten by the XDP program. Extract the relevant fields from the headroom while they are still available, before running the XDP program. Since the headroom might be resized before the frame is passed up to the stack, remove the check for a fixed headroom value when building an skb. Allow the meta data to be updated and pass the information up the stack. Scatter/Gather frames are dropped when XDP is enabled. Acked-by:
-
Camelia Groza authored
We maintain an skb backpointer in the software annotations area of Tx frames. Introduce a structure for explicit handling. Acked-by:
-
- 30 Nov, 2020 2 commits
-
-
Marc Kleine-Budde authored
This patch moves the function m_can_class_unregister() directly after the m_can_class_register() function. Link: https://lore.kernel.org/r/20201130133713.269256-7-mkl@pengutronix.deReviewed-by:
Dan Murphy <dmurphy@ti.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
There's no need to unset the drvdata on remove, so remove the unneeded call to platform_set_drvdata() in m_can_plat_remove(). Link: https://lore.kernel.org/r/20201130133713.269256-6-mkl@pengutronix.deReviewed-by:
-
