On Wed, Oct 28, 2020 at 08:18:24PM +0200, Vladimir Oltean wrote: > Yes, I expect that the bridge input would need to have one more entry > path into it than just br_handle_frame. > > I'm a bit confused and undecided right now, so let's look at it from a > different perspective. Let's imagine a switchdev driver (DSA or not) > which is able to offload IP forwarding. There are some interfaces that > are bridged and one that is standalone. The setup looks as below. > > IP interfaces > +---------------------------------------------------------+ > | br0 | > +---------------------------------------------------------+ > > +------------+ +------------+ +------------+ +------------+ +------------+ > | swp0 | | swp1 | | swp2 | | swp3 | | eth0 | > +------------+ +------------+ +------------+ +------------+ +------------+ > > Hardware interfaces > > +------------+ +------------+ +------------+ +------------+ +------------+ > | DSA port 0 | | DSA port 1 | | DSA port 2 | | DSA port 3 | | e1000 | > +------------+ +------------+ +------------+ +------------+ +------------+ > > Let's say you receive a packet on the standalone swp0, and you need to > perform IP routing towards the bridged domain br0. Some switchdev/DSA > ports are bridged and some aren't. > > The switchdev/DSA switch will attempt to do the IP routing step first, > and it _can_ do that because it is aware of the br0 interface, so it > will decrement the TTL and replace the L2 header. > > At this stage we have a modified IP packet, which corresponds with what > should be injected into the hardware's view of the br0 interface. The > packet is still in the switchdev/DSA hardware data path. > > But then, the switchdev/DSA hardware will look up the FDB in the name of > br0, in an attempt of finding the destination port for the packet. But > the packet should be delivered to a station connected to eth0 (e1000, > foreign interface). So that's part of the exception path, the packet > should be delivered to the CPU. > > But the packet was already modified by the hardware data path (IP > forwarding has already taken place)! So how should the DSA/switchdev > hardware deliver the packet to the CPU? It has 2 options: > > (a) unwind the entire packet modification, cancel the IP forwarding and > deliver the unmodified packet to the CPU on behalf of swp0, the > ingress port. Then let software IP forwarding plus software bridging > deal with it, so that it can reach the e1000.
This is what happens in the Spectrum ASICs. If a packet hits some exception in the data path, it is trapped from the Rx port unmodified. > (b) deliver the packet to the CPU in the middle of the hardware > forwarding data path, where the exception/miss occurred, aka deliver > it on behalf of br0. Modified by IP forwarding. This is where we'd > have to manually inject skb->dev into br0 somehow.
