Re: [OpenWrt-Devel] [PATCH v3 0/6] staging: Introduce DPAA2 Ethernet Switch driver

[Florian Fainelli]

On October 14, 2017 2:59:22 PM PDT, Linus Walleij  
wrote:
>On Sat, Oct 14, 2017 at 8:52 PM, Florian Fainelli
> wrote:
>
>> The most deployed switch device drivers have been converted to DSA
>> already: b53, qca8k (ar83xx in OpenWrt/LEDE) and mtk7530 are all in
>> tree, and now we are getting new submissions from Michrochip to
>support
>> their pretty large KSZ series. Converting from swconfig to DSA is
>> actually quite simple, but like anything requires time and testing,
>and
>> access to hardware and ideally datasheet.
>
>Hm, I have a Realtek RB8366RB in this router on my desk.
>
>I guess that means I should just take the old switchdev-based
>SMI-driver and convert it to DSA.
>
>I bet I can do that :D

Yes, it really should not be too hard. The OpenWrt/LEDE driver had mostly the 
same semantics as what is needed for being a proper DSA driver. You should of 
course start simple: get basic switching working, then add statistics, VLAN, 
FDB, etc. OpenWrt/LEDE models switches as PHY device objects which would not 
work upstream so you should have the driver be probed as a MDIO/SPI/I2C (see 
b53 for example) and set up fixed-link properties between the CPU and the 
switch.

>
>Well, I will try. Because it's blocking me to work on the Gemini
>ethernet driver.

Well usually the boot loader may leave the switch in a good enough state that 
you can work on the CPU controller mostly independently from dealing with the 
switch. This is not universally true, and a properly working bootloader should 
actually quiesce/reset both blocks prior to OS control.

Don't hesitate if you have questions.

Cheers.

-- 
Florian

Re: [OpenWrt-Devel] [PATCH v3 0/6] staging: Introduce DPAA2 Ethernet Switch driver

[Linus Walleij]

On Sat, Oct 14, 2017 at 8:52 PM, Florian Fainelli  wrote:

> The most deployed switch device drivers have been converted to DSA
> already: b53, qca8k (ar83xx in OpenWrt/LEDE) and mtk7530 are all in
> tree, and now we are getting new submissions from Michrochip to support
> their pretty large KSZ series. Converting from swconfig to DSA is
> actually quite simple, but like anything requires time and testing, and
> access to hardware and ideally datasheet.

Hm, I have a Realtek RB8366RB in this router on my desk.

I guess that means I should just take the old switchdev-based
SMI-driver and convert it to DSA.

I bet I can do that :D

Well, I will try. Because it's blocking me to work on the Gemini
ethernet driver.

Yours,
Linus Walleij

Re: [OpenWrt-Devel] [PATCH v3 0/6] staging: Introduce DPAA2 Ethernet Switch driver

[Florian Fainelli]

Hi,

On 10/14/2017 04:09 AM, Linus Walleij wrote:
> Top posting and resending since netdev@vger.kernel.org
> is the right mail address for this. Mea culpa.
> 
> Linus Walleij
> 
> On Sat, Oct 14, 2017 at 11:35 AM, Linus Walleij
>  wrote:
>> On Thu, Oct 5, 2017 at 11:16 AM, Razvan Stefanescu
>>  wrote:
>>
>>> This patchset introduces the Ethernet Switch Driver for Freescale/NXP SoCs
>>> with DPAA2 (DataPath Acceleration Architecture v2). The driver manages
>>> switch objects discovered on the fsl-mc bus. A description of the driver
>>> can be found in the associated README file.
>>>
>>> The patchset consists of:
>>> * A set of libraries containing APIs for configuring and controlling
>>>   Management Complex (MC) switch objects
>>> * The DPAA2 Ethernet Switch driver
>>> * Patch adding ethtool support
>>
>> So it appears that ethernet switches is a class of device that need their own
>> subsystem in Linux, before this driver can move out of staging.

FWIW, I think the biggest dependency on this driver is not a switch
driver model because that exists but it's actually the specific bus (MC
AFAICT) that it depends on. More on the Ethernet switch device model below.

We do actually have a pretty good model for Ethernet switches now, in
fact, we got several options:

- Distributed Switching Architecture (DSA) should be used when the
CPU/management Ethernet controller is a traditional Ethernet MAC that is
either internally or externally attached to a switch. This usually comes
with the Ethernet switch capable of providing per-packet metadata (tag)
to indicate to the management interface why the packet is transmitted.
For older/dumber switches, using no management tag, but separating with
802.1Q tags is definitively an option that brings in the same
requirements for DSA. DSA does make use of switchdev to get notified
from the networking stack when there is an opportunity to offload
objects: VLAN, FDB, MDB, etc. DSA is both a device driver model and a
switch device abstraction model.

- switchdev should be used when the management interface is tightly
coupled with the switching hardware, such that, per-packet information
is obtained via DMA/PIO descriptors for instance. switchdev is not a
device driver model so the switch driver is responsible for creating its
own net_device instances and feeding the appropriate netdev_ops,
ethtool_ops and switchdev_ops, this is what is being done here, and this
is also perfectly fine.

>>
>> I ran into the problem in OpenWRT that has these out-of-tree patches for
>> off-chip ethernet switches, conveniently placed under net/phy:
>> https://github.com/openwrt/openwrt/tree/master/target/linux/generic/files/drivers/net/phy
>>
>> These are some 12 different ethernet switches. It is used in more or
>> less every home router out there.

The most deployed switch device drivers have been converted to DSA
already: b53, qca8k (ar83xx in OpenWrt/LEDE) and mtk7530 are all in
tree, and now we are getting new submissions from Michrochip to support
their pretty large KSZ series. Converting from swconfig to DSA is
actually quite simple, but like anything requires time and testing, and
access to hardware and ideally datasheet.

>>
>> It's not really working to have all of this out-of-tree, there must have been
>> discussions about the requirements for a proper ethernet switch subsystem.
>>
>> I'm not a good net developers, just a grumpy user having to deal with all
>> of this out-of-tree code that's not helpful with changing interfaces like
>> device tree and so on.
>>
>> Can you people who worked on this over the years pit in with your
>> requirements for an ethernet switch subsystem so we can house these
>> drivers in a proper way?
>>
>> What we need AFAICT:
>>
>> - Consensus on userspace ABI
>> - Consensus on ethtool extenstions
>> - Consensus on where in drivers/net this goes
>>
>> You can kick me for not knowing what I'm talking about and how complex the
>> problem is now.

Kicking you would not be fair, but you are about 3 years late ;) We had
such discussions in 2014 after a failed attempt at submitting swconfig
as a possible model. 3 years later we have 1 major switchdev driver:
mlxsw and quite a few active DSA drivers. The paradigms that apply are:

- normal Linux tools keep working: bridge, iproute2, ethtool
- every user-visible port has a corresponding network device, in order
to meet the first paradigm
- for every other part of the switch that does not have a net_device
representor, devlink can/should be used.
-- 
Florian