Re: [PATCH net-next,RFC 00/13] New fast forwarding path
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: 2018-06-15 06:27:37
Also in:
netfilter-devel
On Thu, Jun 14, 2018 at 01:52:03PM -0700, Tom Herbert wrote:
On Thu, Jun 14, 2018 at 7:19 AM, Pablo Neira Ayuso [off-list ref] wrote:quoted
Hi, This patchset proposes a new fast forwarding path infrastructure that combines the GRO/GSO and the flowtable infrastructures. The idea is to add a hook at the GRO layer that is invoked before the standard GRO protocol offloads. This allows us to build custom packet chains that we can quickly pass in one go to the neighbour layer to define fast forwarding path for flows. For each packet that gets into the GRO layer, we first check if there is an entry in the flowtable, if so, the packet is placed in a list until the GRO infrastructure decides to send the batch from gro_complete to the neighbour layer. The first packet in the list takes the route from the flowtable entry, so we avoid reiterative routing lookups. In case no entry is found in the flowtable, the packet is passed up to the classic GRO offload handlers. Thus, this packet follows the standard forwarding path. Note that the initial packets of the flow always go through the standard IPv4/IPv6 netfilter forward hook, that is used to configure what flows are placed in the flowtable. Therefore, only a few (initial) packets follow the standard forwarding path while most of the follow up packets take this new fast forwarding path.IIRC, there was a similar proposal a while back that want to bundle packets of the same flow together (without doing GRO) so that they could be processed by various functions by looking at just one representative packet in the group. The concept had some promise, but in the end it created quite a bit of complexity since at some point the packet bundle needed to be undone to go back to processing the individual packets.
With the way we chain the packets it is not too complicated to undo this chaining (nft_skb_segment in patch 5 implements this). After that, this looks like a chain of usual segments, so we trigger xmit_more with every packet chain.