Re: [PATCH net-next] net: inline eth_type_trans() fast path

[Stanislav Fomichev <sdf.kernel@gmail.com>]

On 10/01, Eric Dumazet wrote:
> On Thu, Oct 1, 2026 at 5:58 PM Alexander Lobakin
> <aleksander.lobakin@intel.com> wrote:
> >
> > From: Edumazet@kernel.org <edumazet@kernel.org>
> > Date: Wed, 30 Sep 2026 19:29:57 +0200
> >
> > > eth_type_trans() is called once per received packet by most
> > > Ethernet drivers, and by core helpers (napi_gro_frags(),
> > > xdp_build_skb_from_*(), veth, tun, tunnels, loopback...).
> > >
> > > With CONFIG_MITIGATION_RETHUNK / SRSO, the call and return
> > > are not free anymore.
> > >
> > > Add eth_type_trans_inline(), handling the common case inline:
> > > unicast frame sent to dev->dev_addr, with a real ethertype,
> > > on a device which is not a DSA conduit. All other frames
> > > (multicast, broadcast, otherhost, 802.2, runts, DSA)
> > > are handled by the out-of-line eth_type_trans().
> > >
> > > eth_type_trans() is now a macro calling eth_type_trans_inline(),
> > > so that all existing callers get the fast path. The out-of-line
> > > version remains exported, and can be called with
> > > (eth_type_trans)(skb, dev). bpf_prog_test_run_skb() uses this
> >
> > Shouldn't it get renamed to e.g. eth_type_trans_slow() to avoid this
> > confusion?
> 
> This was my initial idea, but this would make the patch a bit more
> invasive and touch bpf selftests, something like:
> 
> Let me know if I should send a V2 and CC bpf maintainers, thanks!

I prefer this _slow version as well, less magic.