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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 13 Aug 2019 07:21:41 +0000
From:   Ioana Ciornei <ioana.ciornei@....com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        Ioana Ciocoi Radulescu <ruxandra.radulescu@....com>
Subject: Re: [PATCH] dpaa2-ethsw: move the DPAA2 Ethernet Switch driver out of
 staging

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