Re: [PATCH net-next,RFC 0/8] netfilter: flowtable bulking

[Steffen Klassert <steffen.klassert@secunet.com>]

On Thu, Mar 19, 2026 at 01:18:19PM +0100, Felix Fietkau wrote:
> On 19.03.26 12:28, Steffen Klassert wrote:
> > On Thu, Mar 19, 2026 at 02:15:17PM +0800, Qingfang Deng wrote:
> > > Hi Pablo,
> > > 
> > > On Tue, 17 Mar 2026 12:29:09 +0100, Pablo Neira Ayuso wrote:
> > > > Hi,
> > > >  > Back in 2018 [1], a new fast forwarding combining the flowtable
> > > and
> > > > GRO/GSO was proposed, however, "GRO is specialized to optimize the
> > > > non-forwarding case", so it was considered "counter-intuitive to base a
> > > > fast forwarding path on top of it".
> > > >  > Then, Steffen Klassert proposed the idea of adding a new engine
> > > for the
> > > > flowtable that operates on the skb list that is provided after the NAPI
> > > > cycle. The idea is to process this skb list to create bulks grouped by
> > > > the ethertype, output device, next hop and tos/dscp. Then, add a
> > > > specialized xmit path that can deal with these skb bulks. Note that GRO
> > > > needs to be disabled so this new forwarding engine obtains the list of
> > > > skbs that resulted from the NAPI cycle.
> > > 
> > > +Cc: Felix Fietkau
> > > 
> > > How does this compare to fraglist GRO with the original flowtable?
> > 
> > GRO can only aggregate packets of the same L4 flow. This can
> > aggregate all packets the are treated  the same by the
> > forwarding path. Packets need to have the same output device
> > and next hop, but can be from different L3 and L4 flows.
> > 
> > Packet forwarders usually receive many different flows.
> > GRO might not even kick in if there are not at least
> > two packets from the same flow on a napi cycle.
> 
> Interesting approach! Do you think it might be possible to combine this with
> GRO by bulking together GRO-combined frames from different flows?

This depends on how the GRO packets are crafted. If the packets built
just by adding skb page frags, then yes. If the fraglist pointer is
used to chain packets, then no (our approach uses the fraglist pointer
as well). So combining these would require some changes to the GRO
layer.

> I think it would be unfortunate if you have to choose between decent
> forwarding throughput and decent local rx throughput.

Would be nice if we could tune for both cases, but sometimes it
needs a decision for which use case it should be tuned.