Re: [PATCH] dpaa2-ethsw: move the DPAA2 Ethernet Switch driver out of staging

[Andrew Lunn]

> In the DPAA2 architecture MACs are not the only entities that can be 
> connected to a switch port.
> Below is an exemple of a 4 port DPAA2 switch which is configured to 
> interconnect 2 DPNIs (network interfaces) and 2 DPMACs.
> 
> 
>   [ethA]     [ethB]     [ethC]     [ethD]     [ethE]     [ethF]
>      :          :          :          :          :          :
>      :          :          :          :          :          :
> [eth drv]  [eth drv]  [                ethsw drv              ]
>      :          :          :          :          :          :        kernel
> ========================================================================
>      :          :          :          :          :          : 
> hardware
>   [DPNI]      [DPNI]     [============= DPSW =================]
>      |          |          |          |          |          |
>      |           ----------           |       [DPMAC]    [DPMAC]
>       -------------------------------            |          |
>                                                  |          |
>                                                [PHY]      [PHY]
> 
> You can see it as a hardware-accelerated software bridge where
> forwarding rules are managed from the host software partition.

Hi Ioana

What are the use cases for this?

Configuration is rather unintuitive. To bridge etha and ethb you need
to

ip link add name br0 type bridge
ip link set ethc master br0
ip link set ethd master br0

And once you make ethc and ethd actually send/receive frames, etha and
ethc become equivalent.

If this was a PCI device, i could imagine passing etha into a VM as a
PCI VF. But i don't think it is PCI?

I'm not sure moving etha into a different name space makes much sense
either. My guess would be, a veth pair with one end connected to the
software bridge would be more efficient than DMAing the packet out and
then back in again.

     Thanks
	Andrew