- 08 Aug, 2023 4 commits
-
-
Li Zetao authored
The fsl_mc_driver_register() will set "THIS_MODULE" to driver.owner when register a fsl_mc_driver driver, so it is redundant initialization to set driver.owner in dpaa2_eth_driver statement. Remove it for clean code. Signed-off-by:
Li Zetao <lizetao1@huawei.com> Reviewed-by:
Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20230804095946.99956-2-lizetao1@huawei.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Suman Ghosh says: ==================== octeontx2-af: TC flower offload changes This patchset includes minor code restructuring related to TC flower offload for outer vlan and adding support for TC inner vlan offload. Patch #1 Code restructure to handle TC flower outer vlan offload Patch #2 Add TC flower offload support for inner vlan ==================== Link: https://lore.kernel.org/r/20230804045935.3010554-1-sumang@marvell.comSigned-off-by:
-
Suman Ghosh authored
Extend the current TC flower offload support to enable filters matching inner VLAN, and support offload of those filters to hardware. Signed-off-by:
Suman Ghosh <sumang@marvell.com> Reviewed-by:
-
Suman Ghosh authored
Moved the TC outer VLAN offload support to a separate function. This change is done to handle all VLAN related changes cleanly from a dedicated function. Signed-off-by:
-
- 07 Aug, 2023 18 commits
-
-
Jakub Kicinski authored
Alexander Lobakin says: ==================== page_pool: a couple of assorted optimizations That initially was a spin-off of the IAVF PP series[0], but has grown (and shrunk) since then a bunch. In fact, it consists of three semi-independent blocks: * #1-2: Compile-time optimization. Split page_pool.h into 2 headers to not overbloat the consumers not needing complex inline helpers and then stop including it in skbuff.h at all. The first patch is also prereq for the whole series. * #3: Improve cacheline locality for users of the Page Pool frag API. * #4-6: Use direct cache recycling more aggressively, when it is safe obviously. In addition, make sure nobody wants to use Page Pool API with disabled interrupts. Patches #1 and #5 are authored by Yunsheng and Jakub respectively, with small modifications from my side as per ML discussions. For the perf numbers for #3-6, please see individual commit messages. Also available on my GH with many more Page Pool goodies[1]. [0] https://lore.kernel.org/netdev/20230530150035.1943669-1-aleksander.lobakin@intel.com [1] https://github.com/alobakin/linux/commits/iavf-pp-frag ==================== Link: https://lore.kernel.org/r/20230804180529.2483231-1-aleksander.lobakin@intel.comSigned-off-by:
-
Alexander Lobakin authored
Commit 8c48eea3 ("page_pool: allow caching from safely localized NAPI") allowed direct recycling of skb pages to their PP for some cases, but unfortunately missed a couple of other majors. For example, %XDP_DROP in skb mode. The netstack just calls kfree_skb(), which unconditionally passes `false` as @napi_safe. Thus, all pages go through ptr_ring and locks, although most of time we're actually inside the NAPI polling this PP is linked with, so that it would be perfectly safe to recycle pages directly. Let's address such. If @napi_safe is true, we're fine, don't change anything for this path. But if it's false, check whether we are in the softirq context. It will most likely be so and then if ->list_owner is our current CPU, we're good to use direct recycling, even though @napi_safe is false -- concurrent access is excluded. in_softirq() protection is needed mostly due to we can hit this place in the process context (not the hardirq though). For the mentioned xdp-drop-skb-mode case, the improvement I got is 3-4% in Mpps. As for page_pool stats, recycle_ring is now 0 and alloc_slow counter doesn't change most of time, which means the MM layer is not even called to allocate any new pages. Suggested-by: Jakub Kicinski <kuba@kernel.org> # in_softirq() Signed-off-by:
Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by:
Alexander Duyck <alexanderduyck@fb.com> Link: https://lore.kernel.org/r/20230804180529.2483231-7-aleksander.lobakin@intel.comSigned-off-by:
-
Jakub Kicinski authored
Page pool use in hardirq is prohibited, add debug checks to catch misuses. IIRC we previously discussed using DEBUG_NET_WARN_ON_ONCE() for this, but there were concerns that people will have DEBUG_NET enabled in perf testing. I don't think anyone enables lockdep in perf testing, so use lockdep to avoid pushback and arguing :) Acked-by:
Jesper Dangaard Brouer <hawk@kernel.org> Signed-off-by:
-
Alexander Lobakin authored
Currently, pp->p.napi is always read, but the actual variable it gets assigned to is read-only when @napi_safe is true. For the !napi_safe cases, which yet is still a pack, it's an unneeded operation. Moreover, it can lead to premature or even redundant page_pool cacheline access. For example, when page_pool_is_last_frag() returns false (with the recent frag improvements). Thus, read it only when @napi_safe is true. This also allows moving @napi inside the condition block itself. Constify it while we are here, because why not. Signed-off-by:
-
Alexander Lobakin authored
On x86_64, frag_* fields of struct page_pool are scattered across two cachelines despite the summary size of 24 bytes. All three fields are used in pretty much the same places, but the last field, ::frag_users, is pushed out to the next CL, provoking unwanted false-sharing on hotpath (frags allocation code). There are some holes and cold members to move around. Move frag_* one block up, placing them right after &page_pool_params perfectly at the beginning of CL2. This doesn't do any meaningful to the second block, as those are some destroy-path cold structures, and doesn't do anything to ::alloc_stats, which still starts at 200-byte offset, 8 bytes after CL3 (still fitting into 1 cacheline). On my setup, this yields 1-2% of Mpps when using PP frags actively. When it comes to 32-bit architectures with 32-byte CL: &page_pool_params plus ::pad is 44 bytes, the block taken care of is 16 bytes within one CL, so there should be at least no regressions from the actual change. ::pages_state_hold_cnt is not related directly to that triple, but is paired currently with ::frags_offset and decoupling them would mean either two 4-byte holes or more invasive layout changes. Signed-off-by:
-
Alexander Lobakin authored
Currently, touching <net/page_pool/types.h> triggers a rebuild of more than half of the kernel. That's because it's included in <linux/skbuff.h>. And each new include to page_pool/types.h adds more [useless] data for the toolchain to process per each source file from that pile. In commit 6a5bcd84 ("page_pool: Allow drivers to hint on SKB recycling"), Matteo included it to be able to call a couple of functions defined there. Then, in commit 57f05bc2 ("page_pool: keep pp info as long as page pool owns the page") one of the calls was removed, so only one was left. It's the call to page_pool_return_skb_page() in napi_frag_unref(). The function is external and doesn't have any dependencies. Having very niche page_pool_types.h included only for that looks like an overkill. As %PP_SIGNATURE is not local to page_pool.c (was only in the early submissions), nothing holds this function there. Teleport page_pool_return_skb_page() to skbuff.c, just next to the main consumer, skb_pp_recycle(), and rename it to napi_pp_put_page(), as it doesn't work with skbs at all and the former name tells nothing. The #if guards here are only to not compile and have it in the vmlinux when not needed -- both call sites are already guarded. Now, touching page_pool_types.h only triggers rebuilding of the drivers using it and a couple of core networking files. Suggested-by: Jakub Kicinski <kuba@kernel.org> # make skbuff.h less heavy Suggested-by: Alexander Duyck <alexanderduyck@fb.com> # move to skbuff.c Signed-off-by:
-
Yunsheng Lin authored
Split types and pure function declarations from page_pool.h and add them in page_page/types.h, so that C sources can include page_pool.h and headers should generally only include page_pool/types.h as suggested by jakub. Rename page_pool.h to page_pool/helpers.h to have both in one place. Signed-off-by:
Yunsheng Lin <linyunsheng@huawei.com> Suggested-by:
-
Jakub Kicinski authored
Merge tag 'linux-can-next-for-6.6-20230807' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2023-08-07 The patch is from me and reverts the addition of the CAN controller nodes in the allwinner d1 SoC. * tag 'linux-can-next-for-6.6-20230807' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: Revert "riscv: dts: allwinner: d1: Add CAN controller nodes" ==================== Link: https://lore.kernel.org/r/20230807074222.1576119-1-mkl@pengutronix.deSigned-off-by:
-
Jakub Kicinski authored
Johannes Zink says: ==================== net: stmmac: correct MAC propagation delay Changes in v3: - work in Richard's review feedback. Thank you for reviewing my patch: - as some of the hardware may have no or invalid correction value registers: introduce feature switch which can be enabled in the glue code drivers depending on the actual hardware support - only enable the feature on the i.MX8MP for the time being, as the patch improves timing accuracy and is tested for this hardware - Link to v2: https://lore.kernel.org/r/20230719-stmmac_correct_mac_delay-v2-1-3366f38ee9a6@pengutronix.de Changes in v2: - fix builds for 32bit, this was found by the kernel build bot Reported-by:kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202307200225.B8rmKQPN-lkp@intel.com/ - while at it also fix an overflow by shifting a u32 constant from macro by 10bits by casting the constant to u64 - Link to v1: https://lore.kernel.org/r/20230719-stmmac_correct_mac_delay-v1-1-768aa4d09334@pengutronix.de Tested-by: Kurt Kanzenbach <kurt@linutronix.de> # imx8mp ==================== Link: https://lore.kernel.org/r/20230719-stmmac_correct_mac_delay-v3-0-61e63427735e@pengutronix.deSigned-off-by:
-
Johannes Zink authored
As the i.MX8MP supports reading MAC propagation delay and correcting the Hardware timestamp counter for additional delays [1], enable the feature for this SoC. This reduces phase error of the PPS output from the PTP Hardware Clock from approx 150ns to 100ns. [1] i.MX8MP Reference Manual, rev.1 Section 11.7.2.5.3 "Timestamp correction" Signed-off-by:
Johannes Zink <j.zink@pengutronix.de> Link: https://lore.kernel.org/r/20230719-stmmac_correct_mac_delay-v3-2-61e63427735e@pengutronix.deSigned-off-by:
-
Johannes Zink authored
The IEEE1588 Standard specifies that the timestamps of Packets must be captured when the PTP message timestamp point (leading edge of first octet after the start of frame delimiter) crosses the boundary between the node and the network. As the MAC latches the timestamp at an internal point, the captured timestamp must be corrected for the additional data transmission latency, as described in the publicly available datasheet [1]. This patch only corrects for the MAC-Internal delay, which can be read out from the MAC_Ingress_Timestamp_Latency register on DWMAC version 5, since the Phy framework currently does not support querying the Phy ingress and egress latency. The Closs Domain Crossing Circuits errors as indicated in [1] are already being accounted in the stmmac_get_tx_hwtstamp() function and are not corrected here. As the Latency varies for different link speeds and MII modes of operation, the correction value needs to be updated on each link state change. As the delay also causes a phase shift in the timestamp counter compared to the rest of the network, this correction will also reduce phase error when generating PPS outputs from the timestamp counter. Since the correction registers may be unavailable on some hardware and no feature bits are documented for dynamically detection of the MAC propagation delay readout, introduce a feature bit to explicitely enable MAC delay Correction in the gluecode driver. [1] i.MX8MP Reference Manual, rev.1 Section 11.7.2.5.3 "Timestamp correction" Signed-off-by:
-
Yue Haibing authored
Commit 6ba5a3c5 ("[UDP]: Make full use of proto.h.udp_hash innovation.") removed these implementations but leave declarations. Signed-off-by:
Yue Haibing <yuehaibing@huawei.com> Reviewed-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Yue Haibing authored
Commit ce0aa27f ("sfp: add sfp-bus to bridge between network devices and sfp cages") declared but never implemented it. Signed-off-by:
-
Yue Haibing authored
Commit f8572d8f ("sysctl net: Remove unused binary sysctl code") left behind this declaration. Signed-off-by:
David Ahern <dsahern@kernel.org> Signed-off-by:
-
Yue Haibing authored
Commit acb67442 ("net: sched: introduce per-block callbacks") implemented these but never used it. Signed-off-by:
-
Yue Haibing authored
pneigh_for_each() is never implemented since the beginning of git history. Signed-off-by:
-
Yue Haibing authored
Commit 3c4d7559 ("tls: kernel TLS support") declared but never implemented these functions. Signed-off-by:
-
Marc Kleine-Budde authored
It turned out the dtsi changes were not quite ready, revert them for now. This reverts commit 6ea1ad88. Link: https://lore.kernel.org/all/2690764.mvXUDI8C0e@jernej-laptopSuggested-by:
Jernej Škrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/all/20230807-riscv-allwinner-d1-revert-can-controller-nodes-v1-1-eb3f70b435d9@pengutronix.deSigned-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
- 06 Aug, 2023 16 commits
-
-
Vladimir Oltean authored
Setting dev->priv_flags & IFF_SEE_ALL_HWTSTAMP_REQUESTS is only legal for drivers which were converted to ndo_hwtstamp_get() and ndo_hwtstamp_set(), and it is only there that we call ndo_hwtstamp_set() for a request that otherwise goes to phylib (for stuff like packet traps, which need to be undone if phylib failed, hence the old_cfg logic). The problem is that we end up calling ndo_hwtstamp_get() when we don't need to (even if the SIOCSHWTSTAMP wasn't intended for phylib, or if it was, but the driver didn't set IFF_SEE_ALL_HWTSTAMP_REQUESTS). For those unnecessary conditions, we share a code path with virtual drivers (vlan, macvlan, bonding) where ndo_hwtstamp_get() is implemented as generic_hwtstamp_get_lower(), and may be resolved through generic_hwtstamp_ioctl_lower() if the lower device is unconverted. I.e. this situation: $ ip link add link eno0 name eno0.100 type vlan id 100 $ hwstamp_ctl -i eno0.100 -t 1 We are unprepared to deal with this, because if ndo_hwtstamp_get() is resolved through a legacy ndo_eth_ioctl(SIOCGHWTSTAMP) lower_dev implementation, that needs a non-NULL old_cfg.ifr pointer, and we don't have it. But we don't even need to deal with it either. In the general case, drivers may not even implement SIOCGHWTSTAMP handling, only SIOCSHWTSTAMP, so it makes sense to completely avoid a SIOCGHWTSTAMP call if we can. The solution is to split the single "if" condition into 3 smaller ones, thus separating the decision to call ndo_hwtstamp_get() from the decision to call ndo_hwtstamp_set(). The third "if" condition is identical to the first one, and both are subsets of the second one. Thus, the "cfg" argument of kernel_hwtstamp_config_changed() is always valid. Reported-by:
Eric Dumazet <edumazet@google.com> Closes: https://lore.kernel.org/netdev/CANn89iLOspJsvjPj+y8jikg7erXDomWe8sqHMdfL_2LQSFrPAg@mail.gmail.com/ Fixes: fd770e85 ("net: remove phy_has_hwtstamp() -> phy_mii_ioctl() decision from converted drivers") Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Yang Yingliang authored
Use eth_broadcast_addr() to assign broadcast address instead of memset(). Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
-
Yu Liao authored
gcc with W=1 reports drivers/net/ethernet/ibm/ibmvnic.c:194:13: warning: variable 'rc' set but not used [-Wunused-but-set-variable] ^ This variable is not used so remove it. Reported-by:Yu Liao <liaoyu15@huawei.com> Reviewed-by:
Nick Child <nnac123@linux.ibm.com> Signed-off-by:
-
Haiyang Zhang authored
Add page pool for RX buffers for faster buffer cycle and reduce CPU usage. The standard page pool API is used. With iperf and 128 threads test, this patch improved the throughput by 12-15%, and decreased the IRQ associated CPU's usage from 99-100% to 10-50%. Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by:
-
David S. Miller authored
Rushil Gupta says: ==================== gve: Add QPL mode for DQO descriptor format GVE supports QPL ("queue-page-list") mode where all data is communicated through a set of pre-registered pages. Adding this mode to DQO. ==================== Signed-off-by: -
Rushil Gupta authored
Add a note about QPL and RDA mode Signed-off-by:
Rushil Gupta <rushilg@google.com> Reviewed-by:
Praveen Kaligineedi <pkaligineedi@google.com> Signed-off-by:
Bailey Forrest <bcf@google.com> Signed-off-by:
-
Rushil Gupta authored
The RX path allocates the QPL page pool at queue creation, and tries to reuse these pages through page recycling. This patch ensures that on refill no non-QPL pages are posted to the device. When the driver is running low on free buffers, an ondemand allocation step kicks in that allocates a non-qpl page for SKB business to free up the QPL page in use. gve_try_recycle_buf was moved to gve_rx_append_frags so that driver does not attempt to mark buffer as used if a non-qpl page was allocated ondemand. Signed-off-by:
-
Rushil Gupta authored
Each QPL page is divided into GVE_TX_BUFS_PER_PAGE_DQO buffers. When a packet needs to be transmitted, we break the packet into max GVE_TX_BUF_SIZE_DQO sized chunks and transmit each chunk using a TX descriptor. We allocate the TX buffers from the free list in dqo_tx. We store these TX buffer indices in an array in the pending_packet structure. The TX buffers are returned to the free list in dqo_compl after receiving packet completion or when removing packets from miss completions list. Signed-off-by:
-
Rushil Gupta authored
GVE supports QPL ("queue-page-list") mode where all data is communicated through a set of pre-registered pages. Adding this mode to DQO descriptor format. Add checks, abi-changes and device options to support QPL mode for DQO in addition to GQI. Also, use pages-per-qpl supplied by device-option to control the size of the "queue-page-list". Signed-off-by: -
David S. Miller authored
Eric Dumazet says: ==================== tcp: set few options locklessly This series is avoiding the socket lock for six TCP options. They are not heavily used, but this exercise can give ideas for other parts of TCP/IP stack :) ==================== Signed-off-by: -
Eric Dumazet authored
rskq_defer_accept field can be read/written without the need of holding the socket lock. Signed-off-by:
Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by:
-
Eric Dumazet authored
tp->linger2 can be set locklessly as long as readers use READ_ONCE(). Signed-off-by:
-
Eric Dumazet authored
tp->keepalive_probes can be set locklessly, readers are already taking care of this field being potentially set by other threads. Signed-off-by:
-
Eric Dumazet authored
tp->keepalive_intvl can be set locklessly, readers are already taking care of this field being potentially set by other threads. Signed-off-by:
-
Eric Dumazet authored
icsk->icsk_user_timeout can be set locklessly, if all read sides use READ_ONCE(). Signed-off-by:
-
Eric Dumazet authored
icsk->icsk_syn_retries can safely be set without locking the socket. We have to add READ_ONCE() annotations in tcp_fastopen_synack_timer() and tcp_write_timeout(). Signed-off-by:
-
- 05 Aug, 2023 2 commits
-
-
Jakub Kicinski authored
Merge tag 'wireless-next-2023-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.6 The first pull request for v6.6 and only driver patches this time. Nothing special really standing out, it has been quiet most likely due to vacations. Major changes: rtl8xxxu - enable AP mode for: RTL8192FU, RTL8710BU (RTL8188GU), RTL8192EU and RTL8723BU mwifiex - allow moving to a different namespace mt76 - preparation for mt7925 support - mt7981 support ath12k - Extremely High Throughput (EHT) PHY support for Wi-Fi 7 * tag 'wireless-next-2023-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (172 commits) wifi: rtw89: return failure if needed firmware elements are not recognized wifi: rtw89: add to parse firmware elements of BB and RF tables wifi: rtw89: introduce infrastructure of firmware elements wifi: rtw89: add firmware suit for BB MCU 0/1 wifi: rtw89: add firmware parser for v1 format wifi: rtw89: introduce v1 format of firmware header wifi: rtw89: support firmware log with formatted text wifi: rtw89: recognize log format from firmware file wifi: ath12k: avoid deadlock by change ieee80211_queue_work for regd_update_work wifi: ath12k: add handler for scan event WMI_SCAN_EVENT_DEQUEUED wifi: ath12k: relax list iteration in ath12k_mac_vif_unref() wifi: ath12k: configure puncturing bitmap wifi: ath12k: parse WMI service ready ext2 event wifi: ath12k: add MLO header in peer association wifi: ath12k: peer assoc for 320 MHz wifi: ath12k: add WMI support for EHT peer wifi: ath12k: prepare EHT peer assoc parameters wifi: ath12k: add EHT PHY modes wifi: ath12k: propagate EHT capabilities to userspace wifi: ath12k: WMI support to process EHT capabilities ... ==================== Link: https://lore.kernel.org/r/87msz7j942.fsf@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Kuniyuki Iwashima says: ==================== tcp: Disable header prediction for MD5. The 1st patch disable header prediction for MD5 flow and the 2nd patch updates the stale comment in tcp_parse_options(). ==================== Link: https://lore.kernel.org/r/20230803224552.69398-1-kuniyu@amazon.comSigned-off-by:
-
