Re: [RFC 0/4] net: l2switch: Provide support for L2 switch on i.MX28 SoC

[Lukasz Majewski <lukma@denx.de>]

[-- Attachment #1.1: Type: text/plain, Size: 3811 bytes --]

Hi Andrew,

> > > What is not yet clear to me is how you direct frames out specific
> > > interfaces. This is where i think we hit problems. I don't see a
> > > generic mechanism, which is probably why Lukasz put tagger as
> > > None.   
> > 
> > I've put the "None" tag just to share the "testable" RFC code.  
> 
> Tagging is a core feature of DSA. Without being able to direct a
> packet out a specific port, it is not really a DSA driver.  It is also
> core requirement of integrating a switch into Linux. A DSA driver, or
> a pure switchdev driver expects to be able to forward frames out
> specific ports.

Please find my answer, which I gave to Vladimir in the other mail (you
were CC'ed).

As a backup plan - the vlan tagging may be worth to investigate.

> 
> > It is possible to "tag" frames - at least from the manual [0]:
> > Chapter: "29.4.9.2 Forced Forwarding".
> > 
> > With using register HW_ENET_SWI_FORCE_FWD_P0
> > 29.9.34 ENET SWI Enable forced forwarding for a frame processed
> > from port 0 (HW_ENET_SWI_FORCE_FWD_P0)
> > 
> > One can "tag" the packet going from port0 (internal one from SoC)
> > to be forwarded to port1 (ENET-MAC0) or port2 (ENET-MAC1).
> > 
> > According to the legacy driver [1]:
> > "* It only replace the MAC lookup function,
> >  * all other filtering(eg.VLAN verification) act as normal"  
> 
> This might solve your outgoing frame problems. But you need to dive
> deep into how the FEC driver works, especially in a DSA like
> setup. 

Agree.

> The normal path would be, the slave interface passes a frame to
> the tagger driver, living in net/dsa/tag_*.c. Normally, it adds a
> header/trailer which the switch looks at. It then hands to packet over
> to the master Ethernet driver, which at some point will send the
> frame. Because the frame is self contained, we don't care what that
> ethernet driver actually does. It can add it to a queue and send it
> later. It can look at the QoS tags and send it with low priority after
> other frames, or could put it to the head of the queue and send it
> before other frames etc.
> 

Thanks for the explanation.

> Since you don't have self contained frames, this is a problem. After
> writing to this register, you need to ensure what is transmitted next
> is the specific frame you intend. It cannot be added to an existing
> queue etc. You need to know when the frame has been sent, so you can
> re-write this register for the next frame.

This needs to be assessed as the documentation is very vague. I'm
wondering how MTIP/NXP recommends usage of ESW_FFEN register.

> 
> This is why i said i don't know if the DSA architecture will work. You
> need a close coupling between the tagger setting the force bits, and
> the DMA engine sending the frame.

Maybe it would be just enough to program the ESW_FFEN register when ENET
descriptor is programmed for DMA? Earlier we would append the
superfluous tag in the tag_*.c ?

> 
> The other option is you totally ignore most of this and statically
> assign VLANs. Frames sent with VLAN 1 are forwarded out port 1. Frames
> sent with VLAN 2 are sent out port 2. You need the port to
> append/strip these VLAN tags for ingress/egress. tag_8021q.c gives you
> some code to help with this. But can you still use the hardware to
> switch frames between ports 1 and 2 without them going via the CPU?

Yes, it is possible to switch frames between ENET-MAC{01} ports without
any interaction from CPU.

> 
>        Andrew.




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

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel