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

[Ioana Ciornei]

On 8/12/19 4:57 PM, Andrew Lunn wrote:
>> 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

Hi Andrew,

> 
> 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?

Indeed it's not PCI but we can pass etha to a VM. That's the main use 
case of having DPNIs connected to a switch object.

Our direct assignment solution for DPAA2 is not upstream yet (the case 
with many of our drivers :) ) but the main idea is exposing to the VM a 
fsl-mc bus on which it can find any DPAA2 objects needed to configure a 
network interface (using firmware calls).


> 
> 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
>


That's really an interesting test to be made since we can make a veth 
pair from DPAA2 objects just connecting two DPNIs back to back. I'll 
make some performance tests and compare against the software veth.


Thanks,
Ioana