lkml.org 
[lkml]   [2020]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC 0/4] net: l2switch: Provide support for L2 switch on i.MX28 SoC
Date


On 11/27/2020 4:33 PM, Lukasz Majewski wrote:
>> So why use DSA at all? What benefit does it bring you? Why not do the
>> entire switch configuration from within FEC, or a separate driver very
>> closely related to it?
>
> Mine rationale to use DSA and FEC:
> - Make as little changes to FEC as possible

Which is entirely possible if you stick to Vladimir suggestions of
exporting services for the MTIP switch driver.

>
> - Provide separate driver to allow programming FDB, MDB, VLAN setup.
> This seems straightforward as MTIP has separate memory region (from
> FEC) for switch configuration, statistics, learning, static table
> programming. What is even more bizarre FEC and MTIP have the same 8
> registers (with different base address and +4 offset :-) ) as
> interface to handle DMA0 transfers.

OK, not sure how that is relevant here? The register organization should
never ever dictate how to pick a particular subsystem.

>
> - According to MTIP description from NXP documentation, there is a
> separate register for frame forwarding, so it _shall_ also fit into
> DSA.

And yet it does not, Vladimir went into great length into explaining
what makes the MTIP + dual FEC different here and why it does not
qualify for DSA. Basically any time you have DMA + integrated switch
tightly coupled you have what we have coined a "pure switchdev" wrapper.

>
>
> For me it would be enough to have:
>
> - lan{12} - so I could enable/disable it on demand (control when switch
> ports are passing or not packets).
>
> - Use standard net tools (like bridge) to setup FDB/MDB, vlan
>
> - Read statistics from MTIP ports (all of them)
>
> - I can use lan1 (bridged or not) to send data outside. It would be
> also correct to use eth0.

You know you can do that without having DSA, right? Look at mlxsw, look
at rocker. You can call multiple times register_netdevice() with custom
network devices that behave differently whether HW bridging offload is
offered or not, whether the switch is declared in Device Tree or not.

>
> I'm for the most pragmatic (and simple) solution, which fulfill above
> requirements.

The most pragmatic solution is to implement switchdev operations to
offer HW bridging offload, VLAN programming, FDB/MDB programming.

It seems to me that you are trying to look for a framework to avoid
doing a bit of middle layer work between switchdev and the FEC driver
and that is not setting you for success.
--
Florian

\
 
 \ /
  Last update: 2020-11-28 18:58    [W:0.060 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site