Messages in this thread | | | Date | Tue, 29 Jun 2021 10:09:37 +0200 | From | Lukasz Majewski <> | Subject | Re: [RFC 2/3] net: Provide switchdev driver for NXP's More Than IP L2 switch |
| |
Hi Vladimir,
> On Mon, Jun 28, 2021 at 04:13:14PM +0200, Lukasz Majewski wrote: > > > > > So before considering merging your changes, i would like to > > > > > see a usable binding. > > > > > > > > > > I also don't remember seeing support for STP. Without that, > > > > > your network has broadcast storm problems when there are > > > > > loops. So i would like to see the code needed to put ports > > > > > into blocking, listening, learning, and forwarding states. > > > > > > > > > > Andrew > > > > > > I cannot stress enough how important it is for us to see STP > > > support and consequently the ndo_start_xmit procedure for switch > > > ports. > > > > Ok. > > > > > Let me see if I understand correctly. When the switch is enabled, > > > eth0 sends packets towards both physical switch ports, and eth1 > > > sends packets towards none, but eth0 handles the link state of > > > switch port 0, and eth1 handles the link state of switch port 1? > > > > Exactly, this is how FEC driver is utilized for this switch. > > This is a much bigger problem than anything which has to do with code > organization. Linux does not have any sort of support for unmanaged > switches.
My impression is similar. This switch cannot easily fit into DSA (lack of appending tags) nor to switchdev.
The latter is caused by two modes of operation:
- Bypass mode (no switch) -> DMA1 and DMA0 are used - Switch mode -> only DMA0 is used
Moreover, from my understanding of the CPSW - looks like it uses always just a single DMA, and the switching seems to be the default operation for two ethernet ports.
The "bypass mode" from NXP's L2 switch seems to be achieved inside the CPSW switch, by configuring it to not pass packets between those ports.
> Please try to find out if your switch is supposed to be able > to be managed (run control protocols on the CPU).
It can support all the "normal" set of L2 switch features:
- VLANs, lookup table (with learning), filtering and forwarding (Multicast, Broadcast, Unicast), priority queues, IP snooping, etc.
Frames for BPDU are recognized by the switch and can be used to implement support for RSTP. However, this switch has a separate address space (not covered and accessed by FEC address).
> If not, well, I > don't know what to suggest.
For me it looks like the NXP's L2 switch shall be treated _just_ as offloading IP block to accelerate switching (NXP already support dpaa[2] for example).
The idea with having it configured on demand, when: ip link add name br0 type bridge; ip link set br0 up; ip link set eth0 master br0; ip link set eth1 master br0;
Seems to be a reasonable one. In the above scenario it would work hand by hand with FEC drivers (as those would handle PHY communication setup and link up/down events).
It would be welcome if the community could come up with some rough idea how to proceed with this IP block support (especially that for example imx287 is used in many embedded devices and is going to be in active production for next 10+ years).
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 [unhandled content-type:application/pgp-signature] | |