Messages in this thread | | | Date | Fri, 27 Nov 2020 01:03:25 +0100 | From | Lukasz Majewski <> | Subject | Re: [RFC 0/4] net: l2switch: Provide support for L2 switch on i.MX28 SoC |
| |
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 [unhandled content-type:application/pgp-signature] | |