Re: [RFC PATCH 4/4] net: dsa: tag_edsa: support reception of packets from lag devices

[Ido Schimmel <idosch@idosch.org>]

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.