From: "Cen Zhang (Microsoft)" <blbllhy@gmail.com>
To: ap420073@gmail.com
Cc: AutonomousCodeSecurity@microsoft.com, andrew+netdev@lunn.ch,
blbllhy@gmail.com, davem@davemloft.net, edumazet@google.com,
horms@kernel.org, kuba@kernel.org, kys@microsoft.com,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
pabeni@redhat.com, tgopinath@linux.microsoft.com, xmei5@asu.edu
Subject: Re: [PATCH net] amt: do not store tunnel pointer in skb control block
Date: Wed, 26 Aug 2026 00:15:29 -0400 [thread overview]
Message-ID: <20260826041529.46139-1-blbllhy@gmail.com> (raw)
In-Reply-To: <CAMArcTUmACRn_h2sthPwsi3jYjKWRM6+Pnhg=tN4jn4VZThHCA@mail.gmail.com>
Thanks for the feedback. Just getting back to this thread.
On Thu, Aug 20, 2026 at 10:18:43PM +0900, Taehee Yoo wrote:
> This looks like it adds a per-packet linear scan over all tunnels,
> so I'm concerned about performance when there are many tunnels.
> Do you have any idea how to avoid this regression?
I see two possible approaches:
1. Keep the v1 implementation. It is the simplest fix, but changes the
Query dequeue path from an O(1) pointer access to an O(n) lookup. I am
not sure whether that cost is significant in practice for two reasons:
this handles IGMP/MLD Query control packets rather than multicast data
packets [1], while the hotter multicast data path already walks
tunnel_list for each skb [2]; and max_tunnels defaults to 128. However,
max_tunnels is configurable, so users can set it much higher.
2. Add a small per-device bucket hash keyed by (ip4, source_port) to [1],
while keeping tunnel_list for multicast fan-out in [2]. This avoids
a new linear lookup cost, but adds a second index that must be
maintained during tunnel creation, expiry, and device teardown.
I am not sure whether that is overkill for this fix.
I would appreciate your further feedback here and will prepare v2 after
settling on the approach.
> I think this comment is not necessary. Please remove it.
Agreed. I will remove it in v2.
[1] https://github.com/torvalds/linux/blob/0f23d56f17fdfc7db69d51f64c8b91bbab947aa9/drivers/net/amt.c#L1261
[2] https://github.com/torvalds/linux/blob/0f23d56f17fdfc7db69d51f64c8b91bbab947aa9/drivers/net/amt.c#L1276
next prev parent reply other threads:[~2026-08-26 4:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-18 16:48 [PATCH net] amt: do not store tunnel pointer in skb control block Cen Zhang (Microsoft)
2026-08-20 13:18 ` Taehee Yoo
2026-08-26 4:15 ` Cen Zhang (Microsoft) [this message]
2026-08-26 12:56 ` Taehee Yoo
2026-09-22 21:19 ` Cen Zhang (Microsoft Security FORGE Labs)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260826041529.46139-1-blbllhy@gmail.com \
--to=blbllhy@gmail.com \
--cc=AutonomousCodeSecurity@microsoft.com \
--cc=andrew+netdev@lunn.ch \
--cc=ap420073@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=tgopinath@linux.microsoft.com \
--cc=xmei5@asu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.