Hi, On Fri, Nov 20, 2020 at 03:09:37PM +0000, Alexander Lobakin wrote: > From: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> > Date: Fri, 20 Nov 2020 13:49:12 +0100 [...] > > The following patchset augments the Netfilter flowtable fastpath to > > support for network topologies that combine IP forwarding, bridge and > > VLAN devices. > > I'm curious if this new infra can be expanded later to shortcut other > VLAN-like virtual netdevs e.g. DSA-like switch slaves. > > I mean, usually we have port0...portX physical port representors > and backing CPU port with ethX representor. When in comes to NAT, > portX is set as destination. Flow offload calls dev_queue_xmit() > on it, switch stack pushes CPU tag into the skb, change skb->dev > to ethX and calls another dev_queue_xmit(). > > If we could (using the new .ndo_fill_forward_path()) tell Netfilter > that our real dest is ethX and push the CPU tag via dev_hard_header(), > this will omit one more dev_queue_xmit() and a bunch of indirect calls > and checks. If the XMIT_DIRECT path can be used for this with minimal changes, that would be good. > This might require some sort of "custom" or "private" cookies for > N-Tuple though to separate flows from/to different switch ports (as > it's done for VLAN: proto + VID). Probably VLAN proto + VID in the tuple can be reused for this too. Maybe add some extra information to tell if this is a VLAN or DSA frame. It should be just one extra check for skb->protocol equals DSA. Looks like very minimal changes to support for this. > If so, I'd like to try to implement and publish that idea for reviews > after this one lands nf-next. Exploring new extensions is fine. I received another email from someone else that would like to extend this to support for PPPoE devices with PcEngines APU routers. In general, adding more .ndo_fill_forward_path for more device types is possible.
