Re: [PATCH nf-next 2/5] netfilter: flowtable: consolidate xmit path

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Sun, Oct 12, 2025 at 02:26:20PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > Use dev_queue_xmit() for the XMIT_NEIGH case. Store the interface index
> > of the real device behind the vlan/pppoe device, this introduces  an
> > extra lookup for the real device in the xmit path because rt->dst.dev
> > provides the vlan/pppoe device.
> 
> Will this scale?  netdev_by_index only has a fixed table of 256 slots,
> so with 8k vlans or so this will have a 30-ish netdev list walk.
> 
> [ EDIT: I see now that nf_flow_queue_xmit() already does that.
>   So I guess its either not an issue or not yet and it can be
>   optimized later.  So disregard this ]

Yes, that will need a look closer or later.

> >  	case FLOW_OFFLOAD_XMIT_NEIGH:
> >  		rt = dst_rtable(tuplehash->tuple.dst_cache);
> > -		outdev = rt->dst.dev;
> > -		skb->dev = outdev;
> > -		nexthop = rt_nexthop(rt, flow->tuplehash[!dir].tuple.src_v4.s_addr);
> > +		xmit.outdev = dev_get_by_index_rcu(state->net, tuplehash->tuple.ifidx);
> 
> Why do this if we already have dst_cache?

This is to skip one level of indirection, ie. dst_cache points to the
vlan device, not the real device. The idea is that the flowtable gains
control on the xmit path so the flowtable pushes l2/l3 headers and
send the packets directly to the "real" netdevice.

> The above explanation (rt->dst.dev could be a tunnel device, whereas
> the latter fetches phyical / lowest device) from the commit message
> makes that clear; but I think a short comment would help.

Yes, I can add a comment on this.

Thanks.