- 20 Apr, 2023 12 commits
-
-
Michal Schmidt authored
The ice-gnss-<dev_name> kernel thread, which reads data from the u-blox GNSS module, keep a CPU core almost 100% busy. The main reason is that it busy-waits for data to become available. A simple improvement would be to replace the "mdelay(10);" in ice_gnss_read() with sleeping. A better fix is to not do any waiting directly in the function and just requeue this delayed work as needed. The advantage is that canceling the work from ice_gnss_exit() becomes immediate, rather than taking up to ~2.5 seconds (ICE_MAX_UBX_READ_TRIES * 10 ms). This lowers the CPU usage of the ice-gnss-<dev_name> thread on my system from ~90 % to ~8 %. I am not sure if the larger 0.1 s pause after inserting data into the gnss subsystem is really necessary, but I'm keeping that as it was. Of course, ideally the driver would not have to poll at all, but I don't know if the E810 can watch for GNSS data availability over the i2c bus by itself and notify the driver. Signed-off-by:
Michal Schmidt <mschmidt@redhat.com> Reviewed-by:
Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Tested-by: Sunitha Mekala <sunithax.d.mekala@intel.com> (A Contingent worker at Intel) Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>
-
Zhengchao Shao authored
When wx_alloc_page_pool() failed in wx_setup_rx_resources(), it doesn't release DMA buffer. Add dma_free_coherent() in the error path to release the DMA buffer. Fixes: 850b9711 ("net: libwx: Allocate Rx and Tx resources") Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by:
Paolo Abeni <pabeni@redhat.com>
-
Jakub Kicinski authored
Chuck Lever says: ==================== Another crack at a handshake upcall mechanism Here is v10 of a series to add generic support for transport layer security handshake on behalf of kernel socket consumers (user space consumers use a security library directly, of course). A summary of the purpose of these patches is archived here: https://lore.kernel.org/netdev/1DE06BB1-6BA9-4DB4-B2AA-07DE532963D6@oracle.com/ The first patch in the series applies to the top-level .gitignore file to address the build warnings reported a few days ago. I intend to submit that separately. I'd like you to consider taking the rest of this series for v6.4. The full patch set to support SunRPC with TLSv1.3 is available in the topic-rpc-with-tls-upcall branch here, based on net-next/main: https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git This patch set includes support for in-transit confidentiality and peer authentication for both the Linux NFS client and server. A user space handshake agent for TLSv1.3 to go along with the kernel patches is available in the "main" branch here: https://github.com/oracle/ktls-utils ==================== Link: https://lore.kernel.org/r/168174169259.9520.1911007910797225963.stgit@91.116.238.104.host.secureserver.netSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Chuck Lever authored
These verify the API contracts and help exercise lifetime rules for consumer sockets and handshake_req structures. One way to run these tests: ./tools/testing/kunit/kunit.py run --kunitconfig ./net/handshake/.kunitconfig Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
-
Chuck Lever authored
To enable kernel consumers of TLS to request a TLS handshake, add support to net/handshake/ to request a handshake upcall. This patch also acts as a template for adding handshake upcall support for other kernel transport layer security providers. Signed-off-by:
-
Chuck Lever authored
When a kernel consumer needs a transport layer security session, it first needs a handshake to negotiate and establish a session. This negotiation can be done in user space via one of the several existing library implementations, or it can be done in the kernel. No in-kernel handshake implementations yet exist. In their absence, we add a netlink service that can: a. Notify a user space daemon that a handshake is needed. b. Once notified, the daemon calls the kernel back via this netlink service to get the handshake parameters, including an open socket on which to establish the session. c. Once the handshake is complete, the daemon reports the session status and other information via a second netlink operation. This operation marks that it is safe for the kernel to use the open socket and the security session established there. The notification service uses a multicast group. Each handshake mechanism (eg, tlshd) adopts its own group number so that the handshake services are completely independent of one another. The kernel can then tell via netlink_has_listeners() whether a handshake service is active and prepared to handle a handshake request. A new netlink operation, ACCEPT, acts like accept(2) in that it instantiates a file descriptor in the user space daemon's fd table. If this operation is successful, the reply carries the fd number, which can be treated as an open and ready file descriptor. While user space is performing the handshake, the kernel keeps its muddy paws off the open socket. A second new netlink operation, DONE, indicates that the user space daemon is finished with the socket and it is safe for the kernel to use again. The operation also indicates whether a session was established successfully. Signed-off-by:
-
Chuck Lever authored
Circumvent the .gitignore wildcard to avoid warnings about ignored .kunitconfig files. As far as I can tell, the warnings are harmless and these files are not actually ignored. Reported-by:
kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202304142337.jc4oUrov-lkp@intel.com/Signed-off-by:
-
Jakub Kicinski authored
Merge tag 'ipsec-next-2023-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next Steffen Klassert says: ==================== ipsec-next 2023-04-19 1) Remove inner/outer modes from input/output path. These are not needed anymore. From Herbert Xu. * tag 'ipsec-next-2023-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next: xfrm: Remove inner/outer modes from output path xfrm: Remove inner/outer modes from input path ==================== Link: https://lore.kernel.org/r/20230419075300.452227-1-steffen.klassert@secunet.comSigned-off-by:
-
Rob Herring authored
A JSON pointer reference (the part after the "#") must start with a "/". Conversely, references to the entire document must not have a trailing "/" and should be just a "#". The existing jsonschema package allows these, but coming changes make allowed "$ref" URIs stricter and throw errors on these references. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230418150628.1528480-1-robh@kernel.orgSigned-off-by:
-
Horatiu Vultur authored
At the beginning of the file micrel.c there is list of supported PHYs. Extend this list with the following PHYs lan8841, lan8814 and lan8804, as these PHYs were added but the list was not updated. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20230418124713.2221451-1-horatiu.vultur@microchip.comSigned-off-by:
-
Simon Horman authored
Rather than casting clk_disable_unprepare to an incompatible function type provide a trivial wrapper with the correct signature for the use-case. Reported by clang-16 with W=1: drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c:276:6: error: cast from 'void (*)(struct clk *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict] (void(*)(void *))clk_disable_unprepare, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ No functional change intended. Compile tested only. Signed-off-by:Simon Horman <horms@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20230418-dwmac-meson8b-clk-cb-cast-v1-1-e892b670cbbb@kernel.orgSigned-off-by:
-
Daniel Golle authored
There are two variants of the MT7531 switch IC which got different features (and pins) regarding port 5: * MT7531AE: SGMII/1000Base-X/2500Base-X SerDes PCS * MT7531BE: RGMII Moving the creation of the SerDes PCS from mt753x_setup to mt7530_probe with commit 6de28522 ("net: dsa: mt7530: move SGMII PCS creation to mt7530_probe function") works fine for MT7531AE which got two instances of mtk-pcs-lynxi, however, MT7531BE requires mt7531_pll_setup to setup clocks before the single PCS on port 6 (usually used as CPU port) starts to work and hence the PCS creation failed on MT7531BE. Fix this by introducing a pointer to mt7531_create_sgmii function in struct mt7530_priv and call it again at the end of mt753x_setup like it was before commit 6de28522 ("net: dsa: mt7530: move SGMII PCS creation to mt7530_probe function"). Fixes: 6de28522 ("net: dsa: mt7530: move SGMII PCS creation to mt7530_probe function") Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Acked-by:
Arınç ÜNAL <arinc.unal@arinc9.com> Link: https://lore.kernel.org/r/ZDvlLhhqheobUvOK@makrotopia.orgSigned-off-by:
-
- 19 Apr, 2023 28 commits
-
-
Jakub Kicinski authored
Commit c519fe9a ("bnxt: add dma mapping attributes") added DMA_ATTR_WEAK_ORDERING to DMA attrs on bnxt. It has since spread to a few more drivers (possibly as a copy'n'paste). DMA_ATTR_WEAK_ORDERING only seems to matter on Sparc and PowerPC/cell, the rarity of these platforms is likely why we never bothered adding the attribute in the page pool, even though it should be safe to add. To make the page pool migration in drivers which set this flag less of a risk (of regressing the precious sparc database workloads or whatever needed this) let's add DMA_ATTR_WEAK_ORDERING on all page pool DMA mappings. We could make this a driver opt-in but frankly I don't think it's worth complicating the API. I can't think of a reason why device accesses to packet memory would have to be ordered. Acked-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org> Acked-by:
Somnath Kotur <somnath.kotur@broadcom.com> Reviewed-by:
Alexander Lobakin <aleksander.lobakin@intel.com> Acked-by:
Jesper Dangaard Brouer <brouer@redhat.com> Link: https://lore.kernel.org/r/20230417152805.331865-1-kuba@kernel.orgSigned-off-by:
-
Corinna Vinschen authored
Without the IFF_LIVE_ADDR_CHANGE flag being set, the network code disallows changing the mac address while the interface is UP. Consequences are, for instance, that the interface can't be used in a failover bond. Add the missing flag to net_device priv_flags. Tested on Intel Elkhart Lake with default settings, as well as with failover and alb mode bonds. Signed-off-by:
Corinna Vinschen <vinschen@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Jakub Kicinski says: ==================== net: skbuff: hide some bitfield members There is a number of protocol or subsystem specific fields in struct sk_buff which are only accessed by one subsystem. We can wrap them in ifdefs with minimal code impact. This gives us a better chance to save a 2B and a 4B holes resulting with the following savings (assuming a lucky kernel config): - /* size: 232, cachelines: 4, members: 28 */ - /* sum members: 227, holes: 1, sum holes: 4 */ - /* sum bitfield members: 8 bits (1 bytes) */ + /* size: 224, cachelines: 4, members: 28 */ /* forced alignments: 2 */ - /* last cacheline: 40 bytes */ + /* last cacheline: 32 bytes */ I think that the changes shouldn't be too controversial. The only one I'm not 100% sure of is the SCTP one, 12 extra LoC for one bit.. But it did fit squarely in the "this bit has only one user" category. ==================== Signed-off-by:
-
Jakub Kicinski authored
Accesses to nf_trace and ipvs_property are already wrapped by ifdefs where necessary. Don't allocate the bits for those fields at all if possible. Acked-by:
Florian Westphal <fw@strlen.de> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Jakub Kicinski authored
nf_trace is a debug feature, AFAIU, and yet it sits oddly high in the sk_buff bitfield. Move it down, pushing up dst_pending_confirm and inner_protocol_type. Next change will make nf_trace optional (under Kconfig) and all optional fields should be placed after 2b fields to avoid 2b fields straddling bytes. dst_pending_confirm is L3, so it makes sense next to ignore_df. inner_protocol_type goes up just to keep the balance. Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
-
Jakub Kicinski authored
alloc_cpu is currently between 4 byte fields, so it's almost guaranteed to create a 2B hole. It has a knock on effect of creating a 4B hole after @end (and @end and @tail being in different cachelines). None of this matters hugely, but for kernel configs which don't enable all the features there may well be a 2B hole after the bitfield. Move alloc_cpu there. Reviewed-by:
-
Jakub Kicinski authored
SCTP is not universally deployed, allow hiding its bit from the skb. Reviewed-by:
-
Jakub Kicinski authored
Datacenter kernel builds will very likely not include WIRELESS, so let them shave 2 bits off the skb by hiding the wifi fields. Reviewed-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
David S. Miller authored
Christian Marangi says: ==================== net: Add basic LED support for switch/phy This is a continue of [1]. It was decided to take a more gradual approach to implement LEDs support for switch and phy starting with basic support and then implementing the hw control part when we have all the prereq done. This series implements only the brightness_set() and blink_set() ops. An example of switch implementation is done with qca8k. For PHY a more generic approach is used with implementing the LED support in PHY core and with the user (in this case marvell) adding all the required functions. Currently we set the default-state as "keep" to not change the default configuration of the declared LEDs since almost every switch have a default configuration. [1] https://lore.kernel.org/lkml/20230216013230.22978-1-ansuelsmth@gmail.com/ Changes in new series v7: - Drop ethernet-leds schema and add unevaluatedProperties to ethernet-controller and ethernet-phy schema - Drop function-enumerator binding from schema example and DT - Set devname_mandatory for qca8k leds and assign better name to LEDs using the format {slave_mii_bus id}:0{port number}:{color}:{function} - Add Documentation patch for Correct LEDs naming from Andrew - Changes in Andrew patch: - net: phy: Add a binding for PHY LEDs - Convert index from u32 to u8 - net: phy: phy_device: Call into the PHY driver to set LED brightness - Fixup kernel doc - Convert index from u32 to u8 - net: phy: marvell: Add software control of the LEDs - Convert index from u32 to u8 - net: phy: phy_device: Call into the PHY driver to set LED blinking - Kernel doc fix - Convert index from u32 to u8 - net: phy: marvell: Implement led_blink_set() - Convert index from u32 to u8 Changes in new series v6: - Add leds-ethernet.yaml to document reg in led node - Update ethernet-controller and ethernet-phy to follow new leds-ethernet schema - Fix comments in qca8k-leds.c (at least -> at most) (wrong GENMASK for led phy 0 and 4) - Add review and ack tag from Pavel Machek - Changes in Andrew patch: - leds: Provide stubs for when CLASS_LED & NEW_LEDS are disabled - Change LED_CLASS to NEW_LEDS for led_init_default_state_get() - net: phy: Add a binding for PHY LEDs - Add dependency on LED_CLASS - Drop review tag from Michal Kubiak (patch modified) Changes in new series v5: - Rebase everything on top of net-next/main - Add more info on LED probe fail for qca8k - Drop some additional raw number and move to define in qca8k header - Add additional info on LED mapping on qca8k regs - Checks port number in qca8k switch port parse - Changes in Andrew patch: - Add additional patch for stubs when CLASS_LED disabled - Drop CLASS_LED dependency for PHYLIB (to fix kbot errors reported) Changes in new series v4: - Changes in Andrew patch: - net: phy: Add a binding for PHY LEDs: - Rename phy_led: led_list to list - Rename phy_device: led_list to leds - Remove phy_leds_remove() since devm_ should do what is needed - Fixup documentation for struct phy_led - Fail probe on LED errors - net: phy: phy_device: Call into the PHY driver to set LED brightness - Moved phy_led::phydev from previous patch to here since it is first used here. - net: phy: marvell: Implement led_blink_set() - Use int instead of unsigned - net: phy: marvell: Add software control of the LEDs - Use int instead of unsigned - Add depends on LED_CLASS for qca8k Kconfig - Fix Makefile for qca8k as suggested - Move qca8k_setup_led_ctrl to separate header - Move Documentation from dsa-port to ethernet-controller - Drop trailing . from Andrew patch fro consistency Changes in new series v3: - Move QCA8K_LEDS Kconfig option from tristate to bool - Use new helper led_init_default_state_get for default-state in qca8k - Drop cled_qca8k_brightness_get() as there isn't a good way to describe the mode the led is currently in - Rework qca8k_led_brightness_get() to return true only when LED is set to always ON Changes in new series v2: - Add LEDs node for rb3011 - Fix rb3011 switch node unevaluated properties while running make dtbs_check - Fix a copypaste error in qca8k-leds.c for port 4 required shift - Drop phy-handle usage for qca8k and use qca8k_port_to_phy() - Add review tag from Andrew - Add Christian Marangi SOB in each Andrew patch - Add extra description for dsa-port stressing that PHY have no access and LED are controlled by the related MAC - Add missing additionalProperties for dsa-port.yaml and ethernet-phy.yaml Changes from the old v8 series: - Drop linux,default-trigger set to netdev. - Dropped every hw control related patch and implement only blink_set and brightness_set - Add default-state to "keep" for each LED node example ==================== Signed-off-by:
-
Andrew Lunn authored
Network LEDs can exist in both the MAC and the PHY. Naming is difficult because the netdev name is neither stable or unique, do to commands like ip link set name eth42 dev eth0, and network namesspaces. Give some example names where the MAC and the PHY have unique names based on device tree nodes, or PCI bus addresses. Since the LED can be used for anything which Linux supports for LEDs, avoid using names like activity or link, rather describe the location on the RJ-45, of what the RJ-45 is expected to be used for, WAN/LAN etc. Signed-off-by:
Christian Marangi <ansuelsmth@gmail.com> Signed-off-by:
-
Andrew Lunn authored
The WAN port of the 370-RD has a Marvell PHY, with one LED on the front panel.y List this LED in the device tree. Signed-off-by:
-
Christian Marangi authored
Document support for LEDs node in phy and add an example for it. PHY LED will have to match led pattern and should be treated as a generic led. Signed-off-by:
-
Christian Marangi authored
Add Switch LED for each port for MikroTik RB3011UiAS-RM. MikroTik RB3011UiAS-RM is a 10 port device with 2 qca8337 switch chips connected. It was discovered that in the hardware design all 3 Switch LED trace of the related port is connected to the same LED. This was discovered by setting to 'always on' the related led in the switch regs and noticing that all 3 LED for the specific port (for example for port 1) cause the connected LED for port 1 to turn on. As an extra test we tried enabling 2 different LED for the port resulting in the LED turned off only if every led in the reg was off. Aside from this funny and strange hardware implementation, the device itself have one green LED for each port, resulting in 10 green LED one for each of the 10 supported port. Cc: Jonathan McDowell <noodles@earth.li> Signed-off-by:
-
Christian Marangi authored
IPQ8064 MikroTik RB3011UiAS-RM DT have currently unevaluted properties in the 2 switch nodes. The bindings #address-cells and #size-cells are redundant and cause warning for 'Unevaluated properties are not allowed'. Drop these bindings to mute these warning as they should not be there from the start. Cc: Jonathan McDowell <noodles@earth.li> Signed-off-by:
Jonathan McDowell <noodles@earth.li> Tested-by:
-
Christian Marangi authored
Add LEDs definition example for qca8k Switch Family to describe how they should be defined for a correct usage. Signed-off-by:
-
Christian Marangi authored
Document support for LEDs node in ethernet-controller. Ethernet Controller may support different LEDs that can be configured for different operation like blinking on traffic event or port link. Also add some Documentation to describe the difference of these nodes compared to PHY LEDs, since ethernet-controller LEDs are controllable by the ethernet controller regs and the possible intergated PHY doesn't have control on them. Signed-off-by:
-
Andrew Lunn authored
The Marvell PHY can blink the LEDs, simple on/off. All LEDs blink at the same rate, and the reset default is 84ms per blink, which is around 12Hz. Signed-off-by:
-
Andrew Lunn authored
Linux LEDs can be requested to perform hardware accelerated blinking. Pass this to the PHY driver, if it implements the op. Signed-off-by:
-
Andrew Lunn authored
Add a brightness function, so the LEDs can be controlled from software using the standard Linux LED infrastructure. Signed-off-by:
-
Andrew Lunn authored
Linux LEDs can be software controlled via the brightness file in /sys. LED drivers need to implement a brightness_set function which the core will call. Implement an intermediary in phy_device, which will call into the phy driver if it implements the necessary function. Signed-off-by:
-
Andrew Lunn authored
Define common binding parsing for all PHY drivers with LEDs using phylib. Parse the DT as part of the phy_probe and add LEDs to the linux LED class infrastructure. For the moment, provide a dummy brightness function, which will later be replaced with a call into the PHY driver. This allows testing since the LED core might otherwise reject an LED whose brightness cannot be set. Add a dependency on LED_CLASS. It either needs to be built in, or not enabled, since a modular build can result in linker errors. Signed-off-by:
-
Andrew Lunn authored
Provide stubs for devm_led_classdev_register_ext() and led_init_default_state_get() so that LED drivers embedded within other drivers such as PHYs and Ethernet switches still build when LEDS_CLASS or NEW_LEDS are disabled. This also helps with Kconfig dependencies, which are somewhat hairy for phylib and mdio and only get worse when adding a dependency on LED_CLASS. Signed-off-by:
-
Christian Marangi authored
Add LEDs blink_set() support to qca8k Switch Family. These LEDs support hw accellerated blinking at a fixed rate of 4Hz. Reject any other value since not supported by the LEDs switch. Signed-off-by:
Pavel Machek <pavel@ucw.cz> Reviewed-by:
-
Christian Marangi authored
Add LEDs basic support for qca8k Switch Family by adding basic brightness_set() support. Since these LEDs refelect port status, the default label is set to ":port". DT binding should describe the color and function of the LEDs using standard LEDs api. Each LED always have the device name as prefix. The device name is composed from the mii bus id and the PHY addr resulting in example names like: - qca8k-0.0:00:amber:lan - qca8k-0.0:00:white:lan - qca8k-0.0:01:amber:lan - qca8k-0.0:01:white:lan These LEDs supports only blocking variant of the brightness_set() function since they can sleep during access of the switch leds to set the brightness. While at it add to the qca8k header file each mode defined by the Switch Documentation for future use. Signed-off-by:
-
Christian Marangi authored
Move qca8k_port_to_phy() to qca8k header as it's useful for future reference in Switch LEDs module since the same logic is applied to get the right index of the switch port. Make it inline as it's simple function that just decrease the port. Signed-off-by:
Michal Kubiak <michal.kubiak@intel.com> Reviewed-by:
-
Jaime Breva authored
Our use-case needs two AT ports available: One for running a ppp daemon, and another one for management This patch enables a second AT port on DATA1 Signed-off-by:
Jaime Breva <jbreva@nayarsystems.com> Signed-off-by:
-
David S. Miller authored
Tariq Toukan says: ==================== net/mlx5e: Extend XDP multi-buffer capabilities This series extends the XDP multi-buffer support in the mlx5e driver. Patchset breakdown: - Infrastructural changes and preparations. - Add XDP multi-buffer support for XDP redirect-in. - Use TX MPWQE (multi-packet WQE) HW feature for non-linear single-segmented XDP frames. - Add XDP multi-buffer support for striding RQ. In Striding RQ, we overcome the lack of headroom and tailroom between the RQ strides by allocating a side page per packet and using it for the xdp_buff descriptor. We structure the xdp_buff so that it contains nothing in the linear part, and the whole packet resides in the fragments. Performance highlight: Packet rate test, 64 bytes, 32 channels, MTU 9000 bytes. CPU: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz. NIC: ConnectX-6 Dx, at 100 Gbps. +----------+-------------+-------------+---------+ | Test | Legacy RQ | Striding RQ | Speedup | +----------+-------------+-------------+---------+ | XDP_DROP | 101,615,544 | 117,191,020 | +15% | +----------+-------------+-------------+---------+ | XDP_TX | 95,608,169 | 117,043,422 | +22% | +----------+-------------+-------------+---------+ Series generated against net commit: e61caf04 Merge branch 'page_pool-allow-caching-from-safely-localized-napi' I'm submitting this directly as Saeed is traveling. ==================== Signed-off-by:
-
Tariq Toukan authored
Here we add support for multi-buffer XDP handling in Striding RQ, which is our default out-of-the-box RQ type. Before this series, loading such an XDP program would fail, until you switch to the legacy RQ (by unsetting the rx_striding_rq priv-flag). To overcome the lack of headroom and tailroom between the strides, we allocate a side page to be used for the descriptor (xdp_buff / skb) and the linear part. When an XDP program is attached, we structure the xdp_buff so that it contains no data in the linear part, and the whole packet resides in the fragments. In case of XDP_PASS, where an SKB still needs to be created, we copy up to 256 bytes to its linear part, to match the current behavior, and satisfy functions that assume finding the packet headers in the SKB linear part (like eth_type_trans). Performance testing: Packet rate test, 64 bytes, 32 channels, MTU 9000 bytes. CPU: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz. NIC: ConnectX-6 Dx, at 100 Gbps. +----------+-------------+-------------+---------+ | Test | Legacy RQ | Striding RQ | Speedup | +----------+-------------+-------------+---------+ | XDP_DROP | 101,615,544 | 117,191,020 | +15% | +----------+-------------+-------------+---------+ | XDP_TX | 95,608,169 | 117,043,422 | +22% | +----------+-------------+-------------+---------+ Reviewed-by:
Saeed Mahameed <saeedm@nvidia.com> Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Signed-off-by:
-
