* Re: [PATCH net-next v2 10/11] net: airoha: Do not stop GDM port if it is shared
From: Lorenzo Bianconi @ 2026-04-03 10:18 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew+netdev, davem, edumazet, pabeni, robh, krzk+dt, conor+dt,
ansuelsmth, benjamin.larsson, linux-arm-kernel, linux-mediatek,
netdev, devicetree
In-Reply-To: <20260403011229.1785808-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3201 bytes --]
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> net: airoha: Do not stop GDM port if it is shared
>
> This patch introduces a port->users reference counter to prevent setting
> the GDM port forward configuration to FE_PSE_PORT_DROP if another net_device
> is still using the shared GDM port.
>
> > diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> > index 0780fb8aacfb..3f9bce8c5370 100644
> > --- a/drivers/net/ethernet/airoha/airoha_eth.c
> > +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> [ ... ]
> > @@ -1681,9 +1682,6 @@ static int airoha_dev_stop(struct net_device *netdev)
> > for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++)
> > netdev_tx_reset_subqueue(netdev, i);
> >
> > - airoha_set_gdm_port_fwd_cfg(qdma->eth, REG_GDM_FWD_CFG(port->id),
> > - FE_PSE_PORT_DROP);
> > -
> > if (atomic_dec_and_test(&qdma->users)) {
> > airoha_qdma_clear(qdma, REG_QDMA_GLOBAL_CFG,
> > GLOBAL_CFG_TX_DMA_EN_MASK |
>
> While this patch aims to support shared GDM ports, does the remaining
> unconditional call to airoha_set_vip_for_gdm_port(dev, false) at the start
> of airoha_dev_stop() break other active devices sharing the port?
>
> static int airoha_dev_stop(struct net_device *netdev)
> {
> ...
> err = airoha_set_vip_for_gdm_port(dev, false);
> ...
> }
>
> This appears to clear the REG_FE_VIP_PORT_EN and REG_FE_IFC_PORT_EN hardware
> bits for the physical port, which might instantly kill traffic for any other
> active interface using the shared port.
>
> Similarly, in airoha_dev_open() and airoha_dev_change_mtu(), the
> REG_GDM_LEN_CFG (MTU) is overwritten unconditionally. If a device with a
> smaller MTU is brought up, will it overwrite the shared port's MTU limit
> and cause the hardware to silently drop larger packets for the other device?
ack, I will fix it in v3.
>
> [ ... ]
> > @@ -1697,6 +1695,11 @@ static int airoha_dev_stop(struct net_device *netdev)
> > }
> > }
> >
> > + if (atomic_dec_and_test(&port->users))
> > + airoha_set_gdm_port_fwd_cfg(qdma->eth,
> > + REG_GDM_FWD_CFG(port->id),
> > + FE_PSE_PORT_DROP);
> > +
> > return 0;
> > }
>
> Does moving this FE_PSE_PORT_DROP configuration to the end of airoha_dev_stop()
> cause a race condition when stopping the device?
>
> In airoha_dev_open(), the driver correctly enables the QDMA engine before
> configuring the GDM port to forward packets. A safe teardown typically
> mirrors this by first stopping the packet source (setting FE_PSE_PORT_DROP)
> and then disabling the destination DMA engine.
>
> By moving airoha_set_gdm_port_fwd_cfg() after the airoha_qdma_clear() block,
> when both qdma->users and port->users reach zero, the QDMA engine and its
> queues are shut down while the GDM port is still actively forwarding packets.
>
> Could incoming packets be forwarded to a disabled DMA engine during this
> window, risking hardware lockups or buffer leaks?
ack, I will fix it in v3.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 09/11] net: airoha: Support multiple net_devices for a single FE GDM port
From: Lorenzo Bianconi @ 2026-04-03 10:18 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew+netdev, davem, edumazet, pabeni, robh, krzk+dt, conor+dt,
ansuelsmth, benjamin.larsson, linux-arm-kernel, linux-mediatek,
netdev, devicetree
In-Reply-To: <20260403011208.1784815-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 8019 bytes --]
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> Subject: net: airoha: Support multiple net_devices for a single FE GDM port
>
> This commit introduces support for multiple net_devices connected to the
> same Frame Engine (FE) GDM port via an external hardware arbiter. It
> adds logic to parse device tree child nodes and instantiate separate
> net_devices for TDM traffic from external SerDes.
>
> > diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> > index 5e489e8593ba..0780fb8aacfb 100644
> > --- a/drivers/net/ethernet/airoha/airoha_eth.c
> > +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> [ ... ]
> > @@ -614,9 +616,8 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
> > u32 hash, reason, msg1 = le32_to_cpu(desc->msg1);
> > struct page *page = virt_to_head_page(e->buf);
> > u32 desc_ctrl = le32_to_cpu(desc->ctrl);
> > - struct airoha_gdm_port *port;
> > - struct net_device *netdev;
> > - int data_len, len, p;
> > + struct airoha_gdm_dev *dev;
> > + int data_len, len;
> >
> > if (!(desc_ctrl & QDMA_DESC_DONE_MASK))
> > break;
> > @@ -633,12 +634,10 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
> > if (!len || data_len < len)
> > goto free_frag;
> >
> > - p = airoha_qdma_get_gdm_port(eth, desc);
> > - if (p < 0 || !eth->ports[p])
> > + dev = airoha_qdma_get_gdm_dev(eth, desc);
> > + if (IS_ERR(dev))
> > goto free_frag;
>
> If a scattered frame is being processed (q->skb is not NULL) and IS_ERR(dev)
> triggers the goto free_frag, the error handler frees the skb:
>
> free_frag:
> if (q->skb) {
> dev_kfree_skb(q->skb);
> q->skb = NULL;
> } else {
> page_pool_put_full_page(q->page_pool, page, true);
> }
>
> Since the current fragment's page is not yet attached to q->skb, does this
> skip the else branch and permanently leak the page pool buffer?
This issue is fixed in the following net patch (not merged yet):
https://lore.kernel.org/netdev/20260402-airoha_qdma_rx_process-mem-leak-fix-v1-1-b5706f402d3c@kernel.org/
>
> [ ... ]
> > @@ -1747,9 +1748,7 @@ static int airoha_set_gdm2_loopback(struct airoha_gdm_dev *dev)
> > airoha_fe_clear(eth, REG_FE_VIP_PORT_EN, BIT(AIROHA_GDM2_IDX));
> > airoha_fe_clear(eth, REG_FE_IFC_PORT_EN, BIT(AIROHA_GDM2_IDX));
> >
> > - /* XXX: handle XSI_USB_PORT and XSI_PCE1_PORT */
> > - nbq = port->id == AIROHA_GDM3_IDX && airoha_is_7581(eth) ? 4 : 0;
> > - src_port = eth->soc->ops.get_src_port_id(port, nbq);
> > + src_port = eth->soc->ops.get_src_port_id(port, dev->nbq);
> > if (src_port < 0)
> > return src_port;
>
> With multiple net_devices instantiated for the same physical GDM port, does
> the initialization of sibling devices overwrite shared hardware registers?
>
> For example, when airoha_set_gdm2_loopback() uses src_port to configure
> REG_FE_WAN_PORT, it explicitly clears the WAN port routing masks:
>
> airoha_fe_rmw(eth, REG_FE_WAN_PORT,
> WAN1_EN_MASK | WAN1_MASK | WAN0_MASK,
> FIELD_PREP(WAN0_MASK, src_port));
>
> Will the last initialized device clobber the WAN routing configurations and
> hardware MAC filters for the others, causing their traffic to be dropped?
ack, I will fix it in v3.
>
> [ ... ]
> > @@ -1970,7 +1969,8 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> > }
> >
> > fport = airoha_get_fe_port(dev);
> > - msg1 = FIELD_PREP(QDMA_ETH_TXMSG_FPORT_MASK, fport) |
> > + msg1 = FIELD_PREP(QDMA_ETH_TXMSG_NBOQ_MASK, dev->nbq) |
> > + FIELD_PREP(QDMA_ETH_TXMSG_FPORT_MASK, fport) |
> > FIELD_PREP(QDMA_ETH_TXMSG_METER_MASK, 0x7f);
> >
> > q = &qdma->q_tx[qid];
>
> When multiple net_devices share a single QDMA instance and its TX rings
> (qdma->q_tx), a TX queue stall might occur here.
>
> If the shared hardware ring fills up, netif_tx_stop_queue() stops the
> transmitting device's queue. Later, when descriptors are freed, the driver
> only wakes the queue corresponding to the specific packet that just completed.
>
> If multiple devices' TX queues are stopped, will the other devices' queues
> remain stalled unless their specific packets happen to be processed?
This does not seem strictly related to this series. I will look into it in a
dedicated patch.
>
> [ ... ]
> > @@ -2897,10 +2900,11 @@ bool airoha_is_valid_gdm_dev(struct airoha_eth *eth,
> >
> > static int airoha_alloc_gdm_device(struct airoha_eth *eth,
> > struct airoha_gdm_port *port,
> > - struct device_node *np)
> > + int nbq, struct device_node *np)
> > {
> > - struct airoha_gdm_dev *dev;
> > struct net_device *netdev;
> > + struct airoha_gdm_dev *dev;
> > + u8 index;
> > int err;
> [ ... ]
> > + /* Allowed nbq for EN7581 on GDM3 port are 4 and 5 for PCIE0
> > + * and PCIE1 respectively.
> > + */
> > + index = nbq;
> > + if (airoha_is_7581(eth) && port->id == AIROHA_GDM3_IDX)
> > + index -= 4;
> > +
> > + if (index >= ARRAY_SIZE(port->devs) || port->devs[index]) {
> > + dev_err(eth->dev, "invalid nbq id: %d\n", nbq);
> > + return -EINVAL;
> > + }
>
> There are two potential issues regarding the new index logic:
>
> First, does this break probing for older device trees without child nodes?
> When falling back to airoha_alloc_gdm_device(..., 0, np) with nbq = 0,
> the index -= 4 operation for AIROHA_GDM3_IDX will cause the u8 index to
> underflow to 252. The bounds check 252 >= 2 fails, returning -EINVAL.
ack, I will fix it in v3.
>
> Second, can an invalid device tree value bypass the bounds check?
> The int nbq parameter is directly assigned to the u8 index. If a large value
> like reg = <256> is provided, it truncates to 0, passing the index >= 2
> check. The un-truncated int nbq is then stored in dev->nbq, potentially
> causing out-of-bounds shifts when used in hardware macros.
ack, I will fix it in v3.
>
> [ ... ]
> > @@ -2986,7 +3004,36 @@ static int airoha_alloc_gdm_port(struct airoha_eth *eth,
> > if (err)
> > return err;
> >
> > - return airoha_alloc_gdm_device(eth, port, np);
> > + for_each_child_of_node(np, node) {
> > + /* Multiple external serdes connected to the FE GDM port via an
> > + * external arbiter.
> > + */
> > + const __be32 *nbq_ptr;
> > +
> > + if (!of_device_is_compatible(node, "airoha,eth-port"))
> > + continue;
> > +
> > + d++;
> > + if (!of_device_is_available(node))
> > + continue;
> > +
> > + nbq_ptr = of_get_property(node, "reg", NULL);
> > + if (!nbq_ptr) {
> > + dev_err(eth->dev, "missing nbq id\n");
> > + err = -EINVAL;
> > + of_node_put(node);
> > + break;
> > + }
> > +
> > + err = airoha_alloc_gdm_device(eth, port, be32_to_cpup(nbq_ptr),
> > + node);
> > + if (err) {
> > + of_node_put(node);
> > + return err;
> > + }
> > + }
> > +
> > + return !d ? airoha_alloc_gdm_device(eth, port, 0, np) : 0;
> > }
>
> If nbq_ptr is missing, err = -EINVAL is set and the loop breaks. However,
> since the child counter d was already incremented, the final statement
> evaluates to 0 (success) because !d is false.
>
> Does this swallow the -EINVAL error and cause a silent failure where the
> driver continues probing without initializing the misconfigured GDM devices?
>
> Additionally, the for_each_child_of_node() iterator automatically handles
> taking and dropping the reference to node.
>
> When node is passed to airoha_alloc_gdm_device(), it is directly assigned:
> netdev->dev.of_node = np;
>
> Since of_node_get() is not called, when the loop iteration finishes and drops
> the reference, does this leave the net_device pointing to a freed device
> tree node?
ack, I will fix it in v3.
Regards,
Lorenzo
> --
> pw-bot: cr
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] vsock: avoid timeout for non-blocking accept() with empty backlog
From: Stefano Garzarella @ 2026-04-03 10:04 UTC (permalink / raw)
To: Laurence Rowe; +Cc: virtualization, netdev, Bobby Eshleman
In-Reply-To: <CAOycyLR-otKw4jTcNpo3pUBbDx9DVJyPU7b0T6uHib6mSrAvVg@mail.gmail.com>
On Thu, Apr 02, 2026 at 04:30:20PM -0700, Laurence Rowe wrote:
>On Thu, Apr 2, 2026 at 12:22 PM Laurence Rowe <laurencerowe@gmail.com> wrote:
>>
>> On Thu, Apr 2, 2026 at 5:03 AM Stefano Garzarella <sgarzare@redhat.com> wrote:
>>
>> > >Scheduling a timeout for a non-blocking accept with an empty backlog
>> > >meant AF_VSOCK sockets used by epoll network servers incurred hundreds
>> > >of microseconds of additional latency per accept loop compared to
>> > >AF_INET or AF_UNIX sockets.
>> >
>> > Not related to this patch, but should we do something similar (in
>> > another patch) also in vsock_connect() or doesn't matter since usually
>> > it's always blocking?
>>
>> Looking at vsock_connect it's not immediately obvious to me whether it
>> is affected
>> in the same way. I'll capture some ftraces and follow up after
>> updating this patch.
>
>This does not seem to be a problem for vsock_connect since it checks
>for `if (flags & O_NONBLOCK) {` in the while loop before calling
>`schedule_timeout`.
>
>Timings and ftraces:
>
>https://github.com/lrowe/linux-vsock-accept-timeout-investigation?tab=readme-ov-file#a-quick-look-at-connect
Thanks for checking and for the fix!
Stefano
^ permalink raw reply
* Re: [PATCH iwl-next] ixgbe: fix integer overflow and wrong bit position in ixgbe_validate_rtr()
From: David Laight @ 2026-04-03 10:00 UTC (permalink / raw)
To: Aleksandr Loktionov; +Cc: intel-wired-lan, anthony.l.nguyen, netdev
In-Reply-To: <20260327073046.134085-10-aleksandr.loktionov@intel.com>
On Fri, 27 Mar 2026 08:30:44 +0100
Aleksandr Loktionov <aleksandr.loktionov@intel.com> wrote:
> Two bugs in the same loop in ixgbe_validate_rtr():
>
> 1. When extracting 3-bit traffic class values from the IXGBE_RTRUP2TC
> register the shifted value was assigned directly to a u8, silently
> truncating any bits above bit 7. Mask with IXGBE_RTRUP2TC_UP_MASK
> before the assignment so only the intended 3 bits are kept.
>
> 2. When clearing an out-of-bounds entry the mask was always shifted by
> the fixed constant IXGBE_RTRUP2TC_UP_SHIFT (== 3), regardless of
> which loop iteration was being processed. This means only the entry
> at bit position 3 was ever cleared; entries at bit positions 0, 6, 9,
> ..., 21 were left unreset. Use i * IXGBE_RTRUP2TC_UP_SHIFT to target
> the correct field for each iteration.
>
> Also replace the hardcoded 0x7 literal with the IXGBE_RTRUP2TC_UP_MASK
> constant for consistency with other parts of the driver.
>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 9aec66c..53b82a5 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -9798,11 +9798,12 @@ static void ixgbe_validate_rtr(struct ixgbe_adapter *adapter, u8 tc)
> rsave = reg;
>
> for (i = 0; i < MAX_TRAFFIC_CLASS; i++) {
> - u8 up2tc = reg >> (i * IXGBE_RTRUP2TC_UP_SHIFT);
> + u8 up2tc = IXGBE_RTRUP2TC_UP_MASK &
> + (reg >> (i * IXGBE_RTRUP2TC_UP_SHIFT));
That really ought to be the opposite way round: expr & constant.
Or add a second line to mask the value.
David
>
> /* If up2tc is out of bounds default to zero */
> if (up2tc > tc)
> - reg &= ~(0x7 << IXGBE_RTRUP2TC_UP_SHIFT);
> + reg &= ~(IXGBE_RTRUP2TC_UP_MASK << (i * IXGBE_RTRUP2TC_UP_SHIFT));
> }
>
> if (reg != rsave)
^ permalink raw reply
* Re: [PATCH net] bridge: guard local VLAN-0 FDB helpers against NULL vlan group
From: Ido Schimmel @ 2026-04-03 9:56 UTC (permalink / raw)
To: Zijing Yin
Cc: netdev, bridge, razor, davem, edumazet, kuba, pabeni, horms,
nathan, nick.desaulniers+lkml, morbo, justinstitt, petrm,
linux-kernel, llvm
In-Reply-To: <20260402140153.3925663-1-yzjaurora@gmail.com>
On Thu, Apr 02, 2026 at 07:01:53AM -0700, Zijing Yin wrote:
> When CONFIG_BRIDGE_VLAN_FILTERING is not set, br_vlan_group() and
> nbp_vlan_group() return NULL (br_private.h stub definitions). The
> BR_BOOLOPT_FDB_LOCAL_VLAN_0 toggle code is compiled unconditionally and
> reaches br_fdb_delete_locals_per_vlan_port() and
> br_fdb_insert_locals_per_vlan_port(), where the NULL vlan group pointer
> is dereferenced via list_for_each_entry(v, &vg->vlan_list, vlist).
>
> The observed crash is in the delete path, triggered when creating a
> bridge with IFLA_BR_MULTI_BOOLOPT containing BR_BOOLOPT_FDB_LOCAL_VLAN_0
> via RTM_NEWLINK. The insert helper has the same bug pattern.
>
> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000056: 0000 [#1] KASAN NOPTI
> KASAN: null-ptr-deref in range [0x00000000000002b0-0x00000000000002b7]
> RIP: 0010:br_fdb_delete_locals_per_vlan+0x2b9/0x310
> Call Trace:
> br_fdb_toggle_local_vlan_0+0x452/0x4c0
> br_toggle_fdb_local_vlan_0+0x31/0x80 net/bridge/br.c:276
> br_boolopt_toggle net/bridge/br.c:313
> br_boolopt_multi_toggle net/bridge/br.c:364
> br_changelink net/bridge/br_netlink.c:1542
> br_dev_newlink net/bridge/br_netlink.c:1575
>
> Add NULL checks for the vlan group pointer in both helpers, returning
> early when there are no VLANs to iterate. This matches the existing
> pattern used by other bridge FDB functions such as br_fdb_add() and
> br_fdb_delete().
>
> Fixes: 21446c06b441 ("net: bridge: Introduce UAPI for BR_BOOLOPT_FDB_LOCAL_VLAN_0")
> Signed-off-by: Zijing Yin <yzjaurora@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
^ permalink raw reply
* Re: [PATCH 3/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Fidelio LAWSON @ 2026-04-03 9:43 UTC (permalink / raw)
To: Andrew Lunn
Cc: Woojung Huh, UNGLinuxDriver, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Marek Vasut, Maxime Chevallier,
netdev, devicetree, linux-kernel, Fidelio Lawson
In-Reply-To: <ab6a06c1-2d7d-4032-8d38-063470cd45c0@lunn.ch>
On 3/26/26 13:18, Andrew Lunn wrote:
>> + mutex_lock(&dev->alu_mutex);
>> +
>> + ret = ksz_write8(dev, regs[REG_IND_CTRL_0], 0xA0);
>> +
>> + if (!ret)
>> + ret = ksz_write8(dev, 0x6F, indir_reg);
>> +
>> + if (!ret)
>> + ret = ksz_write8(dev, regs[REG_IND_BYTE], indir_val);
>> +
>> + mutex_unlock(&dev->alu_mutex);
>
> What address space are these registers in? Normally workarounds for a
> PHY would be in the PHY driver. But that assumes the registers are
> accessible from the PHY driver.
>
> Andrew
Hi Andrew,
These registers belong to the KSZ87xx switch address space, accessed
through the switch’s indirect access mechanism. In particular, the
offsets used here correspond to entries within the TABLE_LINK_MD_V
indirect table of the KSZ8-family switches.
In the next revision I will switch to using ksz8_ind_write8(), and I
will also replace the remaining magic values with proper register macros.
Best regards,
Fidelio
^ permalink raw reply
* Re: [PATCH 2/2 net v3] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
From: Ido Schimmel @ 2026-04-03 9:41 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: netdev, petrm, horms, pabeni, kuba, edumazet, davem, dsahern,
kees, Yiming Qian
In-Reply-To: <20260402072613.25262-2-fmancera@suse.de>
On Thu, Apr 02, 2026 at 09:26:13AM +0200, Fernando Fernandez Mancera wrote:
> When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently
> allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for
> single nexthops and small Equal-Cost Multi-Path groups, this fixed
> allocation fails for large nexthop groups like 512 nexthops.
>
> This results in the following warning splat:
>
> WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608
> [...]
> RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395)
> [...]
> Call Trace:
> <TASK>
> rtnetlink_rcv_msg (net/core/rtnetlink.c:6989)
> netlink_rcv_skb (net/netlink/af_netlink.c:2550)
> netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)
> netlink_sendmsg (net/netlink/af_netlink.c:1894)
> ____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585)
> ___sys_sendmsg (net/socket.c:2641)
> __sys_sendmsg (net/socket.c:2671)
> do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
> </TASK>
>
> Fix this by allocating the size dynamically using nh_nlmsg_size() and
> using nlmsg_new(), this is consistent with nexthop_notify() behavior. In
> addition, adjust nh_nlmsg_size_grp() so it calculates the size needed
> based on flags passed. While at it, also add the size of NHA_FDB for
> nexthop group size calculation as it was missing too.
>
> This cannot be reproduced via iproute2 as the group size is currently
> limited and the command fails as follows:
>
> addattr_l ERROR: message exceeded bound of 1048
>
> Fixes: 430a049190de ("nexthop: Add support for nexthop groups")
> Reported-by: Yiming Qian <yimingqian591@gmail.com>
> Closes: https://lore.kernel.org/netdev/CAL_bE8Li2h4KO+AQFXW4S6Yb_u5X4oSKnkywW+LPFjuErhqELA@mail.gmail.com/
> Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
> Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
^ permalink raw reply
* Re: [PATCH v3 11/15] media: qcom: Switch to generic PAS TZ APIs
From: Jorge Ramirez @ 2026-04-03 9:37 UTC (permalink / raw)
To: Sumit Garg
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, andersson,
konradybcio, robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo,
lumag, abhinav.kumar, jesszhan0024, marijn.suijten, airlied,
simona, vikash.garodia, dikshita.agarwal, bod, mchehab, elder,
andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, mukesh.ojha, pavan.kondeti,
jorge.ramirez, tonyh, vignesh.viswanathan, srinivas.kandagatla,
amirreza.zarrabi, jens.wiklander, op-tee, apurupa, skare,
harshal.dev, linux-kernel, Sumit Garg
In-Reply-To: <20260327131043.627120-12-sumit.garg@kernel.org>
On 27/03/26 18:40:39, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Switch qcom media client drivers over to generic PAS TZ APIs. Generic PAS
> TZ service allows to support multiple TZ implementation backends like QTEE
> based SCM PAS service, OP-TEE based PAS service and any further future TZ
> backend service.
OP-TEE based PAS service relies on the linux driver to configure the
iommu (just as it is done on the no_tz case). This generic patch does
not cover that requirement.
Because of that, it is probably better if the commit message doesnt
mention OP-TEE and instead maybe indicate that PAS wll support TEEs that
implement the same restrictions that QTEE (ie, iommu configuration).
I can send an RFC for OP-TEE support based on the integration work being
carried out here [1]
[1] https://github.com/OP-TEE/optee_os/pull/7721#discussion_r3016923507
>
> Along with that pass proper PAS ID to set_remote_state API. As per testing
> the SCM backend just ignores it while OP-TEE makes use of it to for proper
> book keeping purpose.
>
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/Kconfig | 25 ++++++++++---------
> .../media/platform/qcom/iris/iris_firmware.c | 9 ++++---
> drivers/media/platform/qcom/venus/Kconfig | 1 +
> drivers/media/platform/qcom/venus/firmware.c | 11 ++++----
> 4 files changed, 25 insertions(+), 21 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 3/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Fidelio LAWSON @ 2026-04-03 9:35 UTC (permalink / raw)
To: Vladimir Oltean, Bastien Curutchet
Cc: Woojung Huh, UNGLinuxDriver, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Marek Vasut, Maxime Chevallier,
netdev, devicetree, linux-kernel, Fidelio Lawson
In-Reply-To: <20260326094211.hdaf4tz7lbjyjznn@skbuf>
On 3/26/26 10:42, Vladimir Oltean wrote:
> On Thu, Mar 26, 2026 at 10:10:23AM +0100, Fidelio Lawson wrote:
>> Implement the "Module 3: Equalizer fix for short cables" erratum from
>> Microchip document DS80000687C for KSZ87xx switches.
>>
>> The issue affects short or low-loss cable links (e.g. CAT5e/CAT6),
>> where the PHY receiver equalizer may amplify high-amplitude signals
>> excessively, resulting in internal distortion and link establishment
>> failures.
>>
>> Depending on the selected workaround (1 or 2), the driver writes a
>> specific value to the indirect PHY register
>> using the 6E/6F/A0 indirect access mechanism.
>>
>> The errata fix is applied during global switch initialization when
>> enabled via device tree.
>>
>> Signed-off-by: Fidelio Lawson <fidelio.lawson@exotec.com>
>> ---
>> drivers/net/dsa/microchip/ksz8.c | 46 ++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 46 insertions(+)
>>
>> diff --git a/drivers/net/dsa/microchip/ksz8.c b/drivers/net/dsa/microchip/ksz8.c
>> index 78b42cf50ce2..b6f3a1ce85fc 100644
>> --- a/drivers/net/dsa/microchip/ksz8.c
>> +++ b/drivers/net/dsa/microchip/ksz8.c
>> @@ -1901,6 +1901,41 @@ void ksz8_phylink_mac_link_up(struct phylink_config *config,
>> ksz8_phy_port_link_up(dev, port, duplex, tx_pause, rx_pause);
>> }
>>
>> +static int ksz8_handle_module3_errata(struct ksz_device *dev)
>> +{
>> + int ret = 0;
>
> "ret" does not need to be zero-initialized. It is unconditionally
> overwritten by ksz_write8().
>
> And please sort lines with variable declarations in decreasing line
> length order. Netdev calls this "reverse Christmas tree" ordering and is
> the preferred coding style.
>
>> + const u16 *regs = dev->info->regs;
>> + u16 indir_reg = 0x0000;
>> + u8 indir_val = 0x00;
>> +
>> + switch (dev->low_loss_wa_mode) {
>> + case KSZ_LOW_LOSS_WA_1:
>> + indir_reg = 0x3C;
>> + indir_val = 0x15;
>> + break;
>> + case KSZ_LOW_LOSS_WA_2:
>> + indir_reg = 0x4C;
>> + indir_val = 0x40;
>
> Do the 3c and 4c registers have any associated documentation? Do we know
> what they are or what they do? We should have some macros for them,
> instead of magic numbers.
>
>> + break;
>> + default:
>> + break;
>
> Is it expected that in the default case (no workaround), the code flow
> writes indir_val = 0x00 to indir_reg = 0x0000? Or would it be better to
> just exit early without making any change?
>
>> + }
>> +
>> + mutex_lock(&dev->alu_mutex);
>> +
>> + ret = ksz_write8(dev, regs[REG_IND_CTRL_0], 0xA0);
>> +
>> + if (!ret)
>> + ret = ksz_write8(dev, 0x6F, indir_reg);
>> +
>> + if (!ret)
>> + ret = ksz_write8(dev, regs[REG_IND_BYTE], indir_val);
>
> Is this sequence better suited for ksz8_ind_write8()? Perhaps wrapped in
> another layer similar to ksz8_pme_write8(), once we know what the magic
> numbers represent in terms of indirect table?
>
>> +
>> + mutex_unlock(&dev->alu_mutex);
>> +
>> + return ret;
>> +}
>> +
>> static int ksz8_handle_global_errata(struct dsa_switch *ds)
>> {
>> struct ksz_device *dev = ds->priv;
>> @@ -1915,6 +1950,17 @@ static int ksz8_handle_global_errata(struct dsa_switch *ds)
>> if (dev->info->ksz87xx_eee_link_erratum)
>> ret = ksz8_ind_write8(dev, TABLE_EEE, REG_IND_EEE_GLOB2_HI, 0);
>>
>> + /* KSZ87xx Errata DS80000687C.
>> + * Module 3: Equalizer fix for short cables
>> + * The receiver of the embedded PHYs is tuned by default
>> + * to support long cable length applications.
>> + * Because of this, the equalizer in the PHY may amplify
>> + * high amplitude receiver signals to the point that
>> + * the signal is distorted internally
>> + */
>> + if (!ret && dev->low_loss_wa_enable && ksz_is_ksz87xx(dev))
>> + ret = ksz8_handle_module3_errata(dev);
>> +
>> return ret;
>> }
>>
>>
>> --
>> 2.53.0
>>
>
> FYI, the driver is in a restructuring process. The ksz88xx_switch_ops
> will be split out of the common ksz_switch_ops. This will conflict with
> your series, so you should rebase on top of that much larger set.
> You can coordinate with Bastien Curutchet to see what is the status:
> https://lore.kernel.org/netdev/20260313153849.qkfzv5c2u6fepjku@skbuf
Hi Vladimir,
Thanks for the review and for the detailed feedback!
I’ll apply your suggestions in the next version of the patch.
Thanks again for the guidance.
Best regards,
Fidelio
^ permalink raw reply
* [PATCH net] vsock/test: fix send_buf()/recv_buf() EINTR handling
From: Stefano Garzarella @ 2026-04-03 9:32 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Arseniy Krasnov, linux-kernel,
Stefano Garzarella, virtualization
From: Stefano Garzarella <sgarzare@redhat.com>
When send() or recv() returns -1 with errno == EINTR, the code skips
the break but still adds the return value to nwritten/nread, making it
decrease by 1. This leads to wrong buffer offsets and wrong bytes count.
Fix it by explicitly continuing the loop on EINTR, so the return value
is only added when it is positive.
Fixes: a8ed71a27ef5 ("vsock/test: add recv_buf() utility function")
Fixes: 12329bd51fdc ("vsock/test: add send_buf() utility function")
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
---
tools/testing/vsock/util.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/testing/vsock/util.c b/tools/testing/vsock/util.c
index 9430ef5b8bc3..1fe1338c79cd 100644
--- a/tools/testing/vsock/util.c
+++ b/tools/testing/vsock/util.c
@@ -344,7 +344,9 @@ void send_buf(int fd, const void *buf, size_t len, int flags,
ret = send(fd, buf + nwritten, len - nwritten, flags);
timeout_check("send");
- if (ret == 0 || (ret < 0 && errno != EINTR))
+ if (ret < 0 && errno == EINTR)
+ continue;
+ if (ret <= 0)
break;
nwritten += ret;
@@ -396,7 +398,9 @@ void recv_buf(int fd, void *buf, size_t len, int flags, ssize_t expected_ret)
ret = recv(fd, buf + nread, len - nread, flags);
timeout_check("recv");
- if (ret == 0 || (ret < 0 && errno != EINTR))
+ if (ret < 0 && errno == EINTR)
+ continue;
+ if (ret <= 0)
break;
nread += ret;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 1/1] Bluetooth: serialize accept_q access
From: Paul Menzel @ 2026-04-03 9:27 UTC (permalink / raw)
To: Ren Wei
Cc: linux-bluetooth, netdev, marcel, luiz.dentz, davem, edumazet,
kuba, pabeni, horms, yifanwucs, tomapufckgml, yuantan098, bird,
enjou1224z, wangjiexun2025
In-Reply-To: <06a6b4549acba207847ce532dedbf1c95ab22d13.1774925231.git.wangjiexun2025@gmail.com>
Dear Ren,
Thank you for your patch.
Am 03.04.26 um 10:05 schrieb Ren Wei:
> From: Jiexun Wang <wangjiexun2025@gmail.com>
>
> bt_sock_poll() walks the accept queue without synchronization, while
> child teardown can unlink the same socket and drop its last reference.
>
> Protect accept_q with a dedicated lock for queue updates and polling.
> Also rework bt_accept_dequeue() to take temporary child references under
> the queue lock before dropping it and locking the child socket.
>
> Fixes: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ("Linux-2.6.12-rc2")
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Co-developed-by: Yuan Tan <yuantan098@gmail.com>
> Signed-off-by: Yuan Tan <yuantan098@gmail.com>
> Suggested-by: Xin Liu <bird@lzu.edu.cn>
> Tested-by: Ren Wei <enjou1224z@gmail.com>
> Signed-off-by: Jiexun Wang <wangjiexun2025@gmail.com>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
> ---
> Changes in v2:
> - add Tested-by: Ren Wei <enjou1224z@gmail.com>
> - resend to the public Bluetooth/netdev lists
>
> include/net/bluetooth/bluetooth.h | 1 +
> net/bluetooth/af_bluetooth.c | 85 +++++++++++++++++++++++--------
> 2 files changed, 66 insertions(+), 20 deletions(-)
>
> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> index 69eed69f7f26..3faea66b1979 100644
> --- a/include/net/bluetooth/bluetooth.h
> +++ b/include/net/bluetooth/bluetooth.h
> @@ -398,6 +398,7 @@ void baswap(bdaddr_t *dst, const bdaddr_t *src);
> struct bt_sock {
> struct sock sk;
> struct list_head accept_q;
> + spinlock_t accept_q_lock; /* protects accept_q */
> struct sock *parent;
> unsigned long flags;
> void (*skb_msg_name)(struct sk_buff *, void *, int *);
> diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
> index 2b94e2077203..f44e1ecc83d8 100644
> --- a/net/bluetooth/af_bluetooth.c
> +++ b/net/bluetooth/af_bluetooth.c
> @@ -154,6 +154,7 @@ struct sock *bt_sock_alloc(struct net *net, struct socket *sock,
>
> sock_init_data(sock, sk);
> INIT_LIST_HEAD(&bt_sk(sk)->accept_q);
> + spin_lock_init(&bt_sk(sk)->accept_q_lock);
>
> sock_reset_flag(sk, SOCK_ZAPPED);
>
> @@ -214,6 +215,7 @@ void bt_accept_enqueue(struct sock *parent, struct sock *sk, bool bh)
> {
> const struct cred *old_cred;
> struct pid *old_pid;
> + struct bt_sock *par = bt_sk(parent);
>
> BT_DBG("parent %p, sk %p", parent, sk);
>
> @@ -224,9 +226,12 @@ void bt_accept_enqueue(struct sock *parent, struct sock *sk, bool bh)
> else
> lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
>
> - list_add_tail(&bt_sk(sk)->accept_q, &bt_sk(parent)->accept_q);
> bt_sk(sk)->parent = parent;
>
> + spin_lock_bh(&par->accept_q_lock);
> + list_add_tail(&bt_sk(sk)->accept_q, &par->accept_q);
> + spin_unlock_bh(&par->accept_q_lock);
> +
> /* Copy credentials from parent since for incoming connections the
> * socket is allocated by the kernel.
> */
> @@ -254,45 +259,73 @@ EXPORT_SYMBOL(bt_accept_enqueue);
> */
> void bt_accept_unlink(struct sock *sk)
> {
> + struct sock *parent = bt_sk(sk)->parent;
> +
> BT_DBG("sk %p state %d", sk, sk->sk_state);
>
> + spin_lock_bh(&bt_sk(parent)->accept_q_lock);
> list_del_init(&bt_sk(sk)->accept_q);
> - sk_acceptq_removed(bt_sk(sk)->parent);
> + spin_unlock_bh(&bt_sk(parent)->accept_q_lock);
> +
> + sk_acceptq_removed(parent);
> bt_sk(sk)->parent = NULL;
> sock_put(sk);
> }
> EXPORT_SYMBOL(bt_accept_unlink);
>
> +static struct sock *bt_accept_get(struct sock *parent, struct sock *sk)
> +{
> + struct bt_sock *bt = bt_sk(parent);
> + struct sock *next = NULL;
> +
> + /* accept_q is modified from child teardown paths too, so take a
> + * temporary reference before dropping the queue lock.
> + */
> + spin_lock_bh(&bt->accept_q_lock);
> +
> + if (sk) {
> + if (bt_sk(sk)->parent != parent)
> + goto out;
> +
> + if (!list_is_last(&bt_sk(sk)->accept_q, &bt->accept_q)) {
> + next = &list_next_entry(bt_sk(sk), accept_q)->sk;
> + sock_hold(next);
> + }
> + } else if (!list_empty(&bt->accept_q)) {
> + next = &list_first_entry(&bt->accept_q,
> + struct bt_sock, accept_q)->sk;
> + sock_hold(next);
> + }
> +
> +out:
> + spin_unlock_bh(&bt->accept_q_lock);
> + return next;
> +}
> +
> struct sock *bt_accept_dequeue(struct sock *parent, struct socket *newsock)
> {
> - struct bt_sock *s, *n;
> - struct sock *sk;
> + struct sock *sk, *next;
>
> BT_DBG("parent %p", parent);
>
> restart:
> - list_for_each_entry_safe(s, n, &bt_sk(parent)->accept_q, accept_q) {
> - sk = (struct sock *)s;
> -
> + for (sk = bt_accept_get(parent, NULL); sk; sk = next) {
> /* Prevent early freeing of sk due to unlink and sock_kill */
> - sock_hold(sk);
> lock_sock(sk);
>
> /* Check sk has not already been unlinked via
> * bt_accept_unlink() due to serialisation caused by sk locking
> */
> - if (!bt_sk(sk)->parent) {
> + if (bt_sk(sk)->parent != parent) {
> BT_DBG("sk %p, already unlinked", sk);
> release_sock(sk);
> sock_put(sk);
>
> - /* Restart the loop as sk is no longer in the list
> - * and also avoid a potential infinite loop because
> - * list_for_each_entry_safe() is not thread safe.
> - */
> goto restart;
> }
>
> + next = bt_accept_get(parent, sk);
> +
> /* sk is safely in the parent list so reduce reference count */
> sock_put(sk);
>
> @@ -310,6 +343,8 @@ struct sock *bt_accept_dequeue(struct sock *parent, struct socket *newsock)
> sock_graft(sk, newsock);
>
> release_sock(sk);
> + if (next)
> + sock_put(next);
> return sk;
> }
>
> @@ -518,18 +553,28 @@ EXPORT_SYMBOL(bt_sock_stream_recvmsg);
>
> static inline __poll_t bt_accept_poll(struct sock *parent)
> {
> - struct bt_sock *s, *n;
> + struct bt_sock *bt = bt_sk(parent);
> + struct bt_sock *s;
> struct sock *sk;
> + __poll_t mask = 0;
> +
> + spin_lock_bh(&bt->accept_q_lock);
> + list_for_each_entry(s, &bt->accept_q, accept_q) {
> + int state;
>
> - list_for_each_entry_safe(s, n, &bt_sk(parent)->accept_q, accept_q) {
> sk = (struct sock *)s;
> - if (sk->sk_state == BT_CONNECTED ||
> - (test_bit(BT_SK_DEFER_SETUP, &bt_sk(parent)->flags) &&
> - sk->sk_state == BT_CONNECT2))
> - return EPOLLIN | EPOLLRDNORM;
> + state = READ_ONCE(sk->sk_state);
> +
> + if (state == BT_CONNECTED ||
> + (test_bit(BT_SK_DEFER_SETUP, &bt->flags) &&
> + state == BT_CONNECT2)) {
> + mask = EPOLLIN | EPOLLRDNORM;
> + break;
> + }
> }
> + spin_unlock_bh(&bt->accept_q_lock);
>
> - return 0;
> + return mask;
> }
>
> __poll_t bt_sock_poll(struct file *file, struct socket *sock,
Google’s Gemini review service has a comment [1]. Do you think it’s
valid and related?
Kind regards,
Paul
[1]:
https://sashiko.dev/#/patchset/06a6b4549acba207847ce532dedbf1c95ab22d13.1774925231.git.wangjiexun2025%40gmail.com
^ permalink raw reply
* [PATCH net-next] net/mlx5: Update the list of the PCI supported devices
From: Tariq Toukan @ 2026-04-03 9:17 UTC (permalink / raw)
To: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch, netdev,
linux-rdma, linux-kernel, Gal Pressman, Michael Guralnik, stable,
Patrisious Haddad
From: Michael Guralnik <michaelgur@nvidia.com>
Add the upcoming ConnectX-10 NVLink-C2C device ID to the table of
supported PCI device IDs.
Cc: stable@vger.kernel.org
Signed-off-by: Michael Guralnik <michaelgur@nvidia.com>
Reviewed-by: Patrisious Haddad <phaddad@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index dc7f20a357d9..a8fa85430e33 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -2285,6 +2285,7 @@ static const struct pci_device_id mlx5_core_pci_table[] = {
{ PCI_VDEVICE(MELLANOX, 0x1023) }, /* ConnectX-8 */
{ PCI_VDEVICE(MELLANOX, 0x1025) }, /* ConnectX-9 */
{ PCI_VDEVICE(MELLANOX, 0x1027) }, /* ConnectX-10 */
+ { PCI_VDEVICE(MELLANOX, 0x2101) }, /* ConnectX-10 NVLink-C2C */
{ PCI_VDEVICE(MELLANOX, 0xa2d2) }, /* BlueField integrated ConnectX-5 network controller */
{ PCI_VDEVICE(MELLANOX, 0xa2d3), MLX5_PCI_DEV_IS_VF}, /* BlueField integrated ConnectX-5 network controller VF */
{ PCI_VDEVICE(MELLANOX, 0xa2d6) }, /* BlueField-2 integrated ConnectX-6 Dx network controller */
base-commit: 8b0e64d6c9e7feec5ba5643b4fa8b7fd54464778
--
2.44.0
^ permalink raw reply related
* Re: [PATCH net] ice: fix locking around wait_event_interruptible_locked_irq
From: Simon Horman @ 2026-04-03 9:11 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Jacob Keller,
Jakub Kicinski
In-Reply-To: <20260327072332.130320-2-aleksandr.loktionov@intel.com>
On Fri, Mar 27, 2026 at 08:23:25AM +0100, Aleksandr Loktionov wrote:
> From: Jacob Keller <jacob.e.keller@intel.com>
>
> Commit 50327223a8bb ("ice: add lock to protect low latency interface")
> introduced a wait queue used to protect the low latency timer interface.
> The queue is used with the wait_event_interruptible_locked_irq macro, which
> unlocks the wait queue lock while sleeping. The irq variant uses
> spin_lock_irq and spin_unlock_irq to manage this. The wait queue lock was
> previously locked using spin_lock_irqsave. This difference in lock variants
> could lead to issues, since wait_event would unlock the wait queue and
> restore interrupts while sleeping.
>
> The ice_read_phy_tstamp_ll_e810() function is ultimately called through
> ice_read_phy_tstamp, which is called from ice_ptp_process_tx_tstamp or
> ice_ptp_clear_unexpected_tx_ready. The former is called through the
> miscellaneous IRQ thread function, while the latter is called from the
> service task work queue thread. Neither of these functions has interrupts
> disabled, so use spin_lock_irq instead of spin_lock_irqsave.
>
> Fixes: 50327223a8bb ("ice: add lock to protect low latency interface")
> Cc: stable@vger.kernel.org
> Reported-by: Jakub Kicinski <kuba@kernel.org>
> Closes: https://lore.kernel.org/netdev/20250109181823.77f44c69@kernel.org/
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* [PATCH net-next V2 5/5] net/mlx5e: XDP, Use page fragments for linear data in multibuf-mode
From: Tariq Toukan @ 2026-04-03 9:09 UTC (permalink / raw)
To: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Dragos Tatulea, Cosmin Ratiu,
Simon Horman, Jacob Keller, Lama Kayal, Michal Swiatkowski,
Carolina Jubran, Nathan Chancellor, Daniel Zahka,
Rahul Rameshbabu, Raed Salem, netdev, linux-rdma, linux-kernel,
bpf, Gal Pressman
In-Reply-To: <20260403090927.139042-1-tariqt@nvidia.com>
From: Dragos Tatulea <dtatulea@nvidia.com>
Currently in XDP multi-buffer mode for striding rq a whole page is
allocated for the linear part of the XDP buffer. This is wasteful,
especially on systems with larger page sizes.
This change splits the page into fixed sized fragments. The page is
replenished when the maximum number of allowed fragments is reached.
When a fragment is not used, it will be simply recycled on next packet.
This is great for XDP_DROP as the fragment can be recycled for the next
packet. In the most extreme case (XDP_DROP everything), there will be 0
fragments used => only one linear page allocation for the lifetime of
the XDP program.
The previous page_pool size increase was too conservative (doubling the
size) and now there are much fewer allocations (1/8 for a 4K page). So
drop the page_pool size extension altogether when the linear side page
is used.
This small improvement is at most visible for XDP_DROP tests with small
64B packets and a large enough MTU for Striding RQ to be in non-linear
mode:
+----------------------------------------------------------------------+
| System | MTU | baseline | this change | improvement |
|----------------------+------+------------+-------------+-------------|
| 4K page x86_64 [1] | 9000 | 26.30 Mpps | 30.45 Mpps | 15.80 % |
| 64K page aarch64 [2] | 9000 | 15.27 Mpps | 20.10 Mpps | 31.62 % |
+----------------------------------------------------------------------+
[1] Intel Xeon Platinum 8580
[2] ARM Neoverse-N1
Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en.h | 6 ++
.../net/ethernet/mellanox/mlx5/core/en_main.c | 25 ++++++--
.../net/ethernet/mellanox/mlx5/core/en_rx.c | 60 +++++++++++++++----
3 files changed, 74 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h b/drivers/net/ethernet/mellanox/mlx5/core/en.h
index 592234780f2b..2270e2e550dd 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@ -82,6 +82,9 @@ struct page_pool;
#define MLX5E_PAGECNT_BIAS_MAX U16_MAX
#define MLX5E_RX_MAX_HEAD (256)
+#define MLX5E_XDP_LOG_MAX_LINEAR_SZ \
+ order_base_2(MLX5_SKB_FRAG_SZ(XDP_PACKET_HEADROOM + MLX5E_RX_MAX_HEAD))
+
#define MLX5E_SHAMPO_LOG_HEADER_ENTRY_SIZE (8)
#define MLX5E_SHAMPO_WQ_HEADER_PER_PAGE \
(PAGE_SIZE >> MLX5E_SHAMPO_LOG_HEADER_ENTRY_SIZE)
@@ -596,6 +599,7 @@ struct mlx5e_mpw_info {
struct mlx5e_mpw_linear_info {
struct mlx5e_frag_page frag_page;
+ u16 max_frags;
};
#define MLX5E_MAX_RX_FRAGS 4
@@ -1081,6 +1085,8 @@ bool mlx5e_reset_rx_moderation(struct dim_cq_moder *cq_moder, u8 cq_period_mode,
bool mlx5e_reset_rx_channels_moderation(struct mlx5e_channels *chs, u8 cq_period_mode,
bool dim_enabled, bool keep_dim_state);
+void mlx5e_mpwqe_dealloc_linear_page(struct mlx5e_rq *rq);
+
struct mlx5e_sq_param;
int mlx5e_open_xdpsq(struct mlx5e_channel *c, struct mlx5e_params *params,
struct mlx5e_sq_param *param, struct xsk_buff_pool *xsk_pool,
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index aa8359a48b12..4ba198fb9d6c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -371,11 +371,11 @@ static int mlx5e_rq_alloc_mpwqe_info(struct mlx5e_rq *rq, int node)
static int mlx5e_rq_alloc_mpwqe_linear_info(struct mlx5e_rq *rq, int node,
struct mlx5e_params *params,
- struct mlx5e_rq_opt_param *rqo,
- u32 *pool_size)
+ struct mlx5e_rq_opt_param *rqo)
{
struct mlx5_core_dev *mdev = rq->mdev;
struct mlx5e_mpw_linear_info *li;
+ u32 linear_frag_count;
if (mlx5e_rx_mpwqe_is_linear_skb(mdev, params, rqo) ||
!params->xdp_prog)
@@ -385,10 +385,22 @@ static int mlx5e_rq_alloc_mpwqe_linear_info(struct mlx5e_rq *rq, int node,
if (!li)
return -ENOMEM;
+ linear_frag_count =
+ BIT(rq->mpwqe.page_shift - MLX5E_XDP_LOG_MAX_LINEAR_SZ);
+ if (linear_frag_count > U16_MAX) {
+ netdev_warn(rq->netdev,
+ "rq %d: linear_frag_count (%u) larger than expected (%u), page_shift: %u, log_max_linear_sz: %u\n",
+ rq->ix, linear_frag_count, U16_MAX,
+ rq->mpwqe.page_shift, MLX5E_XDP_LOG_MAX_LINEAR_SZ);
+ kvfree(li);
+ return -EINVAL;
+ }
+
+ li->max_frags = linear_frag_count;
rq->mpwqe.linear_info = li;
- /* additional page per packet for the linear part */
- *pool_size *= 2;
+ /* Set to max to force allocation on first run. */
+ li->frag_page.frags = li->max_frags;
return 0;
}
@@ -955,8 +967,7 @@ static int mlx5e_alloc_rq(struct mlx5e_params *params,
if (err)
goto err_rq_mkey;
- err = mlx5e_rq_alloc_mpwqe_linear_info(rq, node, params, rqo,
- &pool_size);
+ err = mlx5e_rq_alloc_mpwqe_linear_info(rq, node, params, rqo);
if (err)
goto err_free_mpwqe_info;
@@ -1347,6 +1358,8 @@ void mlx5e_free_rx_descs(struct mlx5e_rq *rq)
mlx5_wq_ll_pop(wq, wqe_ix_be,
&wqe->next.next_wqe_index);
}
+
+ mlx5e_mpwqe_dealloc_linear_page(rq);
} else {
struct mlx5_wq_cyc *wq = &rq->wqe.wq;
u16 missing = mlx5_wq_cyc_missing(wq);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index feb042d84b8e..5b60aa47c75b 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
@@ -300,6 +300,35 @@ static void mlx5e_page_release_fragmented(struct page_pool *pp,
page_pool_put_unrefed_netmem(pp, netmem, -1, true);
}
+static int mlx5e_mpwqe_linear_page_refill(struct mlx5e_rq *rq)
+{
+ struct mlx5e_mpw_linear_info *li = rq->mpwqe.linear_info;
+
+ if (likely(li->frag_page.frags < li->max_frags))
+ return 0;
+
+ if (likely(li->frag_page.netmem)) {
+ mlx5e_page_release_fragmented(rq->page_pool, &li->frag_page);
+ li->frag_page.netmem = 0;
+ }
+
+ return mlx5e_page_alloc_fragmented(rq->page_pool, &li->frag_page);
+}
+
+static void *mlx5e_mpwqe_get_linear_page_frag(struct mlx5e_rq *rq)
+{
+ struct mlx5e_mpw_linear_info *li = rq->mpwqe.linear_info;
+ u32 frag_offset;
+
+ if (unlikely(mlx5e_mpwqe_linear_page_refill(rq)))
+ return NULL;
+
+ frag_offset = li->frag_page.frags << MLX5E_XDP_LOG_MAX_LINEAR_SZ;
+ WARN_ON(frag_offset >= BIT(rq->mpwqe.page_shift));
+
+ return netmem_address(li->frag_page.netmem) + frag_offset;
+}
+
static inline int mlx5e_get_rx_frag(struct mlx5e_rq *rq,
struct mlx5e_wqe_frag_info *frag)
{
@@ -702,6 +731,22 @@ static void mlx5e_dealloc_rx_mpwqe(struct mlx5e_rq *rq, u16 ix)
bitmap_fill(wi->skip_release_bitmap, rq->mpwqe.pages_per_wqe);
}
+void mlx5e_mpwqe_dealloc_linear_page(struct mlx5e_rq *rq)
+{
+ struct mlx5e_mpw_linear_info *li = rq->mpwqe.linear_info;
+
+ if (!li || !li->frag_page.netmem)
+ return;
+
+ mlx5e_page_release_fragmented(rq->page_pool, &li->frag_page);
+
+ /* Recovery flow can call this function and then alloc again, so leave
+ * things in a good state for re-allocation.
+ */
+ li->frag_page.netmem = 0;
+ li->frag_page.frags = li->max_frags;
+}
+
INDIRECT_CALLABLE_SCOPE bool mlx5e_post_rx_wqes(struct mlx5e_rq *rq)
{
struct mlx5_wq_cyc *wq = &rq->wqe.wq;
@@ -1899,18 +1944,17 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *w
/* area for bpf_xdp_[store|load]_bytes */
net_prefetchw(netmem_address(frag_page->netmem) + frag_offset);
- linear_page = &rq->mpwqe.linear_info->frag_page;
- if (unlikely(mlx5e_page_alloc_fragmented(rq->page_pool,
- linear_page))) {
+ va = mlx5e_mpwqe_get_linear_page_frag(rq);
+ if (!va) {
rq->stats->buff_alloc_err++;
return NULL;
}
- va = netmem_address(linear_page->netmem);
net_prefetchw(va); /* xdp_frame data area */
linear_hr = XDP_PACKET_HEADROOM;
linear_data_len = 0;
linear_frame_sz = MLX5_SKB_FRAG_SZ(linear_hr + MLX5E_RX_MAX_HEAD);
+ linear_page = &rq->mpwqe.linear_info->frag_page;
} else {
skb = napi_alloc_skb(rq->cq.napi,
ALIGN(MLX5E_RX_MAX_HEAD, sizeof(long)));
@@ -1971,8 +2015,6 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *w
linear_page->frags++;
}
- mlx5e_page_release_fragmented(rq->page_pool,
- linear_page);
return NULL; /* page/packet was consumed by XDP */
}
@@ -1989,15 +2031,11 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *w
rq, mxbuf->xdp.data_hard_start, linear_frame_sz,
mxbuf->xdp.data - mxbuf->xdp.data_hard_start, len,
mxbuf->xdp.data - mxbuf->xdp.data_meta);
- if (unlikely(!skb)) {
- mlx5e_page_release_fragmented(rq->page_pool,
- linear_page);
+ if (unlikely(!skb))
return NULL;
- }
skb_mark_for_recycle(skb);
linear_page->frags++;
- mlx5e_page_release_fragmented(rq->page_pool, linear_page);
if (xdp_buff_has_frags(&mxbuf->xdp)) {
struct mlx5e_frag_page *pagep;
--
2.44.0
^ permalink raw reply related
* [PATCH net-next V2 4/5] net/mlx5e: XDP, Use a single linear page per rq
From: Tariq Toukan @ 2026-04-03 9:09 UTC (permalink / raw)
To: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Dragos Tatulea, Cosmin Ratiu,
Simon Horman, Jacob Keller, Lama Kayal, Michal Swiatkowski,
Carolina Jubran, Nathan Chancellor, Daniel Zahka,
Rahul Rameshbabu, Raed Salem, netdev, linux-rdma, linux-kernel,
bpf, Gal Pressman
In-Reply-To: <20260403090927.139042-1-tariqt@nvidia.com>
From: Dragos Tatulea <dtatulea@nvidia.com>
Currently in striding rq there is one mlx5e_frag_page member per WQE for
the linear page. This linear page is used only in XDP multi-buffer mode.
This is wasteful because only one linear page is needed per rq: the page
gets refreshed on every packet, regardless of WQE. Furthermore, it is
not needed in other modes (non-XDP, XDP single-buffer).
This change moves the linear page into its own structure (struct
mlx5_mpw_linear_info) and allocates it only when necessary.
A special structure is created because an upcoming patch will extend
this structure to support fragmentation of the linear page.
This patch has no functional changes.
Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en.h | 6 ++-
.../net/ethernet/mellanox/mlx5/core/en_main.c | 37 ++++++++++++++++---
.../net/ethernet/mellanox/mlx5/core/en_rx.c | 17 +++++----
3 files changed, 47 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h b/drivers/net/ethernet/mellanox/mlx5/core/en.h
index c7ac6ebe8290..592234780f2b 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@ -591,10 +591,13 @@ union mlx5e_alloc_units {
struct mlx5e_mpw_info {
u16 consumed_strides;
DECLARE_BITMAP(skip_release_bitmap, MLX5_MPWRQ_MAX_PAGES_PER_WQE);
- struct mlx5e_frag_page linear_page;
union mlx5e_alloc_units alloc_units;
};
+struct mlx5e_mpw_linear_info {
+ struct mlx5e_frag_page frag_page;
+};
+
#define MLX5E_MAX_RX_FRAGS 4
struct mlx5e_rq;
@@ -689,6 +692,7 @@ struct mlx5e_rq {
u8 umr_wqebbs;
u8 mtts_per_wqe;
u8 umr_mode;
+ struct mlx5e_mpw_linear_info *linear_info;
struct mlx5e_shampo_hd *shampo;
} mpwqe;
};
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 1238e5356012..aa8359a48b12 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -369,6 +369,29 @@ static int mlx5e_rq_alloc_mpwqe_info(struct mlx5e_rq *rq, int node)
return 0;
}
+static int mlx5e_rq_alloc_mpwqe_linear_info(struct mlx5e_rq *rq, int node,
+ struct mlx5e_params *params,
+ struct mlx5e_rq_opt_param *rqo,
+ u32 *pool_size)
+{
+ struct mlx5_core_dev *mdev = rq->mdev;
+ struct mlx5e_mpw_linear_info *li;
+
+ if (mlx5e_rx_mpwqe_is_linear_skb(mdev, params, rqo) ||
+ !params->xdp_prog)
+ return 0;
+
+ li = kvzalloc_node(sizeof(*li), GFP_KERNEL, node);
+ if (!li)
+ return -ENOMEM;
+
+ rq->mpwqe.linear_info = li;
+
+ /* additional page per packet for the linear part */
+ *pool_size *= 2;
+
+ return 0;
+}
static u8 mlx5e_mpwrq_access_mode(enum mlx5e_mpwrq_umr_mode umr_mode)
{
@@ -915,10 +938,6 @@ static int mlx5e_alloc_rq(struct mlx5e_params *params,
mlx5e_mpwqe_get_log_rq_size(mdev, params, rqo);
pool_order = rq->mpwqe.page_shift - PAGE_SHIFT;
- if (!mlx5e_rx_mpwqe_is_linear_skb(mdev, params, rqo) &&
- params->xdp_prog)
- pool_size *= 2; /* additional page per packet for the linear part */
-
rq->mpwqe.log_stride_sz =
mlx5e_mpwqe_get_log_stride_size(mdev, params,
rqo);
@@ -936,10 +955,15 @@ static int mlx5e_alloc_rq(struct mlx5e_params *params,
if (err)
goto err_rq_mkey;
- err = mlx5_rq_shampo_alloc(mdev, params, rq_param, rq, node);
+ err = mlx5e_rq_alloc_mpwqe_linear_info(rq, node, params, rqo,
+ &pool_size);
if (err)
goto err_free_mpwqe_info;
+ err = mlx5_rq_shampo_alloc(mdev, params, rq_param, rq, node);
+ if (err)
+ goto err_free_mpwqe_linear_info;
+
break;
default: /* MLX5_WQ_TYPE_CYCLIC */
err = mlx5_wq_cyc_create(mdev, &rq_param->wq, rqc_wq,
@@ -1054,6 +1078,8 @@ static int mlx5e_alloc_rq(struct mlx5e_params *params,
switch (rq->wq_type) {
case MLX5_WQ_TYPE_LINKED_LIST_STRIDING_RQ:
mlx5e_rq_free_shampo(rq);
+err_free_mpwqe_linear_info:
+ kvfree(rq->mpwqe.linear_info);
err_free_mpwqe_info:
kvfree(rq->mpwqe.info);
err_rq_mkey:
@@ -1081,6 +1107,7 @@ static void mlx5e_free_rq(struct mlx5e_rq *rq)
switch (rq->wq_type) {
case MLX5_WQ_TYPE_LINKED_LIST_STRIDING_RQ:
mlx5e_rq_free_shampo(rq);
+ kvfree(rq->mpwqe.linear_info);
kvfree(rq->mpwqe.info);
mlx5_core_destroy_mkey(rq->mdev, be32_to_cpu(rq->mpwqe.umr_mkey_be));
mlx5e_free_mpwqe_rq_drop_page(rq);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index f5c0e2a0ada9..feb042d84b8e 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
@@ -1869,6 +1869,7 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *w
struct mlx5e_frag_page *frag_page = &wi->alloc_units.frag_pages[page_idx];
u16 headlen = min_t(u16, MLX5E_RX_MAX_HEAD, cqe_bcnt);
struct mlx5e_frag_page *head_page = frag_page;
+ struct mlx5e_frag_page *linear_page = NULL;
struct mlx5e_xdp_buff *mxbuf = &rq->mxbuf;
u32 page_size = BIT(rq->mpwqe.page_shift);
u32 frag_offset = head_offset;
@@ -1897,13 +1898,15 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *w
if (prog) {
/* area for bpf_xdp_[store|load]_bytes */
net_prefetchw(netmem_address(frag_page->netmem) + frag_offset);
+
+ linear_page = &rq->mpwqe.linear_info->frag_page;
if (unlikely(mlx5e_page_alloc_fragmented(rq->page_pool,
- &wi->linear_page))) {
+ linear_page))) {
rq->stats->buff_alloc_err++;
return NULL;
}
- va = netmem_address(wi->linear_page.netmem);
+ va = netmem_address(linear_page->netmem);
net_prefetchw(va); /* xdp_frame data area */
linear_hr = XDP_PACKET_HEADROOM;
linear_data_len = 0;
@@ -1966,10 +1969,10 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *w
for (pfp = head_page; pfp < frag_page; pfp++)
pfp->frags++;
- wi->linear_page.frags++;
+ linear_page->frags++;
}
mlx5e_page_release_fragmented(rq->page_pool,
- &wi->linear_page);
+ linear_page);
return NULL; /* page/packet was consumed by XDP */
}
@@ -1988,13 +1991,13 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *w
mxbuf->xdp.data - mxbuf->xdp.data_meta);
if (unlikely(!skb)) {
mlx5e_page_release_fragmented(rq->page_pool,
- &wi->linear_page);
+ linear_page);
return NULL;
}
skb_mark_for_recycle(skb);
- wi->linear_page.frags++;
- mlx5e_page_release_fragmented(rq->page_pool, &wi->linear_page);
+ linear_page->frags++;
+ mlx5e_page_release_fragmented(rq->page_pool, linear_page);
if (xdp_buff_has_frags(&mxbuf->xdp)) {
struct mlx5e_frag_page *pagep;
--
2.44.0
^ permalink raw reply related
* [PATCH net-next V2 3/5] net/mlx5e: XDP, Remove stride size limitation
From: Tariq Toukan @ 2026-04-03 9:09 UTC (permalink / raw)
To: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Dragos Tatulea, Cosmin Ratiu,
Simon Horman, Jacob Keller, Lama Kayal, Michal Swiatkowski,
Carolina Jubran, Nathan Chancellor, Daniel Zahka,
Rahul Rameshbabu, Raed Salem, netdev, linux-rdma, linux-kernel,
bpf, Gal Pressman
In-Reply-To: <20260403090927.139042-1-tariqt@nvidia.com>
From: Dragos Tatulea <dtatulea@nvidia.com>
Currently XDP mode always uses PAGE_SIZE strides. This limitation
existed because page fragment counting was not implemented when XDP was
added. Furthermore, due to this limitation there were other issues as
well on system with larger pages (e.g. 64K):
- XDP for Striding RQ was effectively disabled on such systems.
- Legacy RQ allows the configuration but uses a fixed scheme of one XDP
buffer per page which is inefficient.
As fragment counting was added during the driver conversion to
page_pool and the support for XDP multi-buffer, it is now possible
to remove this stride size limitation. This patch does just that.
Now it is possible to use XDP on systems with higher page sizes (e.g.
64K):
- For Striding RQ, loading the program is no longer blocked.
Although a 64K page can fit any packet, MTUs that result in
stride > 8K will still make the RQ in non-linear mode. That's
because the HW doesn't support a higher than 8K stride.
- For Legacy RQ, the stride size was PAGE_SIZE which was very
inefficient. Now the stride size will be calculated relative to MTU.
Legacy RQ will always be in linear mode for larger system pages.
This can be observed with an XDP_DROP test [1] when running
in Legacy RQ mode on a ARM Neoverse-N1 system with a 64K
page size:
+-----------------------------------------------+
| MTU | baseline | this change | improvement |
|------+------------+-------------+-------------|
| 1500 | 15.55 Mpps | 18.99 Mpps | 22.0 % |
| 9000 | 15.53 Mpps | 18.24 Mpps | 17.5 % |
+-----------------------------------------------+
There are performance benefits for Striding RQ mode as well:
- Striding RQ non-linear mode now uses 256B strides, just like
non-XDP mode.
- Striding RQ linear mode can now fit a number of XDP buffers per page
that is relative to the MTU size. That means that on 4K page systems
and a small enough MTU, 2 XDP buffers can fit in one page.
The above benefits for Striding RQ can be observed with an
XDP_DROP test [1] when running on a 4K page x86_64 system
(Intel Xeon Platinum 8580):
+-----------------------------------------------+
| MTU | baseline | this change | improvement |
|------+------------+-------------+-------------|
| 1000 | 28.36 Mpps | 33.98 Mpps | 19.82 % |
| 9000 | 20.76 Mpps | 26.30 Mpps | 26.70 % |
+-----------------------------------------------+
[1] Test description:
- xdp-bench with XDP_DROP
- RX: single queue
- TX: sends 64B packets to saturate CPU on RX side
Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en/params.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/params.c b/drivers/net/ethernet/mellanox/mlx5/core/en/params.c
index 26bb31c56e45..1f4a547917ba 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/params.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/params.c
@@ -298,12 +298,9 @@ static u32 mlx5e_rx_get_linear_stride_sz(struct mlx5_core_dev *mdev,
* no_head_tail_room should be set in the case of XDP with Striding RQ
* when SKB is not linear. This is because another page is allocated for the linear part.
*/
- sz = roundup_pow_of_two(mlx5e_rx_get_linear_sz_skb(params, no_head_tail_room));
+ sz = mlx5e_rx_get_linear_sz_skb(params, no_head_tail_room);
- /* XDP in mlx5e doesn't support multiple packets per page.
- * Do not assume sz <= PAGE_SIZE if params->xdp_prog is set.
- */
- return params->xdp_prog && sz < PAGE_SIZE ? PAGE_SIZE : sz;
+ return roundup_pow_of_two(sz);
}
static u8 mlx5e_mpwqe_log_pkts_per_wqe(struct mlx5_core_dev *mdev,
@@ -453,10 +450,6 @@ u8 mlx5e_mpwqe_get_log_stride_size(struct mlx5_core_dev *mdev,
return order_base_2(mlx5e_rx_get_linear_stride_sz(mdev, params,
rqo, true));
- /* XDP in mlx5e doesn't support multiple packets per page. */
- if (params->xdp_prog)
- return PAGE_SHIFT;
-
return MLX5_MPWRQ_DEF_LOG_STRIDE_SZ(mdev);
}
--
2.44.0
^ permalink raw reply related
* [PATCH net-next V2 2/5] net/mlx5e: XDP, Improve dma address calculation of linear part for XDP_TX
From: Tariq Toukan @ 2026-04-03 9:09 UTC (permalink / raw)
To: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Dragos Tatulea, Cosmin Ratiu,
Simon Horman, Jacob Keller, Lama Kayal, Michal Swiatkowski,
Carolina Jubran, Nathan Chancellor, Daniel Zahka,
Rahul Rameshbabu, Raed Salem, netdev, linux-rdma, linux-kernel,
bpf, Gal Pressman
In-Reply-To: <20260403090927.139042-1-tariqt@nvidia.com>
From: Dragos Tatulea <dtatulea@nvidia.com>
When calculating the dma address of the linear part of an XDP frame, the
formula assumes that there is a single XDP buffer per page. Extend the
formula to allow multiple XDP buffers per page by calculating the data
offset in the page.
This is a preparation for the upcoming removal of a single XDP buffer
per page limitation when the formula will no longer be correct.
Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
index 04e1b5fa4825..d3bab198c99c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
@@ -123,7 +123,7 @@ mlx5e_xmit_xdp_buff(struct mlx5e_xdpsq *sq, struct mlx5e_rq *rq,
* mode.
*/
- dma_addr = page_pool_get_dma_addr(page) + (xdpf->data - (void *)xdpf);
+ dma_addr = page_pool_get_dma_addr(page) + offset_in_page(xdpf->data);
dma_sync_single_for_device(sq->pdev, dma_addr, xdptxd->len, DMA_BIDIRECTIONAL);
if (xdptxd->has_frags) {
--
2.44.0
^ permalink raw reply related
* [PATCH net-next V2 1/5] net/mlx5e: XSK, Increase size for chunk_size param
From: Tariq Toukan @ 2026-04-03 9:09 UTC (permalink / raw)
To: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Dragos Tatulea, Cosmin Ratiu,
Simon Horman, Jacob Keller, Lama Kayal, Michal Swiatkowski,
Carolina Jubran, Nathan Chancellor, Daniel Zahka,
Rahul Rameshbabu, Raed Salem, netdev, linux-rdma, linux-kernel,
bpf, Gal Pressman
In-Reply-To: <20260403090927.139042-1-tariqt@nvidia.com>
From: Dragos Tatulea <dtatulea@nvidia.com>
When 64K pages are used, chunk_size can take the 64K value
which doesn't fit in u16. This results in overflows that
are detected in mlx5e_mpwrq_log_wqe_sz().
Increase the type to u32 to fix this.
Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en/params.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/params.h b/drivers/net/ethernet/mellanox/mlx5/core/en/params.h
index 9b1a2aed17c3..275f9be53a34 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/params.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/params.h
@@ -8,7 +8,7 @@
struct mlx5e_xsk_param {
u16 headroom;
- u16 chunk_size;
+ u32 chunk_size;
bool unaligned;
};
--
2.44.0
^ permalink raw reply related
* [PATCH net-next V2 0/5] net/mlx5e: XDP, Add support for multi-packet per page
From: Tariq Toukan @ 2026-04-03 9:09 UTC (permalink / raw)
To: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Dragos Tatulea, Cosmin Ratiu,
Simon Horman, Jacob Keller, Lama Kayal, Michal Swiatkowski,
Carolina Jubran, Nathan Chancellor, Daniel Zahka,
Rahul Rameshbabu, Raed Salem, netdev, linux-rdma, linux-kernel,
bpf, Gal Pressman
Hi,
This series removes the limitation of having one packet per page in XDP
mode. This has the following implications:
- XDP in Striding RQ mode can now be used on 64K page systems.
- XDP in Legacy RQ mode was using a single packet per page which on 64K
page systems is quite inefficient. The improvement can be observed
with an XDP_DROP test when running in Legacy RQ mode on a ARM
Neoverse-N1 system with a 64K page size:
+-----------------------------------------------+
| MTU | baseline | this change | improvement |
|------+------------+-------------+-------------|
| 1500 | 15.55 Mpps | 18.99 Mpps | 22.0 % |
| 9000 | 15.53 Mpps | 18.24 Mpps | 17.5 % |
+-----------------------------------------------+
After lifting this limitation, the series switches to using fragments
for the side page in non-linear mode. This small improvement is at most
visible for XDP_DROP tests with small 64B packets and a large enough MTU
for Striding RQ to be in non-linear mode:
+----------------------------------------------------------------------+
| System | MTU | baseline | this change | improvement |
|----------------------+------+------------+-------------+-------------|
| 4K page x86_64 [1] | 9000 | 26.30 Mpps | 30.45 Mpps | 15.80 % |
| 64K page aarch64 [2] | 9000 | 15.27 Mpps | 20.10 Mpps | 31.62 % |
+----------------------------------------------------------------------+
This series does not cover the xsk (AF_XDP) paths for 64K page systems.
[1] https://lore.kernel.org/all/20260324024235.929875-1-kuba@kernel.org/
V2:
- Link to V1:
https://lore.kernel.org/all/20260319075036.24734-1-tariqt@nvidia.com/
- Fixed issue found by AI review [1].
Dragos Tatulea (5):
net/mlx5e: XSK, Increase size for chunk_size param
net/mlx5e: XDP, Improve dma address calculation of linear part for
XDP_TX
net/mlx5e: XDP, Remove stride size limitation
net/mlx5e: XDP, Use a single linear page per rq
net/mlx5e: XDP, Use page fragments for linear data in multibuf-mode
drivers/net/ethernet/mellanox/mlx5/core/en.h | 12 +++-
.../ethernet/mellanox/mlx5/core/en/params.c | 11 +---
.../ethernet/mellanox/mlx5/core/en/params.h | 2 +-
.../net/ethernet/mellanox/mlx5/core/en/xdp.c | 2 +-
.../net/ethernet/mellanox/mlx5/core/en_main.c | 50 ++++++++++++--
.../net/ethernet/mellanox/mlx5/core/en_rx.c | 65 +++++++++++++++----
6 files changed, 113 insertions(+), 29 deletions(-)
base-commit: 8b0e64d6c9e7feec5ba5643b4fa8b7fd54464778
--
2.44.0
^ permalink raw reply
* [RFC PATCH net-next 1/3] net: phy: add support for disabling PHY-autonomous EEE
From: Nicolai Buchwitz @ 2026-04-03 9:06 UTC (permalink / raw)
To: netdev
Cc: Russell King, Andrew Lunn, Florian Fainelli, Nicolai Buchwitz,
Heiner Kallweit, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-kernel
In-Reply-To: <20260403090656.733985-1-nb@tipi-net.de>
Some PHYs (e.g. Broadcom BCM54xx, Realtek RTL8211F) implement
autonomous EEE where the PHY manages LPI signaling without forwarding
it to the MAC. This conflicts with MAC drivers that implement their own
LPI control.
Add a .disable_autonomous_eee callback to struct phy_driver and call it
from phy_support_eee(). When a MAC driver indicates it supports EEE via
phy_support_eee(), the PHY's autonomous EEE is automatically disabled so
the MAC can manage LPI entry/exit.
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
---
drivers/net/phy/phy_device.c | 22 ++++++++++++++++++++++
include/linux/phy.h | 18 ++++++++++++++++++
2 files changed, 40 insertions(+)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 0edff47478c2..cda4abf4e68c 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1375,6 +1375,14 @@ int phy_init_hw(struct phy_device *phydev)
return ret;
}
+ /* Re-apply autonomous EEE disable after soft reset */
+ if (phydev->autonomous_eee_disabled &&
+ phydev->drv->disable_autonomous_eee) {
+ ret = phydev->drv->disable_autonomous_eee(phydev);
+ if (ret)
+ return ret;
+ }
+
return 0;
}
EXPORT_SYMBOL(phy_init_hw);
@@ -2898,6 +2906,20 @@ void phy_support_eee(struct phy_device *phydev)
linkmode_copy(phydev->advertising_eee, phydev->supported_eee);
phydev->eee_cfg.tx_lpi_enabled = true;
phydev->eee_cfg.eee_enabled = true;
+
+ /* If the PHY supports autonomous EEE, disable it so the MAC can
+ * manage LPI signaling instead. The flag is stored so it can be
+ * re-applied after a PHY soft reset (e.g. suspend/resume).
+ */
+ if (phydev->drv && phydev->drv->disable_autonomous_eee) {
+ int ret = phydev->drv->disable_autonomous_eee(phydev);
+
+ if (ret)
+ phydev_warn(phydev, "Failed to disable autonomous EEE: %pe\n",
+ ERR_PTR(ret));
+ else
+ phydev->autonomous_eee_disabled = true;
+ }
}
EXPORT_SYMBOL(phy_support_eee);
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 5de4b172cd0b..55d9cc6c3605 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -612,6 +612,8 @@ struct phy_oatc14_sqi_capability {
* @advertising_eee: Currently advertised EEE linkmodes
* @enable_tx_lpi: When True, MAC should transmit LPI to PHY
* @eee_active: phylib private state, indicating that EEE has been negotiated
+ * @autonomous_eee_disabled: Set when autonomous EEE has been disabled via
+ * phy_support_eee(), used to re-apply after PHY soft reset
* @eee_cfg: User configuration of EEE
* @lp_advertising: Current link partner advertised linkmodes
* @host_interfaces: PHY interface modes supported by host
@@ -739,6 +741,7 @@ struct phy_device {
__ETHTOOL_DECLARE_LINK_MODE_MASK(eee_disabled_modes);
bool enable_tx_lpi;
bool eee_active;
+ bool autonomous_eee_disabled;
struct eee_config eee_cfg;
/* Host supported PHY interface types. Should be ignored if empty. */
@@ -1359,6 +1362,21 @@ struct phy_driver {
void (*get_stats)(struct phy_device *dev,
struct ethtool_stats *stats, u64 *data);
+ /**
+ * @disable_autonomous_eee: Disable PHY-autonomous EEE
+ *
+ * Some PHYs manage EEE LPI autonomously without forwarding LPI
+ * signaling to the MAC. This callback disables autonomous EEE so
+ * that the MAC can control LPI entry/exit.
+ *
+ * Called by phy_support_eee() when the MAC indicates it supports
+ * EEE. PHY drivers that implement autonomous EEE should provide
+ * this callback.
+ *
+ * Return: 0 on success, negative errno on failure.
+ */
+ int (*disable_autonomous_eee)(struct phy_device *dev);
+
/* Get and Set PHY tunables */
/** @get_tunable: Return the value of a tunable */
int (*get_tunable)(struct phy_device *dev,
--
2.51.0
^ permalink raw reply related
* [RFC PATCH net-next 3/3] net: phy: realtek: convert RTL8211F to .disable_autonomous_eee
From: Nicolai Buchwitz @ 2026-04-03 9:06 UTC (permalink / raw)
To: netdev
Cc: Russell King, Andrew Lunn, Florian Fainelli, Nicolai Buchwitz,
Heiner Kallweit, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Daniel Golle, Vladimir Oltean, Michael Klein,
Daniel Braunwarth, Markus Stockhausen, Issam Hamdi,
Russell King (Oracle), linux-kernel
In-Reply-To: <20260403090656.733985-1-nb@tipi-net.de>
The RTL8211F previously unconditionally disabled PHY-mode EEE in
config_init. Convert this to use the new .disable_autonomous_eee
callback so it is only disabled when the MAC indicates EEE support
via phy_support_eee().
This preserves PHY-autonomous EEE for MACs that do not support EEE,
while still disabling it when the MAC manages LPI.
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
---
drivers/net/phy/realtek/realtek_main.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
index 023e47ad605b..b7c96b020baf 100644
--- a/drivers/net/phy/realtek/realtek_main.c
+++ b/drivers/net/phy/realtek/realtek_main.c
@@ -700,9 +700,8 @@ static int rtl8211f_config_aldps(struct phy_device *phydev)
return phy_modify(phydev, RTL8211F_PHYCR1, mask, mask);
}
-static int rtl8211f_config_phy_eee(struct phy_device *phydev)
+static int rtl8211f_disable_autonomous_eee(struct phy_device *phydev)
{
- /* Disable PHY-mode EEE so LPI is passed to the MAC */
return phy_modify(phydev, RTL8211F_PHYCR2,
RTL8211F_PHYCR2_PHY_EEE_ENABLE, 0);
}
@@ -730,7 +729,7 @@ static int rtl8211f_config_init(struct phy_device *phydev)
return ret;
}
- return rtl8211f_config_phy_eee(phydev);
+ return 0;
}
static int rtl821x_suspend(struct phy_device *phydev)
@@ -2324,6 +2323,7 @@ static struct phy_driver realtek_drvs[] = {
.led_hw_is_supported = rtl8211x_led_hw_is_supported,
.led_hw_control_get = rtl8211f_led_hw_control_get,
.led_hw_control_set = rtl8211f_led_hw_control_set,
+ .disable_autonomous_eee = rtl8211f_disable_autonomous_eee,
}, {
PHY_ID_MATCH_EXACT(RTL_8211FVD_PHYID),
.name = "RTL8211F-VD Gigabit Ethernet",
@@ -2340,6 +2340,7 @@ static struct phy_driver realtek_drvs[] = {
.led_hw_is_supported = rtl8211x_led_hw_is_supported,
.led_hw_control_get = rtl8211f_led_hw_control_get,
.led_hw_control_set = rtl8211f_led_hw_control_set,
+ .disable_autonomous_eee = rtl8211f_disable_autonomous_eee,
}, {
.name = "Generic FE-GE Realtek PHY",
.match_phy_device = rtlgen_match_phy_device,
--
2.51.0
^ permalink raw reply related
* [RFC PATCH net-next 2/3] net: phy: broadcom: implement .disable_autonomous_eee for BCM54xx
From: Nicolai Buchwitz @ 2026-04-03 9:06 UTC (permalink / raw)
To: netdev
Cc: Russell King, Andrew Lunn, Florian Fainelli, Nicolai Buchwitz,
Broadcom internal kernel review list, Heiner Kallweit,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-kernel
In-Reply-To: <20260403090656.733985-1-nb@tipi-net.de>
Disable AutogrEEEn mode on BCM54210E when the MAC indicates EEE support
via phy_support_eee(). In AutogrEEEn mode the PHY manages LPI
autonomously without forwarding LPI signaling to the MAC over the RGMII
interface, which prevents the MAC from controlling TX LPI entry/exit.
Clearing the AutogrEEEn enable bit in MII_BUF_CNTL_0 switches the PHY
to Native EEE mode where the MAC controls TX LPI and the PHY forwards
received LPI on the RGMII interface.
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
---
drivers/net/phy/broadcom.c | 7 +++++++
include/linux/brcmphy.h | 3 +++
2 files changed, 10 insertions(+)
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index cb306f9e80cc..bf0c6a04481e 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -1452,6 +1452,12 @@ static int bcm54811_read_status(struct phy_device *phydev)
return genphy_read_status(phydev);
}
+static int bcm54xx_disable_autonomous_eee(struct phy_device *phydev)
+{
+ return bcm_phy_modify_exp(phydev, BCM54XX_TOP_MISC_MII_BUF_CNTL0,
+ BCM54XX_MII_BUF_CNTL0_AUTOGREEEN_EN, 0);
+}
+
static struct phy_driver broadcom_drivers[] = {
{
PHY_ID_MATCH_MODEL(PHY_ID_BCM5411),
@@ -1495,6 +1501,7 @@ static struct phy_driver broadcom_drivers[] = {
.get_wol = bcm54xx_phy_get_wol,
.set_wol = bcm54xx_phy_set_wol,
.led_brightness_set = bcm_phy_led_brightness_set,
+ .disable_autonomous_eee = bcm54xx_disable_autonomous_eee,
}, {
PHY_ID_MATCH_MODEL(PHY_ID_BCM5461),
.name = "Broadcom BCM5461",
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index 115a964f3006..174687c4c80a 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -266,6 +266,9 @@
#define BCM54XX_TOP_MISC_IDDQ_SD (1 << 2)
#define BCM54XX_TOP_MISC_IDDQ_SR (1 << 3)
+#define BCM54XX_TOP_MISC_MII_BUF_CNTL0 (MII_BCM54XX_EXP_SEL_TOP + 0x00)
+#define BCM54XX_MII_BUF_CNTL0_AUTOGREEEN_EN BIT(0)
+
#define BCM54XX_TOP_MISC_LED_CTL (MII_BCM54XX_EXP_SEL_TOP + 0x0C)
#define BCM54XX_LED4_SEL_INTR BIT(1)
--
2.51.0
^ permalink raw reply related
* [RFC PATCH net-next 0/3] net: phy: add support for disabling autonomous EEE
From: Nicolai Buchwitz @ 2026-04-03 9:06 UTC (permalink / raw)
To: netdev; +Cc: Russell King, Andrew Lunn, Florian Fainelli, Nicolai Buchwitz
Some PHYs implement autonomous EEE where the PHY manages LPI signaling
without forwarding it to the MAC. This conflicts with MACs that
implement their own LPI control via phylink's mac_enable_tx_lpi /
mac_disable_tx_lpi callbacks.
This series adds a .disable_autonomous_eee callback to struct phy_driver
and calls it from phy_support_eee(). When a MAC indicates it supports
EEE, the PHY's autonomous EEE is automatically disabled so the MAC can
manage LPI entry/exit. The setting is persisted across suspend/resume
by re-applying it in phy_init_hw() after soft reset, following the same
pattern suggested by Russell King for PHY tunables [1].
Patch 1 adds the phylib infrastructure.
Patch 2 implements it for Broadcom BCM54xx (AutogrEEEn).
Patch 3 converts the Realtek RTL8211F, which previously unconditionally
disabled PHY-mode EEE in config_init.
This came up while adding EEE support to the Cadence macb driver (used
on Raspberry Pi 5 with a BCM54210PE PHY). The PHY's AutogrEEEn mode
prevented the MAC from tracking LPI state. The Realtek RTL8211F has
the same pattern, unconditionally disabling PHY-mode EEE with the
comment "Disable PHY-mode EEE so LPI is passed to the MAC".
Other BCM54xx PHYs likely have the same AutogrEEEn register layout,
but I only have access to the BCM54210PE/BCM54213PE datasheets. It
would be appreciated if Florian or others could confirm which other
BCM54xx variants share this register so we can wire them up too.
Tested on Raspberry Pi CM4 (bcmgenet + BCM54210PE),
Raspberry Pi CM5 (Cadence GEM + BCM54210PE) and
Raspberry Pi 5 (Cadence GEM + BCM54213PE).
[1] https://lore.kernel.org/netdev/acuwvoydmJusuj9x@shell.armlinux.org.uk/
Previous discussion:
https://lore.kernel.org/netdev/d86c53213a6328b701b8aabbde5d1c83@tipi-net.de/
Nicolai Buchwitz (3):
net: phy: add support for disabling PHY-autonomous EEE
net: phy: broadcom: implement .disable_autonomous_eee for BCM54xx
net: phy: realtek: convert RTL8211F to .disable_autonomous_eee
drivers/net/phy/broadcom.c | 7 +++++++
drivers/net/phy/phy_device.c | 22 ++++++++++++++++++++++
drivers/net/phy/realtek/realtek_main.c | 7 ++++---
include/linux/brcmphy.h | 3 +++
include/linux/phy.h | 18 ++++++++++++++++++
5 files changed, 54 insertions(+), 3 deletions(-)
--
2.51.0
^ permalink raw reply
* Re: [PATCH net] ice: fix PTP Call Trace during PTP release
From: Simon Horman @ 2026-04-03 9:05 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Paul Greenwalt
In-Reply-To: <20260327072332.130320-3-aleksandr.loktionov@intel.com>
On Fri, Mar 27, 2026 at 08:23:26AM +0100, Aleksandr Loktionov wrote:
> From: Paul Greenwalt <paul.greenwalt@intel.com>
>
> If a PF reset occurs when the PTP state is ICE_PTP_UNINIT, then
> ice_ptp_rebuild() will update the state to ICE_PTP_ERROR. This will
> result in the following PTP release call trace during driver unload:
>
> kernel BUG at lib/list_debug.c:52!
> ice_ptp_release+0x332/0x3c0 [ice]
> ice_deinit_features.part.0+0x10e/0x120 [ice]
> ice_remove+0x100/0x220 [ice]
>
> This was observed when passing PF1 through to a VM. ice_ptp_init()
> fails because ctrl_pf is NULL and sets the state to ICE_PTP_UNINIT.
>
> Fix by detecting the ICE_PTP_UNINIT state in ice_ptp_rebuild() and
> returning without error, preventing the invalid state transition to
> ICE_PTP_ERROR. The only valid path to ICE_PTP_ERROR is from
> ICE_PTP_RESETTING after a failed rebuild.
>
> Fixes: 8293e4cb2ff5 ("ice: introduce PTP state machine")
> Cc: stable@vger.kernel.org
> Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next 10/11] net: macb: use context swapping in .set_ringparam()
From: Théo Lebrun @ 2026-04-03 9:03 UTC (permalink / raw)
To: Théo Lebrun, Nicolai Buchwitz
Cc: Nicolas Ferre, Claudiu Beznea, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Richard Cochran,
Russell King, Paolo Valerio, Conor Dooley, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier, netdev, linux-kernel
In-Reply-To: <DHIT9TPJQJ46.21A89R5UAFXVH@bootlin.com>
On Thu Apr 2, 2026 at 6:31 PM CEST, Théo Lebrun wrote:
> On Thu Apr 2, 2026 at 1:29 PM CEST, Nicolai Buchwitz wrote:
>> On 1.4.2026 18:39, Théo Lebrun wrote:
>>> ethtool_ops.set_ringparam() is implemented using the primitive close /
>>> update ring size / reopen sequence. Under memory pressure this does not
>>> fly: we free our buffers at close and cannot reallocate new ones at
>>> open. Also, it triggers a slow PHY reinit.
>>>
>>> Instead, exploit the new context mechanism and improve our sequence to:
>>> - allocate a new context (including buffers) first
>>> - if it fails, early return without any impact to the interface
>>> - stop interface
>>> - update global state (bp, netdev, etc)
>>> - pass buffer pointers to the hardware
>>> - start interface
>>> - free old context.
>>>
>>> The HW disable sequence is inspired by macb_reset_hw() but avoids
>>> (1) setting NCR bit CLRSTAT and (2) clearing register PBUFRXCUT.
>>>
>>> The HW re-enable sequence is inspired by macb_mac_link_up(), skipping
>>> over register writes which would be redundant (because values have not
>>> changed).
>>>
>>> The generic context swapping parts are isolated into helper functions
>>> macb_context_swap_start|end(), reusable by other operations
>>> (change_mtu,
>>> set_channels, etc).
>>>
>>> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
>>> ---
>>> drivers/net/ethernet/cadence/macb_main.c | 89
>>> +++++++++++++++++++++++++++++---
>>> 1 file changed, 82 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/cadence/macb_main.c
>>> b/drivers/net/ethernet/cadence/macb_main.c
>>> index 42b19b969f3e..543356554c11 100644
>>> --- a/drivers/net/ethernet/cadence/macb_main.c
>>> +++ b/drivers/net/ethernet/cadence/macb_main.c
>>> @@ -2905,6 +2905,76 @@ static struct macb_context
>>> *macb_context_alloc(struct macb *bp,
>>> return ctx;
>>> }
>>>
>>> +static void macb_context_swap_start(struct macb *bp)
>>> +{
>>> + struct macb_queue *queue;
>>> + unsigned int q;
>>> + u32 ctrl;
>>> +
>>> + /* Disable software Tx, disable HW Tx/Rx and disable NAPI. */
>>> +
>>> + netif_tx_disable(bp->netdev);
>>> +
>>> + ctrl = macb_readl(bp, NCR);
>>> + macb_writel(bp, NCR, ctrl & ~(MACB_BIT(RE) | MACB_BIT(TE)));
>>> +
>>> + macb_writel(bp, TSR, -1);
>>> + macb_writel(bp, RSR, -1);
>>> +
>>> + for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
>>> + queue_writel(queue, IDR, -1);
>>> + queue_readl(queue, ISR);
>>> + if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
>>> + queue_writel(queue, ISR, -1);
>>> + }
>>> +
>>> + for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
>>> + napi_disable(&queue->napi_rx);
>>> + napi_disable(&queue->napi_tx);
>>> + }
>>
>> tx_error_task, hresp_err_bh_work, and tx_lpi_work all dereference
>> bp->ctx and could race with the pointer swap in swap_end.
>> macb_close() cancels at least tx_lpi_work here. Should these be
>> flushed too?
>
> This is a large topic! While trying to find a solution as part of this
> series I am noticing many race conditions. With this context series we
> worsen some (by introducing bp->ctx NULL ptr dereference).
>
> Let's start by identifying all schedule-able contexts involved:
> - #1 any request from userspace, too many callbacks to list
> - #2 NAPI softirq or kthread context, macb_{rx,tx}_poll()
> - #3 bp->hresp_err_bh_work / macb_hresp_error_task()
> - #4 bp->tx_lpi_work / macb_tx_lpi_work_fn()
> - #5 queue->tx_error_task / macb_tx_error_task()
> - #6 IRQ context, macb_interrupt()
>
> Some race conditions:
>
> - #1 macb_close() doesn't cancel & wait upon #3 hresp_err_bh_work.
> They could race, especially as #3 doesn't grab bp->lock. One race
> example: #3 BP HRESP starts the interface after it has been closed
> and buffers freed. RBQP/TBQP are not reset so MACB would occur
> memory corruption on Rx and transmit memory content.
>
> - #1 macb_close() doesn't cancel & wait upon #5 tx_error_task. #5 does
> grab bp->lock but that doesn't make it much safer. One race example:
> same as above, restart of interface with ghost ring buffers.
>
> - #3 hresp_err_bh_work could collide with anything as it does no
> locking, especially #1 (xmit for example) or #2 (NAPI). It is less
> likely to collide with #6 IRQ because it starts by disabling those
> but there is a possibility of the IRQ having already triggered and
> macb_interrupt() already running in parallel of
> macb_hresp_error_task().
>
> - #5 queue->tx_error_task writes to Tx head/tail inside bp->lock.
> #1 macb_start_xmit() modifies those too, but inside
> queue->tx_ptr_lock. Oops. There probably are other places modifying
> head/tail or any other Tx queue value without queue->tx_ptr_lock.
>
> - #5 macb_tx_error_task() tries to gently disable TX but if it
> times-out then it uses the global switch (TE field in NCR
> register). That sounds racy with #2 NAPI that doesn't grab bp->lock
> and would probably break if the interface is shutdown under its
> feet.
>
> I don't see much more. To fix all that, someone ought to exhaustively go
> through all tasks (#1-6 above) & all shared data and reason one by one.
> Who will be that someone? ;-) But that sounds pretty unrelated to the
> series at hand, no?
>
> I'd agree that some locking of bp->lock around the swap operation would
> improve the series, and I'll add that in V2 for sure!
After some sleep, I feel like my message was a bit rough. To clarify
what I plan for V2:
- grab bp->lock on swap to protect us against some of #1 userspace and
all of #6 IRQ.
- disabling #2 NAPI on swap is already done
- disable all three BH features on swap
That will not fix everything listed above.
On top, we should:
- check/revise our locking strategy for almost all codepaths,
- check all BH features are disabled and blocked upon in the right
codepaths,
- in many bp->lock critical section, we should early exit if !bp->ctx.
>
>>
>>> +}
>>> +
>>> +static void macb_context_swap_end(struct macb *bp,
>>> + struct macb_context *new_ctx)
>>> +{
>>> + struct macb_context *old_ctx;
>>> + struct macb_queue *queue;
>>> + unsigned int q;
>>> + u32 ctrl;
>>> +
>>> + /* Swap contexts & give buffer pointers to HW. */
>>> +
>>> + old_ctx = bp->ctx;
>>> + bp->ctx = new_ctx;
>>> + macb_init_buffers(bp);
>>> +
>>> + /* Start NAPI, HW Tx/Rx and software Tx. */
>>> +
>>> + for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
>>> + napi_enable(&queue->napi_rx);
>>> + napi_enable(&queue->napi_tx);
>>> + }
>>> +
>>> + if (!(bp->caps & MACB_CAPS_MACB_IS_EMAC)) {
>>> + for (q = 0, queue = bp->queues; q < bp->num_queues;
>>> + ++q, ++queue) {
>>> + queue_writel(queue, IER,
>>> + bp->rx_intr_mask |
>>> + MACB_TX_INT_FLAGS |
>>> + MACB_BIT(HRESP));
>>> + }
>>> + }
>>> +
>>> + ctrl = macb_readl(bp, NCR);
>>> + macb_writel(bp, NCR, ctrl | MACB_BIT(RE) | MACB_BIT(TE));
>>> +
>>> + netif_tx_start_all_queues(bp->netdev);
>>> +
>>> + /* Free old context. */
>>> +
>>> + macb_free_consistent(old_ctx);
>>
>> 1. kfree(old_ctx) is missing. The context struct itself leaks on
>> every swap.
>
> Agreed.
>
>> 2. macb_close() calls netdev_tx_reset_queue() for each queue.
>> Shouldn't the swap do the same? BQL accounting will be stale
>> after switching to a fresh context.
>
> I explicitely left that out as I thought DQL would benefit from keeping
> past context of the traffic. But indeed as we start afresh from a new
> set of buffers we should reset DQL. fbnic, pointed out as an good
> example by Jakub recently, does that.
>
>>
>> 3. macb_configure_dma() is not called after the swap. For
>> set_ringparam this is probably fine since rx_buffer_size
>> does not change, but this becomes a problem in patch 11.
>
> Indeed, I had missed it took bp->ctx->rx_buffer_size as a parameter.
> Will fix.
Thanks,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox