* Re: [net-next PATCH 07/10] net: dsa: realtek: rtl8365mb: add port_bridge_{join,leave}
From: Linus Walleij @ 2026-04-07 8:11 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260331-realtek_forward-v1-7-44fb63033b7e@gmail.com>
Hi Luiz, Alvin,
thanks for your patch!
On Wed, Apr 1, 2026 at 1:00 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> static int rtl8365mb_port_set_isolation(struct realtek_priv *priv, int port,
> u32 mask)
> +static int rtl8365mb_port_add_isolation(struct realtek_priv *priv, int port,
> + u32 mask)
> +static int rtl8365mb_port_remove_isolation(struct realtek_priv *priv, int port,
> + u32 mask)
This is smart!
> +static int rtl8365mb_port_bridge_join(struct dsa_switch *ds, int port,
> + struct dsa_bridge bridge,
> + bool *tx_forward_offload,
> + struct netlink_ext_ack *extack)
> +static void rtl8365mb_port_bridge_leave(struct dsa_switch *ds, int port,
> + struct dsa_bridge bridge)
The content of these functions are very similar to
rtl8366rb_port_bridge_join() and rtl8366rb_port_bridge_leave().
What about moving this code to the shared library rtl8366-core as
rtl8366_port_bridge_join() and rtl8366_port_bridge_leave()
and add per-variant callbacks for ->port_set_isolation()
->port_add_isolation() and ->port_remove_isolation() to
struct realtek_ops and share this with rtl8366rb by refactoring
rtl8366rb.c to use the same callbacks.
Using shared code will help us to avoid having to fix the same
bugs in more than one place.
I don't know about this EFID stuff in rtl8365mb_port_set_efid()
(maybe RTL8366RB needs something like that too) but certainly that
can be an optional callback in struct realtek_ops for now.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net v2 1/1] net: l3mdev: Ignore non-L3 uppers in l3mdev_fib_table_rcu
From: Ido Schimmel @ 2026-04-07 8:02 UTC (permalink / raw)
To: David Ahern
Cc: Ao Zhou, netdev, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Ido Schimmel, Jiri Pirko, Yifan Wu,
Juefei Pu, Yuan Tan, Xin Liu, Haoze Xie
In-Reply-To: <b6cc7bc1-f18b-43d2-a21a-c964466fa882@kernel.org>
On Mon, Apr 06, 2026 at 12:14:15PM -0600, David Ahern wrote:
> On 4/6/26 9:48 AM, Ido Schimmel wrote:
> >
> > Don't we have the same problem in l3mdev_l3_rcv() and l3mdev_l3_out()?
> > If so, please check if I missed more places and include them in v3.
> >
> > And I think that the part that I was missing earlier is that we don't
> > have RCU synchronization in the unslaving path, so an RCU reader can
> > either see the original master, NULL or a new master (e.g., bridge
> > instead of the original VRF master).
>
> synchronize_rcu after the unlink (control path) seems like a better,
> more robust option than adding more checks to the datapath.
IMO it would be better to proceed with the original approach and look
into adding RCU synchronization in net-next. The original approach is
more surgical and the pattern of first checking netif_is_l3_master()
already exists in other places.
^ permalink raw reply
* [PATCH net v2 1/1] af_unix: read UNIX_DIAG_VFS data under unix_state_lock
From: Ren Wei @ 2026-04-07 8:00 UTC (permalink / raw)
To: netdev
Cc: kuniyu, davem, edumazet, kuba, pabeni, horms, xemul, yifanwucs,
tomapufckgml, yuantan098, bird, enjou1224z, wangjiexun2025, n05ec
In-Reply-To: <cover.1775207252.git.wangjiexun2025@gmail.com>
From: Jiexun Wang <wangjiexun2025@gmail.com>
Exact UNIX diag lookups hold a reference to the socket, but not to
u->path. Meanwhile, unix_release_sock() clears u->path under
unix_state_lock() and drops the path reference after unlocking.
Read the inode and device numbers for UNIX_DIAG_VFS while holding
unix_state_lock(), then emit the netlink attribute after dropping the
lock.
This keeps the VFS data stable while the reply is being built.
Fixes: 5f7b0569460b ("unix_diag: Unix inode info NLA")
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:
- reorder local variables in reverse xmas tree order
net/unix/diag.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/net/unix/diag.c b/net/unix/diag.c
index ca3473026151..c9c1e51c4419 100644
--- a/net/unix/diag.c
+++ b/net/unix/diag.c
@@ -28,18 +28,23 @@ static int sk_diag_dump_name(struct sock *sk, struct sk_buff *nlskb)
static int sk_diag_dump_vfs(struct sock *sk, struct sk_buff *nlskb)
{
- struct dentry *dentry = unix_sk(sk)->path.dentry;
+ struct unix_diag_vfs uv;
+ struct dentry *dentry;
+ bool have_vfs = false;
+ unix_state_lock(sk);
+ dentry = unix_sk(sk)->path.dentry;
if (dentry) {
- struct unix_diag_vfs uv = {
- .udiag_vfs_ino = d_backing_inode(dentry)->i_ino,
- .udiag_vfs_dev = dentry->d_sb->s_dev,
- };
-
- return nla_put(nlskb, UNIX_DIAG_VFS, sizeof(uv), &uv);
+ uv.udiag_vfs_ino = d_backing_inode(dentry)->i_ino;
+ uv.udiag_vfs_dev = dentry->d_sb->s_dev;
+ have_vfs = true;
}
+ unix_state_unlock(sk);
- return 0;
+ if (!have_vfs)
+ return 0;
+
+ return nla_put(nlskb, UNIX_DIAG_VFS, sizeof(uv), &uv);
}
static int sk_diag_dump_peer(struct sock *sk, struct sk_buff *nlskb)
--
2.34.1
^ permalink raw reply related
* Re: [net-next PATCH 06/10] net: dsa: realtek: rtl8365mb: add VLAN support
From: Linus Walleij @ 2026-04-07 7:59 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260331-realtek_forward-v1-6-44fb63033b7e@gmail.com>
Hi Luiz, Alvin,
thanks for your patch!
On Wed, Apr 1, 2026 at 1:00 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
>
> Realtek RTL8365MB switches (a.k.a. RTL8367C family) use two different
> structures for VLANs:
>
> - VLAN4K: A full table with 4096 entries defining port membership and
> tagging.
> - VLANMC: A smaller table with 32 entries used primarily for PVID
> assignment.
>
> In this hardware, a port's PVID must point to an index in the VLANMC
> table rather than a VID directly. Since the VLANMC table is limited to
> 32 entries, the driver implements a dynamic allocation scheme to
> maximize resource usage:
>
> - VLAN4K is treated by the driver as the source of truth for membership.
> - A VLANMC entry is only allocated when a port is configured to use a
> specific VID as its PVID.
> - VLANMC entries are deleted when no longer needed as a PVID by any port.
>
> Although VLANMC has a members field, the switch only checks membership
> in the VLAN4K table. However, when a corresponding VLAN entry also exists
> in VLANMC, this driver keeps both membership configurations in sync.
>
> VLANMC index 0, although a valid entry, is reserved in this driver as a
> neutral PVID value for ports not using a specific PVID.
>
> In the subsequent RTL8367D switch family, VLANMC table was
> removed and PVID assignment was delegated to a dedicated set of
> registers.
>
> All ports start isolated, forwarding exclusively to CPU ports, and
> with VLAN transparent, ignoring VLAN membership. Once a member in a
> bridge, the port isolation is expanded to include the bridge members.
> When that bridge enables VLAN filtering, the VLAN transparent feature is
> disabled, letting the switch filter based on VLAN setup.
>
> Co-developed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
This patch ignores the existing abstractions for generic RTL8366 VLAN
handling in rtl8366-core.c and realtek.h, which is actually compiled
and bundled into the same object with the RTL8365MB driver.
It provides rtl8366_vlan_add(), rtl8366_vlan_del(), rtl8366_enable_vlan(),
rtl8366_enable_vlan4k(), rtl8366_set_pvid(), rtl8366_set_vlan().
The RTL8366RB notably has the same 32 PVID thing and the
same 4K VLAN table.
I understand that it is always easier to develop and test something
for "just this one chip", but I predictably have to be the one to ask
if this can be done in the shared code.
You need to either:
- Take a second sweep and refactor to share the existing VLAN
handling with RTL8366RB (preferred).
- Explain why RTL8365MB is so very different that it cannot share
code with RTL8366RB, then proceed to move all code from
rtl8366-core.c into the RTL8366RB driver, change prefix of functions
and generally make it local so it doesn't bloat the
RTL8365MB code before adding this.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2] net: fix skb_ext_total_length() BUILD_BUG_ON with CONFIG_GCOV_PROFILE_ALL
From: Paolo Abeni @ 2026-04-07 7:55 UTC (permalink / raw)
To: Konstantin Khorenko, David S . Miller, Eric Dumazet,
Jakub Kicinski
Cc: Simon Horman, Thomas Weißschuh, Arnd Bergmann,
Peter Oberparleiter, Mikhail Zaslonko, netdev, linux-kernel,
Pavel Tikhomirov, Vasileios Almpanis
In-Reply-To: <20260402140558.1437002-2-khorenko@virtuozzo.com>
On 4/2/26 4:05 PM, Konstantin Khorenko wrote:
> When CONFIG_GCOV_PROFILE_ALL=y is enabled, the kernel fails to build:
>
> In file included from <command-line>:
> In function 'skb_extensions_init',
> inlined from 'skb_init' at net/core/skbuff.c:5214:2:
> ././include/linux/compiler_types.h:706:45: error: call to
> '__compiletime_assert_1490' declared with attribute error:
> BUILD_BUG_ON failed: skb_ext_total_length() > 255
>
> CONFIG_GCOV_PROFILE_ALL adds -fprofile-arcs -ftest-coverage
> -fno-tree-loop-im to CFLAGS globally. GCC inserts branch profiling
> counters into the skb_ext_total_length() loop and, combined with
> -fno-tree-loop-im (which disables loop invariant motion), cannot
> constant-fold the result.
> BUILD_BUG_ON requires a compile-time constant and fails.
>
> The issue manifests in kernels with 5+ SKB extension types enabled
> (e.g., after addition of SKB_EXT_CAN, SKB_EXT_PSP). With 4 extensions
> GCC can still unroll and fold the loop despite GCOV instrumentation;
> with 5+ it gives up.
>
> Mark skb_ext_total_length() with __no_profile to prevent GCOV from
> inserting counters into this function. Without counters the loop is
> "clean" and GCC can constant-fold it even with -fno-tree-loop-im active.
> This allows BUILD_BUG_ON to work correctly while keeping GCOV profiling
> for the rest of the kernel.
>
> This also removes the CONFIG_KCOV_INSTRUMENT_ALL preprocessor guard
> introduced by d6e5794b06c0, as __no_profile handles both GCOV and KCOV
> instrumentation at the root cause level rather than just disabling the
> check.
>
> Fixes: 5d21d0a65b57 ("net: generalize calculation of skb extensions length")
> Fixes: d6e5794b06c0 ("net: avoid build bug in skb extension length calculation")
>
> Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
No empty lines in the tags area.
Also given the commit description, isn't the introduction of the 5th skb
extension a better fixes tag?
> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> net/core/skbuff.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 0e217041958a..47c7f0ab6e84 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -5145,7 +5145,7 @@ static const u8 skb_ext_type_len[] = {
> #endif
> };
>
> -static __always_inline unsigned int skb_ext_total_length(void)
> +static __always_inline __no_profile unsigned int skb_ext_total_length(void)
> {
> unsigned int l = SKB_EXT_CHUNKSIZEOF(struct skb_ext);
> int i;
> @@ -5159,9 +5159,7 @@ static __always_inline unsigned int skb_ext_total_length(void)
> static void skb_extensions_init(void)
> {
> BUILD_BUG_ON(SKB_EXT_NUM > 8);
> -#if !IS_ENABLED(CONFIG_KCOV_INSTRUMENT_ALL)
> BUILD_BUG_ON(skb_ext_total_length() > 255);
> -#endif
Sashiko notes that there could be still build breakage:
https://sashiko.dev/#/patchset/20260402140558.1437002-1-khorenko%40virtuozzo.com
Could you please double check the above?
I think a 'noinline' in skb_extensions_init() would address any
complains on patch 2/2
/P
>
> skbuff_ext_cache = kmem_cache_create("skbuff_ext_cache",
> SKB_EXT_ALIGN_VALUE * skb_ext_total_length(),
^ permalink raw reply
* Re: [PATCH net v1 1/2] net/rds: Optimize rds_ib_laddr_check
From: Allison Henderson @ 2026-04-07 7:55 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: rds-devel, edumazet, linux-rdma, horms, pabeni, netdev
In-Reply-To: <20260407011900.3596320-1-kuba@kernel.org>
On Mon, 2026-04-06 at 18:19 -0700, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
>
> For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
> ---
> net/rds: Optimize rds_ib_laddr_check
>
> This patch optimizes rds_ib_laddr_check() to avoid excessive
> rdma_bind_addr() calls by checking if an address has been used before.
> It renames the original function to rds_ib_laddr_check_cm() and
> introduces a new wrapper that first checks rds_ib_get_device() before
> falling back to the CM-based check.
>
> > diff --git a/net/rds/ib.c b/net/rds/ib.c
> > index ac6affa33ce7..73e01984ee9a 100644
> > --- a/net/rds/ib.c
> > +++ b/net/rds/ib.c
> > @@ -401,8 +401,8 @@ static void rds6_ib_ic_info(struct socket *sock, unsigned int len,
> > * allowed to influence which paths have priority. We could call userspace
> > * asserting this policy "routing".
> > */
> > -static int rds_ib_laddr_check(struct net *net, const struct in6_addr *addr,
> > - __u32 scope_id)
> > +static int rds_ib_laddr_check_cm(struct net *net, const struct in6_addr *addr,
> > + __u32 scope_id)
> > {
> > int ret;
> > struct rdma_cm_id *cm_id;
>
> [ ... ]
>
> > @@ -487,6 +487,20 @@ static int rds_ib_laddr_check(struct net *net, const struct in6_addr *addr,
> > return ret;
> > }
> >
> > +static int rds_ib_laddr_check(struct net *net, const struct in6_addr *addr,
> > + __u32 scope_id)
> > +{
> > + struct rds_ib_device *rds_ibdev = rds_ib_get_device(addr->s6_addr32[3]);
> > +
> > + if (rds_ibdev) {
> > + rds_ib_dev_put(rds_ibdev);
> > +
> > + return 0;
> > + }
> > +
> > + return rds_ib_laddr_check_cm(net, addr, scope_id);
> > +}
> > +
>
> Can this code handle pure IPv6 addresses correctly? The function extracts
> addr->s6_addr32[3] and passes it to rds_ib_get_device(), which looks up
> devices by IPv4 address.
>
> For IPv4-mapped IPv6 addresses, addr->s6_addr32[3] contains the IPv4
> address. But for pure IPv6 addresses (when CONFIG_IPV6 is enabled),
> addr->s6_addr32[3] contains the last 32 bits of the IPv6 address, which
> could accidentally match a stored IPv4 address.
>
> When this collision occurs, the function returns 0 (success) without
> calling rds_ib_laddr_check_cm(), which performs the full validation
> including rdma_bind_addr() and IPv6 link-local scope_id checks. This
> means a pure IPv6 address could be incorrectly accepted as valid for IB
> transport.
>
> Should this be guarded with an ipv6_addr_v4mapped(addr) check? For
> example:
>
> if (ipv6_addr_v4mapped(addr)) {
> rds_ibdev = rds_ib_get_device(addr->s6_addr32[3]);
> ...
> }
>
> The existing callers of rds_ib_get_device (rds_ib_get_mr,
> rds_ib_update_ipaddr) operate in post-connection contexts where the
> address type is already validated, but rds_ib_laddr_check is the
> validation gate called during bind/transport-selection for any address
> type.
Ok I think the correct ports to fix this would be these two commits:
https://github.com/oracle/linux-uek/commit/caffdcae6593
caffdcae6593 ("rds: Enable RDS IPv6 support")
https://github.com/oracle/linux-uek/commit/cb82f22bbff5
cb82f22bbff5 ("rds: Changed IP address internal representation to struct in6_addr")
But that is starting to snowball quite a bit outside the scope of the syzbot bug, and a lot of rds port patches tend to
domino like this if we don't find a way to contain it. So for the syzbot report, I think the ai suggestion is
reasonable. So, if folks agree, I am fine to add that check in v2.
Thank you!
Allison
>
> > static void rds_ib_unregister_client(void)
> > {
> > ib_unregister_client(&rds_ib_client);
>
> [ ... ]
^ permalink raw reply
* Re: [PATCH net v1 1/2] net/rds: Optimize rds_ib_laddr_check
From: Allison Henderson @ 2026-04-07 7:54 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, pabeni, edumazet, rds-devel, horms, linux-rdma
In-Reply-To: <20260406181957.4bba8580@kernel.org>
On Mon, 2026-04-06 at 18:19 -0700, Jakub Kicinski wrote:
> On Sat, 4 Apr 2026 21:16:12 -0700 Allison Henderson wrote:
> > From: Håkon Bugge <haakon.bugge@oracle.com>
>
> > Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com>
> > Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
> > Signed-off-by: Allison Henderson <achender@kernel.org>
>
> Author's sign-off missing on this patch (I sent out the AI reviews
> as well, without looking, take them with a grain of salt).
Yes, Håkon's sob should be here, I will add it.
Thanks!
Allison
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] bpf-timestamp: keep track of the skb when wait_for_space occurs
From: Jason Xing @ 2026-04-07 7:43 UTC (permalink / raw)
To: Willem de Bruijn
Cc: davem, edumazet, kuba, pabeni, horms, willemb, martin.lau, netdev,
bpf, Jason Xing, Yushan Zhou
In-Reply-To: <CAL+tcoAvVBN7juJEBt5-FYQ4eGTe7dYrFbR3CMOwguw=_X=btA@mail.gmail.com>
On Tue, Apr 7, 2026 at 11:33 AM Jason Xing <kerneljasonxing@gmail.com> wrote:
>
> On Mon, Apr 6, 2026 at 10:37 PM Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
> >
> > Jason Xing wrote:
> > > On Mon, Apr 6, 2026 at 10:28 AM Willem de Bruijn
> > > <willemdebruijn.kernel@gmail.com> wrote:
> > > >
> > > > Jason Xing wrote:
> > > > > From: Jason Xing <kernelxing@tencent.com>
> > > > >
> > > > > The patch is the 1/2 part of push-level granularity feature.
> > > > >
> > > > > Tag the skb in tcp_sendmsg_locked() when wait_for_space occurs even
> > > > > though it might not carry the last byte of the sendmsg.
> > > > >
> > > > > Prior to the patch, BPF timestamping cannot cover this case:
> > > > > The following steps reproduce this:
> > > > > 1) skb A is the current last skb before entering wait_for_space process
> > > > > 2) tcp_push() pushes A without any tag
> > > > > 3) A is transmitted from TCP to driver without putting any skb carrying
> > > > > timestamps in the error queue, like SCHED, DRV/HARDWARE.
> > > > > 4) sk_stream_wait_memory() sleeps for a while and then returns with an
> > > > > error code. Note that the socket lock is released.
> > > > > 5) skb A finally gets acked and removed from the rtx queue.
> > > > > 6) continue with the rest of tcp_sendmsg_locked(): it will jump to(goto)
> > > > > 'do_error' label and then 'out' label.
> > > > > 7) at this moment, skb A turns out to be the last one in this send
> > > > > syscall, and miss the following tcp_bpf_tx_timestamp() opportunity
> > > > > before the final tcp_push()
> > > > > 8) BPF script fails to see any timestamps this time
> > > > >
> > > > > Signed-off-by: Yushan Zhou <katrinzhou@tencent.com>
> > > > > Signed-off-by: Jason Xing <kernelxing@tencent.com>
> > > > > ---
> > > > > net/ipv4/tcp.c | 4 +++-
> > > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> > > > > index c603b90057f6..7d030a11d004 100644
> > > > > --- a/net/ipv4/tcp.c
> > > > > +++ b/net/ipv4/tcp.c
> > > > > @@ -1400,9 +1400,11 @@ int tcp_sendmsg_locked(struct sock *sk, struct msghdr *msg, size_t size)
> > > > > wait_for_space:
> > > > > set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
> > > > > tcp_remove_empty_skb(sk);
> > > > > - if (copied)
> > > > > + if (copied) {
> > > > > + tcp_bpf_tx_timestamp(sk);
> > > > > tcp_push(sk, flags & ~MSG_MORE, mss_now,
> > > > > TCP_NAGLE_PUSH, size_goal);
> > > >
> > > > Now the number of skbs that will be tracked will be unpredictable,
> > > > varying based on memory pressure.
> > >
> > > Right, I put some effort into writing a selftests to check how many
> > > push functions get called at one time and failed to do so.
> > >
> > > >
> > > > That sounds hard to use to me. Especially if these extra pushes
> > > > cannot be identified as such.
> > > >
> > > > Perhaps if all skbs from the same sendmsg call can be identified,
> > > > that would help explain pattern in data resulting from these
> > > > uncommon extra data points.
> > >
> > > You meant move tcp_bpf_tx_timestamp before tcp_skb_entail()? That is
> > > close to packet basis without considering fragmentation of skb :)
> >
> > No, I meant somehow in the notification having a way to identify all
> > the skbs belonging to the same sendmsg call, to allow filtering on
> > that. But I also don't immediately see how to do that (without adding
> > yet another counter say).
>
> If we don't build the relationship between skb and sendmsg (just like
> the SENDMSG sock option), we will have no clue on how to calculate. If
> we only take care of the skb from the view of the syscall layer, it's
> fine by moving tcp_bpf_tx_timestamp() before tcp_skb_entail(). But in
> terms of per skb even generated beneath TCP due to gso/tso, there is
> only one way to correlate: adding an additional member in the skb
> structure to store its sendmsg time. This discussion is only suitable
> for use cases like net_timestamping.
>
> Well, my key point is that, I have to admit, the above (including
> existing bpf script net_timestamping) is a less effective way which
> definitely harms the performance because of the extremely frequent
> look-up process. It's not suitable for 7x24 observability in
> production. What we've done internally is make the kernel layer as
> lightweight/easy as possible and let the timestamping feature throw
> each record into a ring buffer that the application can read, sort and
> calculate. This arch survives the performance. But that's simply what
> the design of the kernel module is, given the fast deployment in
> production. I suppose in the future we could build a userspace tool
> like blktrace to monitor efficiently instead of the selftest sample.
> Honestly I don't like look-up action.
>
> Since we're modifying the kernel, how about adding a new member to
> record sendmsg time which bpf script is able to read. The whole
> scenario looks like this:
> 1) in tcp_sendmsg_locked(), record the sendmsg time for each skb
> 2) in either tso_fragment() or tcp_gso_tstamp(), each new skb will get
> a copy of its original skb
> 3) in each stage, bpf script reads the skb's sendmsg time and the
> current time, and then effortlessly do the math.
>
> At this point, what I had in mind is we have two options:
> 1) only handle the skb from the view of the send syscall layer, which
> is, for sure, very simple but not thorough.
> 2) stick to a pure authentic packet basis, then adding a new member
> seems inevitable. so the question would be where to add? The space of
> the skb structure is very precious :(
Finding a suitable place to put this timestamp is really hard. IIRC,
we can't expand the size of struct skb_shared_info so easily since
it's a global effect.
I'm wondering if we can turn the per-packet mode into a non-compatible
feature by reusing 'u32 tskey' to store a microsecond timestamp of
sendmsg.
Thanks,
Jason
^ permalink raw reply
* Re: [net-next PATCH 05/10] net: dsa: realtek: rtl8365mb: add table lookup interface
From: Linus Walleij @ 2026-04-07 7:43 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260331-realtek_forward-v1-5-44fb63033b7e@gmail.com>
On Wed, Apr 1, 2026 at 1:00 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
>
> Add a generic table lookup interface to centralize access to
> the RTL8365MB internal tables.
>
> This interface abstracts the low-level table access logic and
> will be used by subsequent commits to implement FDB and VLAN
> operations.
>
> Co-developed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net] net: txgbe: fix RTNL assertion warning when remove module
From: Russell King (Oracle) @ 2026-04-07 7:40 UTC (permalink / raw)
To: Jiawen Wu
Cc: netdev, 'Mengyuan Lou', 'Andrew Lunn',
'David S. Miller', 'Eric Dumazet',
'Jakub Kicinski', 'Paolo Abeni',
'Simon Horman', 'Jacob Keller',
'Abdun Nihaal', stable
In-Reply-To: <096d01dcc657$9ee42b00$dcac8100$@trustnetic.com>
On Tue, Apr 07, 2026 at 02:27:34PM +0800, Jiawen Wu wrote:
> On Wed, Apr 1, 2026 2:22 PM, Russell King (Oracle) wrote:
> > On Wed, Apr 01, 2026 at 10:16:34AM +0800, Jiawen Wu wrote:
> > > On Tue, Mar 31, 2026 9:08 PM, Russell King (Oracle) wrote:
> > > > On Tue, Mar 31, 2026 at 03:11:07PM +0800, Jiawen Wu wrote:
> > > > > For the copper NIC with external PHY, the driver called
> > > > > phylink_connect_phy() during probe and phylink_disconnect_phy() during
> > > > > remove. It caused an RTNL assertion warning in phylink_disconnect_phy()
> > > > > upon module remove.
> > > > >
> > > > > To fix this, move the phylink connect/disconnect PHY to ndo_open/close.
> > > >
> > > > Wouldn't it be simpler to just wrap the phylink_disconnect_phy() in the
> > > > remove function with rtnl_lock()..rtnl_unlock() ?
> > >
> > > This is also a solution. But I think it would be nice to unify with other drivers
> > > that call the functions in ndo_open/close.
> >
> > Both approaches are equally valid. Some network drivers attach the PHY
> > at probe time (and thus can return -EPROBE_DEFER if the PHY is specified
> > but not present). Others attach in .ndo_open which can only fail in this
> > circumstance with no retry without userspace manually implementing that.
> >
> > There are other advantages and disadvantages to each approach.
>
> Hi,
>
> So is it still recommended that add rtnl_lock()...rtnl_unlock() instead of moving it?
The reaosn phylink_disconnect_phy() requires the RTNL lock is because it
_can_ be called while the netdev is published, and the RTNL lock
protects the networking core from the PHY being removed from the netdev,
preventing ethtool ops into the PHY driver from running concurrently
with the PHY's disconnection and potential later destruction.
Offering two APIs, one which requires the lock to provide that
protection and one which doesn't would over-complicate the phylink code
and make reviews way more difficult, as we'd now have to spot the
wrong function being used in the wrong code path.
It's simpler for drivers that want to connect and disconnect the PHY
at probe/remove time for them to just take the RTNL lock briefly over
the call to phylink_disconnect_phy().
There is no "recommendation" for connecting and disconnecting the
PHY at probe/remove time vs ndo_open/ndo_release. That's entirely up
to the driver author. As I've already said, there are advantages and
disadvantages of either way and that's a matter for the driver author
to consider and select the most appropriate choice for their driver.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH net-next v8 00/11] net: tunnel: introduce noref xmit flows for tunnels
From: Paolo Abeni @ 2026-04-07 7:39 UTC (permalink / raw)
To: Marek Mietus, netdev, sd, kuba; +Cc: Jason
In-Reply-To: <bbb2b833-a9a9-4558-8d4b-1b041f6706d7@yahoo.com>
On 4/6/26 9:58 AM, Marek Mietus wrote:
> W dniu 17.03.2026 o 12:37, Paolo Abeni pisze:
>> On 3/12/26 4:56 PM, Marek Mietus wrote:
>>> Currently, tunnel xmit flows always take a reference on the dst_entry
>>> for each xmitted packet. These atomic operations are redundant in some
>>> flows.
>>>
>>> This patchset introduces the infrastructure required for converting
>>> the tunnel xmit flows to noref, and converts them where possible.
>>>
>>> These changes improve tunnel performance, since less atomic operations
>>> are used.
>>>
>>> There are already noref optimizations in both ipv4 and ip6.
>>> (See __ip_queue_xmit, inet6_csk_xmit)
>>> This patchset implements similar optimizations in ip and udp tunnels.
>>>
>>> Benchmarks:
>>> I used a vxlan tunnel over a pair of veth peers and measured the average
>>> throughput over multiple samples.
>>>
>>> I ran 100 samples on a clean build, and another 100 on a patched
>>> build. Each sample ran for 120 seconds. These were my results:
>>>
>>> clean: 72.52 gb/sec, stddev = 1.39
>>> patched: 75.39 gb/sec, stddev = 0.94
>>>
>>> TL;DR - This patchset results in a 4% improvement in throughput for
>>> vxlan. It's safe to assume that we might see similar results when testing
>>> other tunnels.
>>
>> Sabrina noted I wrongly replied on an old revision. Reporting my
>> statements here for completeness.
>>
>> IMHO this performance delta is not enough to justify this amount of changes.
>>
>> Additionally, the measured impact of removing the dst_hold/dst_release
>> does not fit with my direct experience on the same matter: it should be
>> below noise level in practice, as dst are per-cpu and and no
>> contention/false sharing is expected in a good setup.
>>
>> I think you are observing larger impact because in the veth test
>> dst_release can happen on a remote CPU. Note that this setup (vxlan over
>> veth) is not very relevant in practice.
>>
>> I'm sorry I'm not applying this series.
>>
>> Side note: if you are interested into improving (UDP) tunnel
>> performances have a look to big TCP support work from Alice Mikityanska:
>>
>> https://lore.kernel.org/netdev/20260226201600.222044-1-alice.kernel@fastmail.im/
>>
>> /P
>>
>>
>
> Hi Paolo,
>
> Could you clarify what would be a more realistic test setup? I'm assuming using physical interfaces would yield more realistic results.
> Also, what performance benefit would be worth this kind of "code churn"? What kind of margins were you looking for?
veth devices hides a significant part of the memory buffer lifecycles,
as there is a single allocation/free for both sender and receiver. Using
reasonably fast/recent H/W NICs would make the figures much more relevant.
Given the amount of changes included in this series, I think that a
performance improvement well above the noise range in a relevant test
case would be needed to justify it. If you really want a figure, I would
say 5%. Note that the main difference WRT your testing is the setup itself.
To be completely open, I don't see how the refcount change could come
near such figure, as in my testing on H/W NICs the total reference
counting cost is usually well below noise level.
/P
^ permalink raw reply
* Re: [net-next PATCH 03/10] net: dsa: realtek: rtl8365mb: prepare for multiple source files
From: Linus Walleij @ 2026-04-07 7:35 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260331-realtek_forward-v1-3-44fb63033b7e@gmail.com>
On Wed, Apr 1, 2026 at 1:00 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
>
> Rename rtl8365mb.c to rtl8365mb_main.c in preparation for subsequent
> commits which add additional source files to the driver.
>
> The trailing backslash in the Makefile is deliberate. It allows for new
> files to be added without clobbering git history.
>
> Co-developed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
I can't really see from the patch if the line below the backslash is empty and
that is why this bisects fine, but if this compiles fine then OK.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [net-next PATCH 01/10] net: dsa: tag_rtl8_4: update format description
From: Linus Walleij @ 2026-04-07 7:33 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260331-realtek_forward-v1-1-44fb63033b7e@gmail.com>
On Wed, Apr 1, 2026 at 1:00 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
>
> Document the updated tag layout fields (EFID, VSEL/VIDX) and clarify
> which bits are set/cleared when emitting tags.
>
> Co-developed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 8/9] driver core: Replace dev->of_node_reused with dev_of_node_reused()
From: Manivannan Sadhasivam @ 2026-04-07 7:27 UTC (permalink / raw)
To: Douglas Anderson
Cc: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern, Alexey Kardashevskiy, Johan Hovold, Eric Dumazet,
Leon Romanovsky, Christoph Hellwig, Robin Murphy, maz,
Alexander Lobakin, Saravana Kannan, Mark Brown, alexander.stein,
andrew, andrew, andriy.shevchenko, astewart, bhelgaas, brgl,
davem, devicetree, driver-core, hkallweit1, jirislaby, joel, kees,
kuba, lgirdwood, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pci, linux-serial, linux-usb, linux, netdev, pabeni, robh
In-Reply-To: <20260406162231.v5.8.I806b8636cd3724f6cd1f5e199318ab8694472d90@changeid>
On Mon, Apr 06, 2026 at 04:23:01PM -0700, Douglas Anderson wrote:
> In C, bitfields are not necessarily safe to modify from multiple
> threads without locking. Switch "of_node_reused" over to the "flags"
> field so modifications are safe.
>
> Cc: Johan Hovold <johan@kernel.org>
> Acked-by: Mark Brown <broonie@kernel.org>
> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
> Reviewed-by: Danilo Krummrich <dakr@kernel.org>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org> # PCI_PWRCTRL
- Mani
> ---
> Not fixing any known bugs; problem is theoretical and found by code
> inspection. Change is done somewhat manually and only lightly tested
> (mostly compile-time tested).
>
> (no changes since v4)
>
> Changes in v4:
> - Use accessor functions for flags
>
> Changes in v3:
> - New
>
> drivers/base/core.c | 2 +-
> drivers/base/pinctrl.c | 2 +-
> drivers/base/platform.c | 2 +-
> drivers/net/pcs/pcs-xpcs-plat.c | 2 +-
> drivers/of/device.c | 6 +++---
> drivers/pci/of.c | 2 +-
> drivers/pci/pwrctrl/core.c | 2 +-
> drivers/regulator/bq257xx-regulator.c | 2 +-
> drivers/regulator/rk808-regulator.c | 2 +-
> drivers/tty/serial/serial_base_bus.c | 2 +-
> drivers/usb/gadget/udc/aspeed-vhub/dev.c | 2 +-
> include/linux/device.h | 7 ++++---
> 12 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 8a83d7c93361..30825bf83234 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -5283,7 +5283,7 @@ void device_set_of_node_from_dev(struct device *dev, const struct device *dev2)
> {
> of_node_put(dev->of_node);
> dev->of_node = of_node_get(dev2->of_node);
> - dev->of_node_reused = true;
> + dev_set_of_node_reused(dev);
> }
> EXPORT_SYMBOL_GPL(device_set_of_node_from_dev);
>
> diff --git a/drivers/base/pinctrl.c b/drivers/base/pinctrl.c
> index 6e250272c843..0bbc83231234 100644
> --- a/drivers/base/pinctrl.c
> +++ b/drivers/base/pinctrl.c
> @@ -24,7 +24,7 @@ int pinctrl_bind_pins(struct device *dev)
> {
> int ret;
>
> - if (dev->of_node_reused)
> + if (dev_of_node_reused(dev))
> return 0;
>
> dev->pins = devm_kzalloc(dev, sizeof(*(dev->pins)), GFP_KERNEL);
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index d44591d52e36..199e6fb25770 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -856,7 +856,7 @@ struct platform_device *platform_device_register_full(
> pdev->dev.parent = pdevinfo->parent;
> pdev->dev.fwnode = pdevinfo->fwnode;
> pdev->dev.of_node = of_node_get(to_of_node(pdev->dev.fwnode));
> - pdev->dev.of_node_reused = pdevinfo->of_node_reused;
> + dev_assign_of_node_reused(&pdev->dev, pdevinfo->of_node_reused);
>
> if (pdevinfo->dma_mask) {
> pdev->platform_dma_mask = pdevinfo->dma_mask;
> diff --git a/drivers/net/pcs/pcs-xpcs-plat.c b/drivers/net/pcs/pcs-xpcs-plat.c
> index b8c48f9effbf..f4b1b8246ce9 100644
> --- a/drivers/net/pcs/pcs-xpcs-plat.c
> +++ b/drivers/net/pcs/pcs-xpcs-plat.c
> @@ -349,7 +349,7 @@ static int xpcs_plat_init_dev(struct dw_xpcs_plat *pxpcs)
> * up later. Make sure DD-core is aware of the OF-node being re-used.
> */
> device_set_node(&mdiodev->dev, fwnode_handle_get(dev_fwnode(dev)));
> - mdiodev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&mdiodev->dev);
>
> /* Pass the data further so the DW XPCS driver core could use it */
> mdiodev->dev.platform_data = (void *)device_get_match_data(dev);
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index f7e75e527667..be4e1584e0af 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -26,7 +26,7 @@
> const struct of_device_id *of_match_device(const struct of_device_id *matches,
> const struct device *dev)
> {
> - if (!matches || !dev->of_node || dev->of_node_reused)
> + if (!matches || !dev->of_node || dev_of_node_reused(dev))
> return NULL;
> return of_match_node(matches, dev->of_node);
> }
> @@ -192,7 +192,7 @@ ssize_t of_device_modalias(struct device *dev, char *str, ssize_t len)
> {
> ssize_t sl;
>
> - if (!dev || !dev->of_node || dev->of_node_reused)
> + if (!dev || !dev->of_node || dev_of_node_reused(dev))
> return -ENODEV;
>
> sl = of_modalias(dev->of_node, str, len - 2);
> @@ -254,7 +254,7 @@ int of_device_uevent_modalias(const struct device *dev, struct kobj_uevent_env *
> {
> int sl;
>
> - if ((!dev) || (!dev->of_node) || dev->of_node_reused)
> + if ((!dev) || (!dev->of_node) || dev_of_node_reused(dev))
> return -ENODEV;
>
> /* Devicetree modalias is tricky, we add it in 2 steps */
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index 9f8eb5df279e..1f9b669abdb0 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -38,7 +38,7 @@ int pci_set_of_node(struct pci_dev *dev)
> struct device *pdev __free(put_device) =
> bus_find_device_by_of_node(&platform_bus_type, node);
> if (pdev)
> - dev->bus->dev.of_node_reused = true;
> + dev_set_of_node_reused(&dev->bus->dev);
>
> device_set_node(&dev->dev, of_fwnode_handle(no_free_ptr(node)));
> return 0;
> diff --git a/drivers/pci/pwrctrl/core.c b/drivers/pci/pwrctrl/core.c
> index 7754baed67f2..72963a92362a 100644
> --- a/drivers/pci/pwrctrl/core.c
> +++ b/drivers/pci/pwrctrl/core.c
> @@ -39,7 +39,7 @@ static int pci_pwrctrl_notify(struct notifier_block *nb, unsigned long action,
> * If we got here then the PCI device is the second after the
> * power control platform device. Mark its OF node as reused.
> */
> - dev->of_node_reused = true;
> + dev_set_of_node_reused(dev);
> break;
> }
>
> diff --git a/drivers/regulator/bq257xx-regulator.c b/drivers/regulator/bq257xx-regulator.c
> index dab8f1ab4450..40e0f1a7ae81 100644
> --- a/drivers/regulator/bq257xx-regulator.c
> +++ b/drivers/regulator/bq257xx-regulator.c
> @@ -143,7 +143,7 @@ static int bq257xx_regulator_probe(struct platform_device *pdev)
> struct regulator_config cfg = {};
>
> pdev->dev.of_node = pdev->dev.parent->of_node;
> - pdev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&pdev->dev);
>
> pdata = devm_kzalloc(&pdev->dev, sizeof(struct bq257xx_reg_data), GFP_KERNEL);
> if (!pdata)
> diff --git a/drivers/regulator/rk808-regulator.c b/drivers/regulator/rk808-regulator.c
> index e66408f23bb6..8297d31cde9f 100644
> --- a/drivers/regulator/rk808-regulator.c
> +++ b/drivers/regulator/rk808-regulator.c
> @@ -2115,7 +2115,7 @@ static int rk808_regulator_probe(struct platform_device *pdev)
> int ret, i, nregulators;
>
> pdev->dev.of_node = pdev->dev.parent->of_node;
> - pdev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&pdev->dev);
>
> regmap = dev_get_regmap(pdev->dev.parent, NULL);
> if (!regmap)
> diff --git a/drivers/tty/serial/serial_base_bus.c b/drivers/tty/serial/serial_base_bus.c
> index a12935f6b992..5f23284a8778 100644
> --- a/drivers/tty/serial/serial_base_bus.c
> +++ b/drivers/tty/serial/serial_base_bus.c
> @@ -74,7 +74,7 @@ static int serial_base_device_init(struct uart_port *port,
> dev->parent = parent_dev;
> dev->bus = &serial_base_bus_type;
> dev->release = release;
> - dev->of_node_reused = true;
> + dev_set_of_node_reused(dev);
>
> device_set_node(dev, fwnode_handle_get(dev_fwnode(parent_dev)));
>
> diff --git a/drivers/usb/gadget/udc/aspeed-vhub/dev.c b/drivers/usb/gadget/udc/aspeed-vhub/dev.c
> index 2ecd049dacc2..8b9449d16324 100644
> --- a/drivers/usb/gadget/udc/aspeed-vhub/dev.c
> +++ b/drivers/usb/gadget/udc/aspeed-vhub/dev.c
> @@ -593,7 +593,7 @@ int ast_vhub_init_dev(struct ast_vhub *vhub, unsigned int idx)
> d->gadget.max_speed = USB_SPEED_HIGH;
> d->gadget.speed = USB_SPEED_UNKNOWN;
> d->gadget.dev.of_node = vhub->pdev->dev.of_node;
> - d->gadget.dev.of_node_reused = true;
> + dev_set_of_node_reused(&d->gadget.dev);
>
> rc = usb_add_gadget_udc(d->port_dev, &d->gadget);
> if (rc != 0)
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 5b0fb6ad4c72..a79865a212e9 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -483,6 +483,8 @@ struct device_physical_location {
> * driver/bus sync_state() callback.
> * @DEV_FLAG_DMA_COHERENT: This particular device is dma coherent, even if the
> * architecture supports non-coherent devices.
> + * @DEV_FLAG_OF_NODE_REUSED: Set if the device-tree node is shared with an
> + * ancestor device.
> */
> enum struct_device_flags {
> DEV_FLAG_READY_TO_PROBE = 0,
> @@ -492,6 +494,7 @@ enum struct_device_flags {
> DEV_FLAG_DMA_OPS_BYPASS = 4,
> DEV_FLAG_STATE_SYNCED = 5,
> DEV_FLAG_DMA_COHERENT = 6,
> + DEV_FLAG_OF_NODE_REUSED = 7,
>
> DEV_FLAG_COUNT
> };
> @@ -573,8 +576,6 @@ enum struct_device_flags {
> *
> * @offline_disabled: If set, the device is permanently online.
> * @offline: Set after successful invocation of bus type's .offline().
> - * @of_node_reused: Set if the device-tree node is shared with an ancestor
> - * device.
> * @flags: DEV_FLAG_XXX flags. Use atomic bitfield operations to modify.
> *
> * At the lowest level, every device in a Linux system is represented by an
> @@ -681,7 +682,6 @@ struct device {
>
> bool offline_disabled:1;
> bool offline:1;
> - bool of_node_reused:1;
>
> DECLARE_BITMAP(flags, DEV_FLAG_COUNT);
> };
> @@ -715,6 +715,7 @@ __create_dev_flag_accessors(dma_skip_sync, DEV_FLAG_DMA_SKIP_SYNC);
> __create_dev_flag_accessors(dma_ops_bypass, DEV_FLAG_DMA_OPS_BYPASS);
> __create_dev_flag_accessors(state_synced, DEV_FLAG_STATE_SYNCED);
> __create_dev_flag_accessors(dma_coherent, DEV_FLAG_DMA_COHERENT);
> +__create_dev_flag_accessors(of_node_reused, DEV_FLAG_OF_NODE_REUSED);
>
> #undef __create_dev_flag_accessors
>
> --
> 2.53.0.1213.gd9a14994de-goog
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH net-next v9 0/4] net: stmmac: Add PCI driver support for BCM8958x
From: Russell King (Oracle) @ 2026-04-07 7:24 UTC (permalink / raw)
To: Jitendra Vegiraju
Cc: netdev, alexandre.torgue, davem, edumazet, kuba, pabeni,
mcoquelin.stm32, bcm-kernel-feedback-list, richardcochran, ast,
daniel, hawk, john.fastabend, rohan.g.thomas, linux-kernel,
linux-stm32, linux-arm-kernel, bpf, andrew+netdev, horms, sdf, me,
siyanteng, prabhakar.mahadev-lad.rj, weishangjuan, wens,
vladimir.oltean, lizhi2, boon.khai.ng, maxime.chevallier,
chenchuangyu, yangtiezhu, ovidiu.panait.rb, chenhuacai,
florian.fainelli, quic_abchauha
In-Reply-To: <20260402213629.1996133-1-jitendra.vegiraju@broadcom.com>
On Thu, Apr 02, 2026 at 02:36:25PM -0700, Jitendra Vegiraju wrote:
> From: Jitendra Vegiraju <jitendra.vegiraju@broadcom.com>
>
> This patchset adds basic PCI ethernet device driver support for Broadcom
> BCM8958x Automotive Ethernet switch SoC devices.
>
> This SoC device has PCIe ethernet MAC attached to an integrated ethernet
> switch using XGMII interface. The PCIe ethernet controller is presented to
> the Linux host as PCI network device.
> Management of integrated ethernet switch on this SoC is not handled via
> the PCIe interface.
>
> The following block diagram gives an overview of the application.
> +=================================+
> | Host CPU/Linux |
> +=================================+
> || PCIe
> ||
> +==========================================+
> | +--------------+ |
> | | PCIE Endpoint| |
> | | Ethernet | |
> | | Controller | |
> | | DMA | |
> | +--------------+ |
> | | MAC | BCM8958X |
> | +--------------+ SoC |
> | || XGMII |
> | || |
> | +--------------+ |
> | | Ethernet | |
> | | switch | |
> | +--------------+ |
> | || || || || |
> +==========================================+
> || || || || More external interfaces
>
> The MAC block on BCM8958x is based on Synopsis XGMAC 4.00a core. This
> MAC IP introduces new DMA architecture called Hyper-DMA for virtualization
> scalability.
>
> Driver functionality specific to new MAC (DW25GMAC) is implemented in
> new file dw25gmac.c.
Sorry for suggesting this rather late, but I recently came across
another stmmac driver in the kernel - drivers/net/ethernet/synopsys.
This is for XLGMAC, but I wonder whether it may be a better bet for
this core. Have you looked at it?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* 回复：[PATCH v10 net-next 04/11] net/nebula-matrix: channel msg value and msg struct
From: Illusion Wang @ 2026-04-07 7:22 UTC (permalink / raw)
To: Mohsin Bashir, Dimon, Alvin, Sam, netdev
Cc: andrew+netdev, corbet, kuba, linux-doc, lorenzo, pabeni, horms,
vadim.fedorenko, lukas.bulwahn, edumazet, enelsonmoore, skhan,
hkallweit1, jani.nikula, open list
In-Reply-To: <0b0eb2e1-7aec-4913-8062-b3eff786a1ae@gmail.com>
> struct nbl_channel_mgt;
> struct nbl_adapter;
>> +enum nbl_chan_msg_type {
>> + NBL_CHAN_MSG_ACK,
>> + NBL_CHAN_MSG_ADD_MACVLAN,
>> + NBL_CHAN_MSG_DEL_MACVLAN,
>> + NBL_CHAN_MSG_ADD_MULTI_RULE,
>> + NBL_CHAN_MSG_DEL_MULTI_RULE,
>> + NBL_CHAN_MSG_SETUP_MULTI_GROUP,
>> + NBL_CHAN_MSG_REMOVE_MULTI_GROUP,
>> + NBL_CHAN_MSG_REGISTER_NET,
>> + NBL_CHAN_MSG_UNREGISTER_NET,
>> + NBL_CHAN_MSG_ALLOC_TXRX_QUEUES,
>> + NBL_CHAN_MSG_FREE_TXRX_QUEUES,
>> + NBL_CHAN_MSG_SETUP_QUEUE,
>> + NBL_CHAN_MSG_REMOVE_ALL_QUEUES,
>> + NBL_CHAN_MSG_CFG_DSCH,
>> + NBL_CHAN_MSG_SETUP_CQS,
>> + NBL_CHAN_MSG_REMOVE_CQS,
>> + NBL_CHAN_MSG_CFG_QDISC_MQPRIO,
>> + NBL_CHAN_MSG_CONFIGURE_MSIX_MAP,
>> + NBL_CHAN_MSG_DESTROY_MSIX_MAP,
>> + NBL_CHAN_MSG_MAILBOX_ENABLE_IRQ,
>> + NBL_CHAN_MSG_GET_GLOBAL_VECTOR,
>> + NBL_CHAN_MSG_GET_VSI_ID,
>> + NBL_CHAN_MSG_SET_PROSISC_MODE,
>> + NBL_CHAN_MSG_GET_FIRMWARE_VERSION,
>> + NBL_CHAN_MSG_GET_QUEUE_ERR_STATS,
>> + NBL_CHAN_MSG_GET_COALESCE,
>> + NBL_CHAN_MSG_SET_COALESCE,
>> + NBL_CHAN_MSG_SET_SPOOF_CHECK_ADDR,
>> + NBL_CHAN_MSG_SET_VF_SPOOF_CHECK,
>> + NBL_CHAN_MSG_GET_RXFH_INDIR_SIZE,
>> + NBL_CHAN_MSG_GET_RXFH_INDIR,
>> + NBL_CHAN_MSG_GET_RXFH_RSS_KEY,
>> + NBL_CHAN_MSG_GET_RXFH_RSS_ALG_SEL,
>> + NBL_CHAN_MSG_GET_HW_CAPS,
>> + NBL_CHAN_MSG_GET_HW_STATE,
>> + NBL_CHAN_MSG_REGISTER_RDMA,
>> + NBL_CHAN_MSG_UNREGISTER_RDMA,
>> + NBL_CHAN_MSG_GET_REAL_HW_ADDR,
>> + NBL_CHAN_MSG_GET_REAL_BDF,
>> + NBL_CHAN_MSG_GRC_PROCESS,
>> + NBL_CHAN_MSG_SET_SFP_STATE,
>> + NBL_CHAN_MSG_SET_ETH_LOOPBACK,
>> + NBL_CHAN_MSG_CHECK_ACTIVE_VF,
>> + NBL_CHAN_MSG_GET_PRODUCT_FLEX_CAP,
>> + NBL_CHAN_MSG_ALLOC_KTLS_TX_INDEX,
>> + NBL_CHAN_MSG_FREE_KTLS_TX_INDEX,
>> + NBL_CHAN_MSG_CFG_KTLS_TX_KEYMAT,
>> + NBL_CHAN_MSG_ALLOC_KTLS_RX_INDEX,
>> + NBL_CHAN_MSG_FREE_KTLS_RX_INDEX,
>> + NBL_CHAN_MSG_CFG_KTLS_RX_KEYMAT,
>> + NBL_CHAN_MSG_CFG_KTLS_RX_RECORD,
>> + NBL_CHAN_MSG_ADD_KTLS_RX_FLOW,
>> + NBL_CHAN_MSG_DEL_KTLS_RX_FLOW,
>> + NBL_CHAN_MSG_ALLOC_IPSEC_TX_INDEX,
>> + NBL_CHAN_MSG_FREE_IPSEC_TX_INDEX,
>> + NBL_CHAN_MSG_ALLOC_IPSEC_RX_INDEX,
>> + NBL_CHAN_MSG_FREE_IPSEC_RX_INDEX,
>> + NBL_CHAN_MSG_CFG_IPSEC_TX_SAD,
>> + NBL_CHAN_MSG_CFG_IPSEC_RX_SAD,
>> + NBL_CHAN_MSG_ADD_IPSEC_TX_FLOW,
>> + NBL_CHAN_MSG_DEL_IPSEC_TX_FLOW,
>> + NBL_CHAN_MSG_ADD_IPSEC_RX_FLOW,
>> + NBL_CHAN_MSG_DEL_IPSEC_RX_FLOW,
>> + NBL_CHAN_MSG_NOTIFY_IPSEC_HARD_EXPIRE,
>> + NBL_CHAN_MSG_GET_MBX_IRQ_NUM,
>> + NBL_CHAN_MSG_CLEAR_FLOW,
>> + NBL_CHAN_MSG_CLEAR_QUEUE,
>> + NBL_CHAN_MSG_GET_ETH_ID,
>> + NBL_CHAN_MSG_SET_OFFLOAD_STATUS,
>> + NBL_CHAN_MSG_INIT_OFLD,
>> + NBL_CHAN_MSG_INIT_CMDQ,
>> + NBL_CHAN_MSG_DESTROY_CMDQ,
>> + NBL_CHAN_MSG_RESET_CMDQ,
>> + NBL_CHAN_MSG_INIT_FLOW,
>> + NBL_CHAN_MSG_DEINIT_FLOW,
>> + NBL_CHAN_MSG_OFFLOAD_FLOW_RULE,
>> + NBL_CHAN_MSG_GET_ACL_SWITCH,
>> + NBL_CHAN_MSG_GET_VSI_GLOBAL_QUEUE_ID,
>> + NBL_CHAN_MSG_INIT_REP,
>> + NBL_CHAN_MSG_GET_LINE_RATE_INFO,
>> + NBL_CHAN_MSG_REGISTER_NET_REP,
>> + NBL_CHAN_MSG_UNREGISTER_NET_REP,
>> + NBL_CHAN_MSG_REGISTER_ETH_REP,
>> + NBL_CHAN_MSG_UNREGISTER_ETH_REP,
>> + NBL_CHAN_MSG_REGISTER_UPCALL_PORT,
>> + NBL_CHAN_MSG_UNREGISTER_UPCALL_PORT,
>> + NBL_CHAN_MSG_GET_PORT_STATE,
>> + NBL_CHAN_MSG_SET_PORT_ADVERTISING,
>> + NBL_CHAN_MSG_GET_MODULE_INFO,
>> + NBL_CHAN_MSG_GET_MODULE_EEPROM,
>> + NBL_CHAN_MSG_GET_LINK_STATE,
>> + NBL_CHAN_MSG_NOTIFY_LINK_STATE,
>> + NBL_CHAN_MSG_GET_QUEUE_CXT,
>> + NBL_CHAN_MSG_CFG_LOG,
>> + NBL_CHAN_MSG_INIT_VDPAQ,
>> + NBL_CHAN_MSG_DESTROY_VDPAQ,
>> + NBL_CHAN_MSG_GET_UPCALL_PORT,
>> + NBL_CHAN_MSG_NOTIFY_ETH_REP_LINK_STATE,
>> + NBL_CHAN_MSG_SET_ETH_MAC_ADDR,
>> + NBL_CHAN_MSG_GET_FUNCTION_ID,
>> + NBL_CHAN_MSG_GET_CHIP_TEMPERATURE,
>> + NBL_CHAN_MSG_DISABLE_HW_FLOW,
>> + NBL_CHAN_MSG_ENABLE_HW_FLOW,
>> + NBL_CHAN_MSG_SET_UPCALL_RULE,
>> + NBL_CHAN_MSG_UNSET_UPCALL_RULE,
>> + NBL_CHAN_MSG_GET_REG_DUMP,
>> + NBL_CHAN_MSG_GET_REG_DUMP_LEN,
>> + NBL_CHAN_MSG_CFG_LAG_HASH_ALGORITHM,
>> + NBL_CHAN_MSG_CFG_LAG_MEMBER_FWD,
>> + NBL_CHAN_MSG_CFG_LAG_MEMBER_LIST,
>> + NBL_CHAN_MSG_CFG_LAG_MEMBER_UP_ATTR,
>> + NBL_CHAN_MSG_ADD_LAG_FLOW,
>> + NBL_CHAN_MSG_DEL_LAG_FLOW,
>> + NBL_CHAN_MSG_SWITCHDEV_INIT_CMDQ,
>> + NBL_CHAN_MSG_SWITCHDEV_DEINIT_CMDQ,
>> + NBL_CHAN_MSG_SET_TC_FLOW_INFO,
>> + NBL_CHAN_MSG_UNSET_TC_FLOW_INFO,
>> + NBL_CHAN_MSG_INIT_ACL,
>> + NBL_CHAN_MSG_UNINIT_ACL,
>> + NBL_CHAN_MSG_CFG_LAG_MCC,
>> + NBL_CHAN_MSG_REGISTER_VSI2Q,
>> + NBL_CHAN_MSG_SETUP_Q2VSI,
>> + NBL_CHAN_MSG_REMOVE_Q2VSI,
>> + NBL_CHAN_MSG_SETUP_RSS,
>> + NBL_CHAN_MSG_REMOVE_RSS,
>> + NBL_CHAN_MSG_GET_REP_QUEUE_INFO,
>> + NBL_CHAN_MSG_CTRL_PORT_LED,
>> + NBL_CHAN_MSG_NWAY_RESET,
>> + NBL_CHAN_MSG_SET_INTL_SUPPRESS_LEVEL,
>> + NBL_CHAN_MSG_GET_ETH_STATS,
>> + NBL_CHAN_MSG_GET_MODULE_TEMPERATURE,
>> + NBL_CHAN_MSG_GET_BOARD_INFO,
>> + NBL_CHAN_MSG_GET_P4_USED,
>> + NBL_CHAN_MSG_GET_VF_BASE_VSI_ID,
>> + NBL_CHAN_MSG_ADD_LLDP_FLOW,
>> + NBL_CHAN_MSG_DEL_LLDP_FLOW,
>> + NBL_CHAN_MSG_CFG_ETH_BOND_INFO,
>> + NBL_CHAN_MSG_CFG_DUPPKT_MCC,
>> + NBL_CHAN_MSG_ADD_ND_UPCALL_FLOW,
>> + NBL_CHAN_MSG_DEL_ND_UPCALL_FLOW,
>> + NBL_CHAN_MSG_GET_BOARD_ID,
>> + NBL_CHAN_MSG_SET_SHAPING_DPORT_VLD,
>> + NBL_CHAN_MSG_SET_DPORT_FC_TH_VLD,
>> + NBL_CHAN_MSG_REGISTER_RDMA_BOND,
>> + NBL_CHAN_MSG_UNREGISTER_RDMA_BOND,
>> + NBL_CHAN_MSG_RESTORE_NETDEV_QUEUE,
>> + NBL_CHAN_MSG_RESTART_NETDEV_QUEUE,
>> + NBL_CHAN_MSG_RESTORE_HW_QUEUE,
>> + NBL_CHAN_MSG_KEEP_ALIVE,
>> + NBL_CHAN_MSG_GET_BASE_MAC_ADDR,
>> + NBL_CHAN_MSG_CFG_BOND_SHAPING,
>> + NBL_CHAN_MSG_CFG_BGID_BACK_PRESSURE,
>> + NBL_CHAN_MSG_ALLOC_KT_BLOCK,
>> + NBL_CHAN_MSG_FREE_KT_BLOCK,
>> + NBL_CHAN_MSG_GET_USER_QUEUE_INFO,
>> + NBL_CHAN_MSG_GET_ETH_BOND_INFO,
>> + NBL_CHAN_MSG_CLEAR_ACCEL_FLOW,
>> + NBL_CHAN_MSG_SET_BRIDGE_MODE,
>> + NBL_CHAN_MSG_GET_VF_FUNCTION_ID,
>> + NBL_CHAN_MSG_NOTIFY_LINK_FORCED,
>> + NBL_CHAN_MSG_SET_PMD_DEBUG,
>> + NBL_CHAN_MSG_REGISTER_FUNC_MAC,
>> + NBL_CHAN_MSG_SET_TX_RATE,
>> + NBL_CHAN_MSG_REGISTER_FUNC_LINK_FORCED,
>> + NBL_CHAN_MSG_GET_LINK_FORCED,
>> + NBL_CHAN_MSG_REGISTER_FUNC_VLAN,
>> + NBL_CHAN_MSG_GET_FD_FLOW,
>> + NBL_CHAN_MSG_GET_FD_FLOW_CNT,
>> + NBL_CHAN_MSG_GET_FD_FLOW_ALL,
>> + NBL_CHAN_MSG_GET_FD_FLOW_MAX,
>> + NBL_CHAN_MSG_REPLACE_FD_FLOW,
>> + NBL_CHAN_MSG_REMOVE_FD_FLOW,
>> + NBL_CHAN_MSG_CFG_FD_FLOW_STATE,
>> + NBL_CHAN_MSG_REGISTER_FUNC_RATE,
>> + NBL_CHAN_MSG_NOTIFY_VLAN,
>> + NBL_CHAN_MSG_GET_XDP_QUEUE_INFO,
>> + NBL_CHAN_MSG_STOP_ABNORMAL_SW_QUEUE,
>> + NBL_CHAN_MSG_STOP_ABNORMAL_HW_QUEUE,
>> + NBL_CHAN_MSG_NOTIFY_RESET_EVENT,
>> + NBL_CHAN_MSG_ACK_RESET_EVENT,
>> + NBL_CHAN_MSG_GET_VF_VSI_ID,
>> + NBL_CHAN_MSG_CONFIGURE_QOS,
>> + NBL_CHAN_MSG_GET_PFC_BUFFER_SIZE,
>> + NBL_CHAN_MSG_SET_PFC_BUFFER_SIZE,
>> + NBL_CHAN_MSG_GET_VF_STATS,
>> + NBL_CHAN_MSG_REGISTER_FUNC_TRUST,
>> + NBL_CHAN_MSG_NOTIFY_TRUST,
>> + NBL_CHAN_MSG_CHECK_VF_IS_ACTIVE,
>> + NBL_CHAN_MSG_GET_ETH_ABNORMAL_STATS,
>> + NBL_CHAN_MSG_GET_ETH_CTRL_STATS,
>> + NBL_CHAN_MSG_GET_PAUSE_STATS,
>> + NBL_CHAN_MSG_GET_ETH_MAC_STATS,
>> + NBL_CHAN_MSG_GET_FEC_STATS,
>> + NBL_CHAN_MSG_CFG_MULTI_MCAST_RULE,
>> + NBL_CHAN_MSG_GET_LINK_DOWN_COUNT,
>> + NBL_CHAN_MSG_GET_LINK_STATUS_OPCODE,
>> + NBL_CHAN_MSG_GET_RMON_STATS,
>> + NBL_CHAN_MSG_REGISTER_PF_NAME,
>> + NBL_CHAN_MSG_GET_PF_NAME,
>> + NBL_CHAN_MSG_CONFIGURE_RDMA_BW,
>> + NBL_CHAN_MSG_SET_RATE_LIMIT,
>> + NBL_CHAN_MSG_SET_TC_WGT,
>> + NBL_CHAN_MSG_REMOVE_QUEUE,
>> + NBL_CHAN_MSG_GET_MIRROR_TABLE_ID,
>> + NBL_CHAN_MSG_CONFIGURE_MIRROR,
>> + NBL_CHAN_MSG_CONFIGURE_MIRROR_TABLE,
>> + NBL_CHAN_MSG_CLEAR_MIRROR_CFG,
>> + NBL_CHAN_MSG_MIRROR_OUTPUTPORT_NOTIFY,
>> + NBL_CHAN_MSG_CHECK_FLOWTABLE_SPEC,
>> + NBL_CHAN_MSG_CHECK_VF_IS_VDPA,
>> + NBL_CHAN_MSG_GET_VDPA_VF_STATS,
>> + NBL_CHAN_MSG_SET_RX_RATE,
>> + NBL_CHAN_MSG_GET_UVN_PKT_DROP_STATS,
>> + NBL_CHAN_MSG_GET_USTORE_PKT_DROP_STATS,
>> + NBL_CHAN_MSG_GET_USTORE_TOTAL_PKT_DROP_STATS,
>> + NBL_CHAN_MSG_SET_WOL,
>> + NBL_CHAN_MSG_INIT_VF_MSIX_MAP,
>> + NBL_CHAN_MSG_GET_ST_NAME,
>> + NBL_CHAN_MSG_MTU_SET = 501,
>> + NBL_CHAN_MSG_SET_RXFH_INDIR = 506,
>> + NBL_CHAN_MSG_SET_RXFH_RSS_ALG_SEL = 508,
>> + /* mailbox msg end */
>> + NBL_CHAN_MSG_MAILBOX_MAX,
>> +};
>> +
>This is a big enum. Is there a possibility to group them by functionality?
Thank you for your feedback.
As mentioned in the commit message, for compatibility,
the msg ID values are fixed and cannot be reordered or renumbered.
This constraintensures backward compatibility with existing
implementations that rely on these numeric values.
---illusion.wang
^ permalink raw reply
* Re: [PATCH net v2] bridge: cfm: reject invalid CCM interval at configuration time
From: Ido Schimmel @ 2026-04-07 7:07 UTC (permalink / raw)
To: Xiang Mei
Cc: netdev, horms, bridge, razor, davem, edumazet, pabeni, bestswngs
In-Reply-To: <20260405000324.548623-1-xmei5@asu.edu>
On Sat, Apr 04, 2026 at 05:03:24PM -0700, Xiang Mei wrote:
> ccm_tx_work_expired() re-arms itself via queue_delayed_work() using
> the configured exp_interval converted by interval_to_us(). When
> exp_interval is BR_CFM_CCM_INTERVAL_NONE or out of range,
> interval_to_us() returns 0, causing the worker to fire immediately in
> a tight loop that allocates skbs until OOM.
>
> Fix this by validating exp_interval at configuration time:
>
> - Constrain IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL to [1, 7] in the
> netlink policy so userspace cannot set an invalid value.
>
> - Reject starting CCM TX in br_cfm_cc_ccm_tx() when exp_interval has
> not yet been configured (defaults to 0 from kzalloc).
>
> Fixes: a806ad8ee2aa ("bridge: cfm: Kernel space implementation of CFM. CCM frame TX added.")
Nit: Doesn't matter in practice, but let's blame commit 2be665c3940d
("bridge: cfm: Netlink SET configuration Interface.") instead as I don't
think this bug could be triggered before exposing the netlink API.
> Reported-by: Weiming Shi <bestswngs@gmail.com>
> Signed-off-by: Xiang Mei <xmei5@asu.edu>
> ---
> v2: Move validation out of the datapath and into configuration
>
> net/bridge/br_cfm.c | 6 ++++++
> net/bridge/br_cfm_netlink.c | 2 +-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/net/bridge/br_cfm.c b/net/bridge/br_cfm.c
> index 118c7ea48c35..dea56fffa1c1 100644
> --- a/net/bridge/br_cfm.c
> +++ b/net/bridge/br_cfm.c
> @@ -805,6 +805,12 @@ int br_cfm_cc_ccm_tx(struct net_bridge *br, const u32 instance,
> goto save;
> }
>
> + if (!interval_to_us(mep->cc_config.exp_interval)) {
> + NL_SET_ERR_MSG_MOD(extack,
> + "Invalid CCM interval");
> + return -EINVAL;
> + }
> +
> /* Start delayed work to transmit CCM frames. It is done with zero delay
> * to send first frame immediately
> */
> diff --git a/net/bridge/br_cfm_netlink.c b/net/bridge/br_cfm_netlink.c
> index 2faab44652e7..1bb33c8f587b 100644
> --- a/net/bridge/br_cfm_netlink.c
> +++ b/net/bridge/br_cfm_netlink.c
> @@ -34,7 +34,7 @@ br_cfm_cc_config_policy[IFLA_BRIDGE_CFM_CC_CONFIG_MAX + 1] = {
> [IFLA_BRIDGE_CFM_CC_CONFIG_UNSPEC] = { .type = NLA_REJECT },
> [IFLA_BRIDGE_CFM_CC_CONFIG_INSTANCE] = { .type = NLA_U32 },
> [IFLA_BRIDGE_CFM_CC_CONFIG_ENABLE] = { .type = NLA_U32 },
> - [IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL] = { .type = NLA_U32 },
> + [IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL] = NLA_POLICY_RANGE(NLA_U32, 1, 7),
Use BR_CFM_CCM_INTERVAL_3_3_MS and BR_CFM_CCM_INTERVAL_10_MIN instead of
the magic numbers?
The Sashiko review points out that blocking BR_CFM_CCM_INTERVAL_NONE
might break user space, but it seems weird to allow passing a value that
is interpreted the same as an invalid one. Worst case, if someone
complains, we can revert and go back to v1.
> [IFLA_BRIDGE_CFM_CC_CONFIG_EXP_MAID] = {
> .type = NLA_BINARY, .len = CFM_MAID_LENGTH },
> };
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH net-next 01/15] igc: Call netif_queue_set_napi() with rtnl locked
From: Mika Westerberg @ 2026-04-07 6:53 UTC (permalink / raw)
To: Paolo Abeni
Cc: Bjorn Helgaas, Tony Nguyen, davem, kuba, edumazet, andrew+netdev,
netdev, andriy.shevchenko, ilpo.jarvinen, dima.ruinskiy, mbloch,
leon, linux-pci, saeedm, tariqt, lukas, bhelgaas, richardcochran,
Vinicius Costa Gomes, Jacob Keller, Avigail Dahan
In-Reply-To: <9f169800-12f2-4f98-ab99-e4433b2b49a9@redhat.com>
Hi,
On Thu, Apr 02, 2026 at 12:29:06PM +0200, Paolo Abeni wrote:
> On 3/31/26 7:37 PM, Bjorn Helgaas wrote:
> > On Mon, Mar 30, 2026 at 04:02:30PM -0700, Tony Nguyen wrote:
> >> From: Mika Westerberg <mika.westerberg@linux.intel.com>
> >>
> >> When runtime resuming igc we get:
> >>
> >> [ 516.161666] RTNL: assertion failed at ./include/net/netdev_lock.h (72)
> >>
> >> Happens because commit 310ae9eb2617 ("net: designate queue -> napi
> >> linking as "ops protected"") added check for this. For this reason drop
> >> the special case for runtime PM from __igc_resume(). This makes it take
> >> rtnl lock unconditionally.
> >
> > Taking the rtnl lock unconditionally certainly makes the code nicer,
> > but the commit log only mentions the "avoid the warning" benefit, not
> > the actual reason this is safe to do.
>
> Sashiko says it's not safe:
>
> ---
> Can this regression cause a self-deadlock when a runtime resume is
> triggered from paths that already hold the rtnl lock?
> If the network interface is logically up but the link is disconnected,
> igc_runtime_idle() allows the device to enter runtime suspend. When a
> user queries the device using ethtool, the networking core acquires
> rtnl_lock() and then calls pm_runtime_get_sync() to ensure the hardware
> is awake.
> This synchronously executes the driver's runtime resume callback, which
> calls __igc_resume(). Because netif_running(netdev) is true, the
> modified __igc_resume() unconditionally attempts to acquire rtnl_lock().
> Since the executing thread already holds this non-recursive mutex, it
> appears the system would self-deadlock, hanging the network stack.
> ---
It's a good analysis. I just tried this flow:
1. Boot the system up, nothing connected to igc NIC.
2. Plug in cable to igc.
3. Configure the interface.
4. Enable runtime PM for igc.
5. Unplug the cable.
6. Verify igc is runtime suspended.
7. Run ethtool <interface>
This leads to deadlock as below.
igc maintainers, please drop this patch. I apologize I did not realize this
flow when I did it.
[ 1231.655924] INFO: task ethtool:3139 blocked for more than 122 seconds.
[ 1231.662515] Tainted: G U 7.0.0-rc6+ #1748
[ 1231.668551] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1231.676410] task:ethtool state:D stack:0 pid:3139 tgid:3139 ppid:292 task_flags:0x480000 flags:0x00080800
[ 1231.687508] Call Trace:
[ 1231.689997] <TASK>
[ 1231.692132] __schedule+0x58a/0x1820
[ 1231.695747] ? sysvec_apic_timer_interrupt+0x4c/0xa0
[ 1231.700742] ? asm_sysvec_apic_timer_interrupt+0x1b/0x20
[ 1231.706090] schedule+0x64/0xe0
[ 1231.709262] schedule_preempt_disabled+0x15/0x30
[ 1231.713907] __mutex_lock+0x377/0xa60
[ 1231.717606] __mutex_lock_slowpath+0x13/0x20
[ 1231.721905] mutex_lock+0x2c/0x40
[ 1231.725259] rtnl_lock+0x15/0x20
[ 1231.728541] __igc_resume+0x19a/0x2b0 [igc]
[ 1231.732798] igc_runtime_resume+0xe/0x20 [igc]
[ 1231.737288] pci_pm_runtime_resume+0xce/0x100
[ 1231.741678] ? __pfx_pci_pm_runtime_resume+0x10/0x10
[ 1231.746681] __rpm_callback+0xab/0x310
[ 1231.750458] ? ktime_get_mono_fast_ns+0x3a/0x100
[ 1231.755107] ? __pfx_pci_pm_runtime_resume+0x10/0x10
[ 1231.760096] rpm_resume+0x4bb/0x670
[ 1231.763618] __pm_runtime_resume+0x5c/0x80
[ 1231.767749] dev_ethtool+0x19d/0xc90
[ 1231.771352] dev_ioctl+0x23c/0x550
[ 1231.774791] sock_do_ioctl+0x11f/0x1b0
[ 1231.778569] sock_ioctl+0x27f/0x390
[ 1231.782091] ? handle_mm_fault+0x11a5/0x1250
[ 1231.786388] __se_sys_ioctl+0x75/0xd0
[ 1231.790077] __x64_sys_ioctl+0x1d/0x30
[ 1231.793851] x64_sys_call+0x14ed/0x2d30
[ 1231.797719] do_syscall_64+0xfb/0x680
[ 1231.801404] ? arch_exit_to_user_mode_prepare+0xd/0xb0
[ 1231.806559] ? irqentry_exit+0x3b/0x510
[ 1231.810413] entry_SYSCALL_64_after_hwframe+0x76/0x7e
^ permalink raw reply
* Re: [PATCH net-next v3 5/5] selftests: net: bridge: add tests for MRC and QQIC validation
From: Ujjal Roy @ 2026-04-07 6:53 UTC (permalink / raw)
To: Jakub Kicinski
Cc: David S . Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Nikolay Aleksandrov, Ido Schimmel, David Ahern, Shuah Khan,
Andy Roulin, Yong Wang, Petr Machata, Ujjal Roy, bridge, netdev,
linux-kernel, linux-kselftest
In-Reply-To: <20260406182504.52a03794@kernel.org>
On Tue, Apr 7, 2026 at 6:55 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Fri, 3 Apr 2026 15:00:50 +0000 Ujjal Roy wrote:
> > --- a/tools/testing/selftests/net/forwarding/.gitignore
> > +++ b/tools/testing/selftests/net/forwarding/.gitignore
> > @@ -1,3 +1,5 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > forwarding.config
> > ipmr
> > +mc_encode
> > +mc_decode
>
> please keep this file sorted
I will keep all the codes under a single file and keep them sorted.
>
> > diff --git a/tools/testing/selftests/net/forwarding/Makefile b/tools/testing/selftests/net/forwarding/Makefile
> > index bbaf4d937dd8..a26da846632d 100644
> > --- a/tools/testing/selftests/net/forwarding/Makefile
> > +++ b/tools/testing/selftests/net/forwarding/Makefile
> > @@ -1,5 +1,15 @@
> > # SPDX-License-Identifier: GPL-2.0+ OR MIT
> >
> > +top_srcdir = ../../../../..
> > +
> > +CFLAGS += -Wall -Wl,--no-as-needed -O2 -g -I$(top_srcdir)/usr/include $(KHDR_INCLUDES)
> > +CFLAGS += -I$(top_srcdir)/tools/include
>
> Could you please keep the format more aligned with the ksft
> net/Makefile? Also is the -I$(top_srcdir)/tools/include
> still necessary? KHDR_INCLUDES don't include $src/usr/include ??
>
> > +TEST_GEN_FILES := \
> > + mc_encode \
> > + mc_decode \
> > +# end of TEST_GEN_FILES
>
> Also needs to be sorted
> --
> pw-bot: cr
I need bitops.h for fls() API, so I can see KHDR_INCLUDES is not
needed but tools/include is needed. I don't see lib.mk is including
the tools/include.
@Nikolay Aleksandrov Please review the updated test cases in this patch.
^ permalink raw reply
* [PATCH net v3] net: airoha: Add dma_rmb() and READ_ONCE() in airoha_qdma_rx_process()
From: Lorenzo Bianconi @ 2026-04-07 6:48 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: Xuegang Lu, Simon Horman, linux-arm-kernel, linux-mediatek,
netdev
Add missing dma_rmb() in airoha_qdma_rx_process routine to make sure the
DMA read operations are completed when the NIC reports the processing on
the current descriptor is done. Moreover, add missing READ_ONCE() in
airoha_qdma_rx_process() for DMA descriptor control fields in order to
avoid any compiler reordering.
Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
Changes in v3:
- Move page pointer initialization before checking error condition on
payload length in order avoid using page pointer uninitialized in the
airoha_qdma_rx_process() error path.
- Link to v2: https://lore.kernel.org/r/20260403-airoha_qdma_rx_process-fix-reordering-v2-1-181e6e23d27b@kernel.org
Changes in v2:
- Use msg1 in airoha_qdma_get_gdm_port() signature to avoid missing
READ_ONCE().
- Link to v1: https://lore.kernel.org/r/20260402-airoha_qdma_rx_process-fix-reordering-v1-1-53278474f062@kernel.org
---
drivers/net/ethernet/airoha/airoha_eth.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 91cb63a32d99..9285a68f435f 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -584,7 +584,7 @@ static int airoha_qdma_fill_rx_queue(struct airoha_queue *q)
static int airoha_qdma_get_gdm_port(struct airoha_eth *eth,
struct airoha_qdma_desc *desc)
{
- u32 port, sport, msg1 = le32_to_cpu(desc->msg1);
+ u32 port, sport, msg1 = le32_to_cpu(READ_ONCE(desc->msg1));
sport = FIELD_GET(QDMA_ETH_RXMSG_SPORT_MASK, msg1);
switch (sport) {
@@ -612,21 +612,24 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
while (done < budget) {
struct airoha_queue_entry *e = &q->entry[q->tail];
struct airoha_qdma_desc *desc = &q->desc[q->tail];
- 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);
+ u32 hash, reason, msg1, desc_ctrl;
struct airoha_gdm_port *port;
int data_len, len, p;
+ struct page *page;
+ desc_ctrl = le32_to_cpu(READ_ONCE(desc->ctrl));
if (!(desc_ctrl & QDMA_DESC_DONE_MASK))
break;
+ dma_rmb();
+
q->tail = (q->tail + 1) % q->ndesc;
q->queued--;
dma_sync_single_for_cpu(eth->dev, e->dma_addr,
SKB_WITH_OVERHEAD(q->buf_size), dir);
+ page = virt_to_head_page(e->buf);
len = FIELD_GET(QDMA_DESC_LEN_MASK, desc_ctrl);
data_len = q->skb ? q->buf_size
: SKB_WITH_OVERHEAD(q->buf_size);
@@ -670,8 +673,8 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
* DMA descriptor. Report DSA tag to the DSA stack
* via skb dst info.
*/
- u32 sptag = FIELD_GET(QDMA_ETH_RXMSG_SPTAG,
- le32_to_cpu(desc->msg0));
+ u32 msg0 = le32_to_cpu(READ_ONCE(desc->msg0));
+ u32 sptag = FIELD_GET(QDMA_ETH_RXMSG_SPTAG, msg0);
if (sptag < ARRAY_SIZE(port->dsa_meta) &&
port->dsa_meta[sptag])
@@ -679,6 +682,7 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
&port->dsa_meta[sptag]->dst);
}
+ msg1 = le32_to_cpu(READ_ONCE(desc->msg1));
hash = FIELD_GET(AIROHA_RXD4_FOE_ENTRY, msg1);
if (hash != AIROHA_RXD4_FOE_ENTRY)
skb_set_hash(q->skb, jhash_1word(hash, 0),
---
base-commit: a9d4f4f6e65e0bf9bbddedecc84d67249991979c
change-id: 20260402-airoha_qdma_rx_process-fix-reordering-722308255b65
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* 回复：[PATCH v10 net-next 02/11] net/nebula-matrix: add our driver architecture
From: Illusion Wang @ 2026-04-07 6:40 UTC (permalink / raw)
To: Mohsin Bashir, Dimon, Alvin, Sam, netdev
Cc: andrew+netdev, corbet, kuba, linux-doc, lorenzo, pabeni, horms,
vadim.fedorenko, lukas.bulwahn, edumazet, enelsonmoore, skhan,
hkallweit1, jani.nikula, open list
In-Reply-To: <bf9f7c6f-8759-4f4f-8e35-2bd7c446d102@gmail.com>
>> +
>> + chan_mgt = devm_kzalloc(dev, sizeof(*chan_mgt), GFP_KERNEL);
>> + if (!chan_mgt)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + chan_mgt->common = common;
>> + chan_mgt->hw_ops_tbl = hw_ops_tbl;
>> +
>> + mailbox = devm_kzalloc(dev, sizeof(*mailbox), GFP_KERNEL);
>> + if (!mailbox)
>> + return ERR_PTR(-ENOMEM);
>Here, if mailbox allocation fails, we return without freeing chan_mgt
>resulting in a leak.
>> + mailbox->chan_type = NBL_CHAN_TYPE_MAILBOX;
>> + chan_mgt->chan_info[NBL_CHAN_TYPE_MAILBOX] = mailbox;
>> +
>> + return chan_mgt;
>> +}
Thanks for your feedback.
I've carefully considered your comment about the potential
memory leak in the provided code snippet,
but I use devm_kzalloc(), the area is guaranteed to be
freed whether initialization fails half-way or the device
gets detached.
ps:Documentation\driver-api\driver-model\devres.tst
my_init_one()
{
struct mydev *d;
d = devm_kzalloc(dev, sizeof(*d), GFP_KERNEL);
if (!d)
return -ENOMEM;
d->ring = dmam_alloc_coherent(...);
if (!d->ring)
return -ENOMEM;
if (check something)
return -EINVAL;
...
}
--illusion.wang
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] net: rnpgbe: Add TX/RX and link status support
From: Yibo Dong @ 2026-04-07 6:37 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew+netdev, davem, edumazet, pabeni, danishanwar,
vadim.fedorenko, horms, linux-kernel, netdev
In-Reply-To: <20260403081249.50e25acd@kernel.org>
On Fri, Apr 03, 2026 at 08:12:49AM -0700, Jakub Kicinski wrote:
> On Fri, 3 Apr 2026 10:57:09 +0800 Dong Yibo wrote:
> > This patch series adds the packet transmission, reception, and link status
> > management features to the RNPGBE driver, building upon the previously
> > introduced mailbox communication and basic driver infrastructure.
>
> drivers/net/ethernet/mucse/rnpgbe/rnpgbe.h:183:19-23: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays)
>
> nit: checkpatch complains about a few lines over 80 chars too
> --
> pw-bot: cr
>
Be fixed in next version.
Thanks for you feedback.
^ permalink raw reply
* RE: [PATCH net] net: txgbe: fix RTNL assertion warning when remove module
From: Jiawen Wu @ 2026-04-07 6:27 UTC (permalink / raw)
To: 'Russell King (Oracle)'
Cc: netdev, 'Mengyuan Lou', 'Andrew Lunn',
'David S. Miller', 'Eric Dumazet',
'Jakub Kicinski', 'Paolo Abeni',
'Simon Horman', 'Jacob Keller',
'Abdun Nihaal', stable
In-Reply-To: <acy5evlrUesbcB46@shell.armlinux.org.uk>
On Wed, Apr 1, 2026 2:22 PM, Russell King (Oracle) wrote:
> On Wed, Apr 01, 2026 at 10:16:34AM +0800, Jiawen Wu wrote:
> > On Tue, Mar 31, 2026 9:08 PM, Russell King (Oracle) wrote:
> > > On Tue, Mar 31, 2026 at 03:11:07PM +0800, Jiawen Wu wrote:
> > > > For the copper NIC with external PHY, the driver called
> > > > phylink_connect_phy() during probe and phylink_disconnect_phy() during
> > > > remove. It caused an RTNL assertion warning in phylink_disconnect_phy()
> > > > upon module remove.
> > > >
> > > > To fix this, move the phylink connect/disconnect PHY to ndo_open/close.
> > >
> > > Wouldn't it be simpler to just wrap the phylink_disconnect_phy() in the
> > > remove function with rtnl_lock()..rtnl_unlock() ?
> >
> > This is also a solution. But I think it would be nice to unify with other drivers
> > that call the functions in ndo_open/close.
>
> Both approaches are equally valid. Some network drivers attach the PHY
> at probe time (and thus can return -EPROBE_DEFER if the PHY is specified
> but not present). Others attach in .ndo_open which can only fail in this
> circumstance with no retry without userspace manually implementing that.
>
> There are other advantages and disadvantages to each approach.
Hi,
So is it still recommended that add rtnl_lock()...rtnl_unlock() instead of moving it?
^ permalink raw reply
* Re: [net-next,v17,08/14] net: homa: create homa_rpc.h and homa_rpc.c
From: Paolo Abeni @ 2026-04-07 6:07 UTC (permalink / raw)
To: John Ousterhout; +Cc: horms, netdev, kuba, edumazet
In-Reply-To: <CAGXJAmx6YsBYQCagvHs1DPTd-b-yHYVTN67-JCApQdG+x6-cjg@mail.gmail.com>
On 4/4/26 1:04 AM, John Ousterhout wrote:
> On Tue, Mar 24, 2026 at 1:55 AM Paolo Abeni <pabeni@redhat.com> wrote:
>>
>>>> [ ... ]
>>>> Paolo also suggested using deferred SKB freeing (skb_attempt_defer_free) to
>>>> reduce the cost. While you mentioned that GRO is implemented in the full
>>>> Homa but was left out of the initial patch series, would it be beneficial to
>>>> include at least some of these optimizations in this initial submission?
>>>>
>>>> Reference: https://lore.kernel.org/netdev/9209dfbb-ca3a-4fb7-a2fb-0567394f8cda@redhat.com/
>>>
>>> When I asked ChatGPT about homa_attempt_defer_free it said that it
>>> only works if the skb has no dst, no destructor, and no skb_nfct. I'm
>>> a bit unsure how to proceed. Is homa_attempt_defer_free only intended
>>> for incoming packets? If so, then presumably there is no dst? But what
>>> about the other fields? Do I need to do something to clean them up
>>> before calling homa_attempt_defer_free?
>> skb_attempt_defer_free() usage is intended for the RX path only.
>>
>> Incoming packets get state (dst, extensions, ct...) attached in the rx
>> path before reaching the socket. You should free/release the state, if
>> possible, before inserting the skb into the receive queue, so that you
>> could defer free them after read.
>
> I have modified Homa to use skb_attempt_defer_free, and this made a
> significant difference in the throughput of the critical path copying
> data from skbs to user space. Thanks for the suggestion.
>
> However, skb_attempt_defer_free is not currently exported, so the
> patch series will now include an EXPORT_SYMBOL line for that in
> skbuff.c; hopefully that will be OK...
Yes, it is as long as such export is bundled with the module user - i.e.
this series.
Cheers,
Paolo
^ permalink raw reply
* [RFC bpf] Ingress RX queue provenance across cpumap redirect
From: Adith-Joshua @ 2026-04-07 6:02 UTC (permalink / raw)
To: bpf; +Cc: netdev, ast, daniel, andrii, kuba, hawk, john.fastabend
Hi,
While working with XDP programs using cpumap redirection, I observed that
ctx->rx_queue_index becomes 0 after xdp_buff -> xdp_frame conversion and
execution on the remote CPU.
This is expected since xdp_frame does not carry xdp_rxq_info and cpumap
re-invokes XDP in a new execution context.
---
## Motivation
Some XDP deployments use cpumap as part of a multi-stage packet processing
pipeline, where XDP is effectively used as a distributed processing model
across CPUs rather than a single RX invocation.
In such setups, ingress RX queue identity (rx_queue_index) is sometimes
used beyond the initial hook not only for debugging, but for maintaining
consistent observability and pipeline semantics across stages. This includes:
- maintaining consistent per-RX-queue accounting across cpumap and later
XDP stages
- preserving RSS-based classification identity for traffic analysis and
validation of NIC steering behavior across a distributed pipeline
- enabling end-to-end telemetry correlation from hardware queue origin
through CPU-side processing
- supporting reproducibility of packet processing paths in asynchronous
cpumap-driven execution where scheduling and CPU assignment may vary
In these cases, rx_queue_index acts as a stable ingress classification anchor.
Losing this information at the cpumap boundary breaks the assumption that
XDP programs operate on a logically continuous packet context across stages.
---
## Design observation
Current behavior appears intentional:
- xdp_frame does not carry xdp_rxq_info
- cpumap executes XDP in a new RX context
- RX metadata is not considered part of redirected packet state
This suggests that RX provenance is currently scoped strictly to the NIC RX
invocation context, and is not carried across execution boundaries such as
cpumap or devmap.
---
## Question
Is RX queue provenance expected to be part of the XDP execution model across
redirect boundaries, or is it explicitly considered out of scope once a packet
is passed through cpumap/devmap?
---
## Alternative direction (for clarification only)
One possible model could be to treat ingress RX metadata as optional,
non-authoritative context and expose it via a helper-based mechanism
(e.g. ingress queue accessor), rather than embedding it in xdp_frame or
xdp_rxq_info.
However, I am not assuming this is aligned with existing design principles,
and would appreciate clarification on whether such a model is desirable at all.
To be explicit, I am not proposing that rx_queue_index itself be preserved
in xdp_frame or across cpumap, nor any change to existing struct layouts.
The question is whether ingress RX queue identity is intended to be
representable beyond the initial NIC RX invocation, particularly in
redirect-based XDP pipelines.
This question is motivated by cases where cpumap is used as part of a
multi-stage XDP processing pipeline, where loss of ingress queue identity
removes a stable classification signal that can otherwise be useful for:
- correlating packets across distributed XDP execution stages
- validating RSS / hardware steering behavior in software datapaths
- maintaining consistent per-queue observability across cpumap boundaries
- reconstructing ingress-to-processing paths in asynchronous CPU offload
The intent is to understand whether these requirements are intentionally
out of scope in the current XDP execution model, or whether a helper-based
or metadata-based abstraction is expected for such use cases.
---
## Follow-up
If this aligns with intended design, I would be happy to explore a concrete
proposal or implementation.
Thanks,
Adith
^ 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