- 15 Feb, 2024 10 commits
-
-
Alex Henrie authored
If the preferred lifetime was less than the minimum required lifetime, ipv6_create_tempaddr would error out without creating any new address. On my machine and network, this error happened immediately with the preferred lifetime set to 5 seconds or less, after a few minutes with the preferred lifetime set to 6 seconds, and not at all with the preferred lifetime set to 7 seconds. During my investigation, I found a Stack Exchange post from another person who seems to have had the same problem: They stopped getting new addresses if they lowered the preferred lifetime below 3 seconds, and they didn't really know why. The preferred lifetime is a preference, not a hard requirement. The kernel does not strictly forbid new connections on a deprecated address, nor does it guarantee that the address will be disposed of the instant its total valid lifetime expires. So rather than disable IPv6 privacy extensions altogether if the minimum required lifetime swells above the preferred lifetime, it is more in keeping with the user's intent to increase the temporary address's lifetime to the minimum necessary for the current network conditions. With these fixes, setting the preferred lifetime to 5 or 6 seconds "just works" because the extra fraction of a second is practically unnoticeable. It's even possible to reduce the time before deprecation to 1 or 2 seconds by setting /proc/sys/net/ipv6/conf/*/regen_min_advance and /proc/sys/net/ipv6/conf/*/dad_transmits to 0. I realize that that is a pretty niche use case, but I know at least one person who would gladly sacrifice performance and convenience to be sure that they are getting the maximum possible level of privacy. Link: https://serverfault.com/a/1031168/310447Signed-off-by:
Alex Henrie <alexhenrie24@gmail.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Alex Henrie authored
In RFC 8981, REGEN_ADVANCE cannot be less than 2 seconds, and the RFC does not permit the creation of temporary addresses with lifetimes shorter than that: > When processing a Router Advertisement with a > Prefix Information option carrying a prefix for the purposes of > address autoconfiguration (i.e., the A bit is set), the host MUST > perform the following steps: > 5. A temporary address is created only if this calculated preferred > lifetime is greater than REGEN_ADVANCE time units. However, some users want to change their IPv6 address as frequently as possible regardless of the RFC's arbitrary minimum lifetime. For the benefit of those users, add a regen_min_advance sysctl parameter that can be set to below or above 2 seconds. Link: https://datatracker.ietf.org/doc/html/rfc8981Signed-off-by:
-
Alex Henrie authored
RFC 8981 defines REGEN_ADVANCE as follows: REGEN_ADVANCE = 2 + (TEMP_IDGEN_RETRIES * DupAddrDetectTransmits * RetransTimer / 1000) Thus, allowing it to be less than 2 seconds is technically a protocol violation. Link: https://datatracker.ietf.org/doc/html/rfc8981#name-defined-protocol-parametersSigned-off-by:
-
Kurt Kanzenbach authored
Add support for LEDs on i225/i226. The LEDs can be controlled via sysfs from user space using the netdev trigger. The LEDs are named as igc-<bus><device>-<led> to be easily identified. Offloading link speed and activity are supported. Other modes are simulated in software by using on/off. Tested on Intel i225. Signed-off-by:
Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Tested-by:
Naama Meir <naamax.meir@linux.intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://lore.kernel.org/r/20240213184138.1483968-1-anthony.l.nguyen@intel.comSigned-off-by:
-
Kamal Heib authored
IS_ERR() is already using unlikely internally. Signed-off-by:
Kamal Heib <kheib@redhat.com> Acked-by:
Arthur Kiyanovski <akiyano@amazon.com> Link: https://lore.kernel.org/r/20240213161502.2297048-1-kheib@redhat.comSigned-off-by:
-
Ricardo B. Marliere authored
Since commit d492cc25 ("driver core: device.h: make struct bus_type a const *"), the driver core can properly handle constant struct bus_type, move the mdio_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ricardo B. Marliere <ricardo@marliere.net> Reviewed-by:
-
Shigeru Yoshida authored
Consolidate the error paths of tipc_nl_bearer_add() under the common label if the function holds rtnl_lock. Signed-off-by:
Shigeru Yoshida <syoshida@redhat.com> Reviewed-by:
Tung Nguyen <tung.q.nguyen@dektech.com.au> Link: https://lore.kernel.org/r/20240213134058.386123-1-syoshida@redhat.comSigned-off-by:
-
Christian Marangi authored
Add Aquantia AQR111 and AQR111B0 PHY ID. These PHY advertise 10G speed but actually supports up to 5G speed, hence some manual fixup is needed. The Aquantia AQR111B0 PHY is just a variant of the AQR111 with smaller chip size. Signed-off-by:
Christian Marangi <ansuelsmth@gmail.com> Reviewed-by:
-
Jason Xing authored
Since tcp_conn_request() always returns zero, there is no need to keep the dead code. Remove it then. Link: https://lore.kernel.org/netdev/CANn89iJwx9b2dUGUKFSV3PF=kN5o+kxz3A_fHZZsOS4AnXhBNw@mail.gmail.com/Suggested-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jason Xing <kernelxing@tencent.com> Reviewed-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://lore.kernel.org/r/20240213131205.4309-1-kerneljasonxing@gmail.comSigned-off-by:
-
Robert Marko authored
Currently, we are checking whether the PHY package mode matches the individual PHY interface modes at PHY package probe time, but at that time we only know the PHY package mode and not the individual PHY interface modes as of_get_phy_mode() that populates it will only get called once the netdev to which PHY-s are attached to is being probed and thus this check will always fail and return -EINVAL. So, lets move this check to .config_init_once as at that point individual PHY interface modes should be populated. Fixes: d1cb613e ("net: phy: qcom: add support for QCA807x PHY Family") Signed-off-by:
Robert Marko <robimarko@gmail.com> Reviewed-by:
-
- 14 Feb, 2024 30 commits
-
-
Catalin Popescu authored
DP83826 offers the possibility to tune the voltage of logical levels of the MLT-3 encoded TX data. This is useful when there is a voltage drop in between the PHY and the connector and we want to increase the voltage levels to compensate for that drop. Prior to PHY configuration, the driver SW resets the PHY which has the same effect as the HW reset pin according to the datasheet. Hence, there's no need to force update the VOD_CFG registers to make sure they hold their reset values. VOD_CFG registers need to be updated only if the DT has been configured with values other than the reset ones. Reviewed-by:
Catalin Popescu <catalin.popescu@leica-geosystems.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Catalin Popescu authored
Add properties ti,cfg-dac-minus-one-bp/ti,cfg-dac-plus-one-bp to support voltage tuning of logical levels -1/+1 of the MLT-3 encoded TX data. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
David S. Miller authored
Eric Dumazet says: ==================== net: complete dev_base_lock removal Back in 2009 we started an effort to get rid of dev_base_lock in favor of RCU. It is time to finish this work. Say goodbye to dev_base_lock ! v4: rebase, and move dev_addr_sem to net/core/dev.h in patch 06/13 (Jakub) v3: I misread kbot reports, the issue was with dev->operstate (patch 10/13) So dev->reg_state is back to u8, and dev->operstate becomes an u32. Sorry for the noise. v2: dev->reg_state must be a standard enum, some arches do not support cmpxchg() on u8. ==================== Signed-off-by: -
Eric Dumazet authored
dev_base_lock is not needed anymore, all remaining users also hold RTNL. Signed-off-by:
-
Eric Dumazet authored
RTNL already protects writes to dev->reg_state, we no longer need to hold dev_base_lock to protect the readers. unlist_netdevice() second argument can be removed. Signed-off-by:
-
Eric Dumazet authored
We hold RTNL here, and dev->link_mode readers already are using READ_ONCE(). Signed-off-by:
-
Eric Dumazet authored
dev_base_lock is going away, add netdev_set_operstate() helper so that hsr does not have to know core internals. Remove dev_base_lock acquisition from rfc2863_policy() v3: use an "unsigned int" for dev->operstate, so that try_cmpxchg() can work on all arches. ( https://lore.kernel.org/oe-kbuild-all/202402081918.OLyGaea3-lkp@intel.com/ ) Signed-off-by: -
Eric Dumazet authored
Change comments incorrectly mentioning dev_base_lock. Signed-off-by:
-
Eric Dumazet authored
dev_get_stats() can be called from RCU, there is no need to acquire dev_base_lock. Change dev_isalive() comment to reflect we no longer use dev_base_lock from net/core/net-sysfs.c Signed-off-by:
-
Eric Dumazet authored
operstate_show() can omit dev_base_lock acquisition only to read dev->operstate. Annotate accesses to dev->operstate. Writers still acquire dev_base_lock for mutual exclusion. Signed-off-by:
-
Eric Dumazet authored
Using dev_base_lock is not preventing from reading garbage. Use dev_addr_sem instead. v4: place dev_addr_sem extern in net/core/dev.h (Jakub Kicinski) Link: https://lore.kernel.org/netdev/20240212175845.10f6680a@kernel.org/Signed-off-by:
-
Eric Dumazet authored
Make clear dev_isalive() can be called with RCU protection. Then convert netdev_show() to RCU, to remove dev_base_lock dependency. Also add RCU to broadcast_show(). Signed-off-by:
-
Eric Dumazet authored
Prepares things so that dev->reg_state reads can be lockless, by adding WRITE_ONCE() on write side. READ_ONCE()/WRITE_ONCE() do not support bitfields. Signed-off-by:
-
Eric Dumazet authored
Following patch will read dev->link locklessly, annotate the write from do_setlink(). Signed-off-by:
-
Eric Dumazet authored
t->parms.link is read locklessly, annotate these reads and opposite writes accordingly. Signed-off-by:
-
Eric Dumazet authored
name_assign_type_show() runs locklessly, we should annotate accesses to dev->name_assign_type. Alternative would be to grab devnet_rename_sem semaphore from name_assign_type_show(), but this would not bring more accuracy. Signed-off-by:
-
David S. Miller authored
Joe Damato says: ==================== Per epoll context busy poll support Greetings: Welcome to v8. TL;DR This builds on commit bf3b9f63 ("epoll: Add busy poll support to epoll with socket fds.") by allowing user applications to enable epoll-based busy polling, set a busy poll packet budget, and enable or disable prefer busy poll on a per epoll context basis. This makes epoll-based busy polling much more usable for user applications than the current system-wide sysctl and hardcoded budget. To allow for this, two ioctls have been added for epoll contexts for getting and setting a new struct, struct epoll_params. ioctl was chosen vs a new syscall after reviewing a suggestion by Willem de Bruijn [1]. I am open to using a new syscall instead of an ioctl, but it seemed that: - Busy poll affects all existing epoll_wait and epoll_pwait variants in the same way, so new verions of many syscalls might be needed. It seems much simpler for users to use the correct epoll_wait/epoll_pwait for their app and add a call to ioctl to enable or disable busy poll as needed. This also probably means less work to get an existing epoll app using busy poll. - previously added epoll_pwait2 helped to bring epoll closer to existing syscalls (like pselect and ppoll) and this busy poll change reflected as a new syscall would not have the same effect. Note: patch 1/4 as of v4 uses an or (||) instead of an xor. I thought about it some more and I realized that if the user enables both the per-epoll context setting and the system wide sysctl, then busy poll should be enabled and not disabled. Using xor doesn't seem to make much sense after thinking through this a bit. Longer explanation: Presently epoll has support for a very useful form of busy poll based on the incoming NAPI ID (see also: SO_INCOMING_NAPI_ID [2]). This form of busy poll allows epoll_wait to drive NAPI packet processing which allows for a few interesting user application designs which can reduce latency and also potentially improve L2/L3 cache hit rates by deferring NAPI until userland has finished its work. The documentation available on this is, IMHO, a bit confusing so please allow me to explain how one might use this: 1. Ensure each application thread has its own epoll instance mapping 1-to-1 with NIC RX queues. An n-tuple filter would likely be used to direct connections with specific dest ports to these queues. 2. Optionally: Setup IRQ coalescing for the NIC RX queues where busy polling will occur. This can help avoid the userland app from being pre-empted by a hard IRQ while userland is running. Note this means that userland must take care to call epoll_wait and not take too long in userland since it now drives NAPI via epoll_wait. 3. Optionally: Consider using napi_defer_hard_irqs and gro_flush_timeout to further restrict IRQ generation from the NIC. These settings are system-wide so their impact must be carefully weighed against the running applications. 4. Ensure that all incoming connections added to an epoll instance have the same NAPI ID. This can be done with a BPF filter when SO_REUSEPORT is used or getsockopt + SO_INCOMING_NAPI_ID when a single accept thread is used which dispatches incoming connections to threads. 5. Lastly, busy poll must be enabled via a sysctl (/proc/sys/net/core/busy_poll). Please see Eric Dumazet's paper about busy polling [3] and a recent academic paper about measured performance improvements of busy polling [4] (albeit with a modification that is not currently present in the kernel) for additional context. The unfortunate part about step 5 above is that this enables busy poll system-wide which affects all user applications on the system, including epoll-based network applications which were not intended to be used this way or applications where increased CPU usage for lower latency network processing is unnecessary or not desirable. If the user wants to run one low latency epoll-based server application with epoll-based busy poll, but would like to run the rest of the applications on the system (which may also use epoll) without busy poll, this system-wide sysctl presents a significant problem. This change preserves the system-wide sysctl, but adds a mechanism (via ioctl) to enable or disable busy poll for epoll contexts as needed by individual applications, making epoll-based busy poll more usable. Note that this change includes an or (as of v4) instead of an xor. If the user has enabled both the system-wide sysctl and also the per epoll-context busy poll settings, then epoll should probably busy poll (vs being disabled). Thanks, Joe v7 -> v8: - Reviewed-by tag from Eric Dumazet applied to commit message of patch 1/4. - patch 4/4: - EPIOCSPARAMS and EPIOCGPARAMS updated to use WRITE_ONCE and READ_ONCE, as requested by Eric Dumazet - Wrapped a long line (via netdev/checkpatch) v6 -> v7: - Acked-by tags from Stanislav Fomichev applied to commit messages of all patches. - Reviewed-by tags from Jakub Kicinski, Eric Dumazet applied to commit messages of patches 2 and 3. Jiri Slaby's Reviewed-by applied to patch 4. - patch 1/4: - busy_poll_usecs reduced from u64 to u32. - Unnecessary parens removed (via netdev/checkpatch) - Wrapped long line (via netdev/checkpatch) - Remove inline from busy_loop_ep_timeout as objdump suggests the function is already inlined - Moved struct eventpoll assignment to declaration - busy_loop_ep_timeout is moved within CONFIG_NET_RX_BUSY_POLL and the ifdefs internally have been removed as per Eric Dumazet's review - Removed ep_busy_loop_on from the !defined CONFIG_NET_RX_BUSY_POLL section as it is only called when CONFIG_NET_RX_BUSY_POLL is defined - patch 3/4: - Fix whitespace alignment issue (via netdev/checkpatch) - patch 4/4: - epoll_params.busy_poll_usecs has been reduced to u32 - epoll_params.busy_poll_usecs is now checked to ensure it is <= S32_MAX - __pad has been reduced to a single u8 - memchr_inv has been dropped and replaced with a simple check for the single __pad byte - Removed space after cast (via netdev/checkpatch) - Wrap long line (via netdev/checkpatch) - Move struct eventpoll *ep assignment to declaration as per Jiri Slaby's review - Remove unnecessary !! as per Jiri Slaby's review - Reorganized variables to be reverse christmas tree order v5 -> v6: - patch 1/3 no functional change, but commit message corrected to explain that an or (||) is being used instead of xor. - patch 3/4 is a new patch which adds support for per epoll context prefer busy poll setting. - patch 4/4 updated to allow getting/setting per epoll context prefer busy poll setting; this setting is limited to either 0 or 1. v4 -> v5: - patch 3/3 updated to use memchr_inv to ensure that __pad is zero for the EPIOCSPARAMS ioctl. Recommended by Greg K-H [5], Dave Chinner [6], and Jiri Slaby [7]. v3 -> v4: - patch 1/3 was updated to include an important functional change: ep_busy_loop_on was updated to use or (||) instead of xor (^). After thinking about it a bit more, I thought xor didn't make much sense. Enabling both the per-epoll context and the system-wide sysctl should probably enable busy poll, not disable it. So, or (||) makes more sense, I think. - patch 3/3 was updated: - to change the epoll_params fields to be __u64, __u16, and __u8 and to pad the struct to a multiple of 64bits. Suggested by Greg K-H [8] and Arnd Bergmann [9]. - remove an unused pr_fmt, left over from the previous revision. - ioctl now returns -EINVAL when epoll_params.busy_poll_usecs > U32_MAX. v2 -> v3: - cover letter updated to mention why ioctl seems (to me) like a better choice vs a new syscall. - patch 3/4 was modified in 3 ways: - when an unknown ioctl is received, -ENOIOCTLCMD is returned instead of -EINVAL as the ioctl documentation requires. - epoll_params.busy_poll_budget can only be set to a value larger than NAPI_POLL_WEIGHT if code is run by privileged (CAP_NET_ADMIN) users. Otherwise, -EPERM is returned. - busy poll specific ioctl code moved out to its own function. On kernels without busy poll support, -EOPNOTSUPP is returned. This also makes the kernel build robot happier without littering the code with more #ifdefs. - dropped patch 4/4 after Eric Dumazet's review of it when it was sent independently to the list [10]. v1 -> v2: - cover letter updated to make a mention of napi_defer_hard_irqs and gro_flush_timeout as an added step 3 and to cite both Eric Dumazet's busy polling paper and a paper from University of Waterloo for additional context. Specifically calling out the xor in patch 1/4 incase it is missed by reviewers. - Patch 2/4 has its commit message updated, but no functional changes. Commit message now describes that allowing for a settable budget helps to improve throughput and is more consistent with other busy poll mechanisms that allow a settable budget via SO_BUSY_POLL_BUDGET. - Patch 3/4 was modified to check if the epoll_params.busy_poll_budget exceeds NAPI_POLL_WEIGHT. The larger value is allowed, but an error is printed. This was done for consistency with netif_napi_add_weight, which does the same. - Patch 3/4 the struct epoll_params was updated to fix the type of the data field; it was uint8_t and was changed to u8. - Patch 4/4 added to check if SO_BUSY_POLL_BUDGET exceeds NAPI_POLL_WEIGHT. The larger value is allowed, but an error is printed. This was done for consistency with netif_napi_add_weight, which does the same. ==================== Signed-off-by:
-
Joe Damato authored
Add an ioctl for getting and setting epoll_params. User programs can use this ioctl to get and set the busy poll usec time, packet budget, and prefer busy poll params for a specific epoll context. Parameters are limited: - busy_poll_usecs is limited to <= s32_max - busy_poll_budget is limited to <= NAPI_POLL_WEIGHT by unprivileged users (!capable(CAP_NET_ADMIN)) - prefer_busy_poll must be 0 or 1 - __pad must be 0 Signed-off-by:Joe Damato <jdamato@fastly.com> Acked-by:
Stanislav Fomichev <sdf@google.com> Reviewed-by:
Jiri Slaby <jirislaby@kernel.org> Reviewed-by:
-
Joe Damato authored
When using epoll-based busy poll, the prefer_busy_poll option is hardcoded to false. Users may want to enable prefer_busy_poll to be used in conjunction with gro_flush_timeout and defer_hard_irqs_count to keep device IRQs masked. Other busy poll methods allow enabling or disabling prefer busy poll via SO_PREFER_BUSY_POLL, but epoll-based busy polling uses a hardcoded value. Fix this edge case by adding support for a per-epoll context prefer_busy_poll option. The default is false, as it was hardcoded before this change. Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Reviewed-by:
-
Joe Damato authored
When using epoll-based busy poll, the packet budget is hardcoded to BUSY_POLL_BUDGET (8). Users may desire larger busy poll budgets, which can potentially increase throughput when busy polling under high network load. Other busy poll methods allow setting the busy poll budget via SO_BUSY_POLL_BUDGET, but epoll-based busy polling uses a hardcoded value. Fix this edge case by adding support for a per-epoll context busy poll packet budget. If not specified, the default value (BUSY_POLL_BUDGET) is used. Signed-off-by:
-
Joe Damato authored
Allow busy polling on a per-epoll context basis. The per-epoll context usec timeout value is preferred, but the pre-existing system wide sysctl value is still supported if it specified. busy_poll_usecs is a u32, but in a follow up patch the ioctl provided to the user only allows setting a value from 0 to S32_MAX. Signed-off-by:
-
Kamal Heib authored
There is no point in initializing an ndo to NULL, therefore the assignment is redundant and can be removed. Signed-off-by:
Brett Creeley <brett.creeley@amd.com> Acked-by:
-
Hariprasad Kelam authored
Packet ingress and egress MAC/serdes channel numbers are configurable on CN10K series of silicons. These channel numbers inturn used while installing MCAM rules to match ingress/egress port. Fetch these channel numbers from firmware at driver init time. Signed-off-by:
Hariprasad Kelam <hkelam@marvell.com> Signed-off-by:
Sunil Kovvuri Goutham <sgoutham@marvell.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueDavid S. Miller authored
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2024-02-12 (ice) This series contains updates to ice driver only. Grzegorz adds support for E825-C devices. Wojciech reworks devlink reload to fulfill expected conditions (remove and readd). ==================== Signed-off-by: -
David S. Miller authored
Merge tag 'linux-can-next-for-6.9-20240213' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== linux-can-next-for-6.9-20240213 this is a pull request of 23 patches for net-next/master. The first patch is by Nicolas Maier and targets the CAN Broadcast Manager (bcm), it adds message flags to distinguish between own local and remote traffic. Oliver Hartkopp contributes a patch for the CAN ISOTP protocol that adds dynamic flow control parameters. Stefan Mätje's patch series add support for the esd PCIe/402 CAN interface family. Markus Schneider-Pargmann contributes 14 patches for the m_can to optimize for the SPI attached tcan4x5x controller. A patch by Vincent Mailhol replaces Wolfgang Grandegger by Vincent Mailhol as the CAN drivers Co-Maintainer. Jimmy Assarsson's patch add support for the Kvaser M.2 PCIe 4xCAN adapter. A patch by Daniil Dulov removed a redundant NULL check in the softing driver. Oliver Hartkopp contributes a patch to add CANXL virtual CAN network identifier support. A patch by myself removes Naga Sureshkumar Relli as the maintainer of the xilinx_can driver, as their email bounces. ==================== Signed-off-by:
-
Jakub Kicinski authored
Lorenzo Bianconi says: ==================== add multi-buff support for xdp running in generic mode Introduce multi-buffer support for xdp running in generic mode not always linearizing the skb in netif_receive_generic_xdp routine. Introduce generic percpu page_pools allocator. ==================== Link: https://lore.kernel.org/r/cover.1707729884.git.lorenzo@kernel.orgSigned-off-by:
-
Lorenzo Bianconi authored
Rely on skb_pp_cow_data utility routine and remove duplicated code. Acked-by:
Jesper Dangaard Brouer <hawk@kernel.org> Reviewed-by:
Toke Hoiland-Jorgensen <toke@redhat.com> Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/029cc14cce41cb242ee7efdcf32acc81f1ce4e9f.1707729884.git.lorenzo@kernel.orgSigned-off-by:
-
Lorenzo Bianconi authored
Similar to native xdp, do not always linearize the skb in netif_receive_generic_xdp routine but create a non-linear xdp_buff to be processed by the eBPF program. This allow to add multi-buffer support for xdp running in generic mode. Acked-by:
-
Lorenzo Bianconi authored
Rely on skb pointer reference instead of the skb pointer in do_xdp_generic and netif_receive_generic_xdp routine signatures. This is a preliminary patch to add multi-buff support for xdp running in generic mode where we will need to reallocate the skb to avoid linearization and we will need to make it visible to do_xdp_generic() caller. Acked-by:
-
Lorenzo Bianconi authored
Introduce generic percpu page_pools allocator. Moreover add page_pool_create_percpu() and cpuid filed in page_pool struct in order to recycle the page in the page_pool "hot" cache if napi_pp_put_page() is running on the same cpu. This is a preliminary patch to add xdp multi-buff support for xdp running in generic mode. Acked-by:
-
