Hi Florian,

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

Ok.

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

I'm very grateful for this insight and explanation from Vladimir.

> Basically any time you have DMA + integrated switch
> tightly coupled you have what we have coined a "pure switchdev"
> wrapper.

Ok.

> 
> > 
> > 
> > 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 will look into those examples and try to follow them for MTIP.

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

Ok.

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

I'm not afraid to rework FEC. I just thought that DSA would be the best
fit for the MTIP. However, after posting the RFC, the community gave me
arguments that I was wrong.

I'm happy for having so detailed feedback :-).


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de