Messages in this thread | | | From | Florian Fainelli <> | Subject | Re: [RFC 0/4] net: l2switch: Provide support for L2 switch on i.MX28 SoC | Date | Fri, 27 Nov 2020 20:34:55 -0800 |
| |
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
| |