[PATCH net-next v2 2/5] net: dsa: add out-of-band tagging protocol

[Maxime Chevallier]

Hello Jakub,

On Mon, 16 May 2022 12:20:48 -0700
Jakub Kicinski <kuba at kernel.org> wrote:

> On Sat, 14 May 2022 17:06:53 +0200 Maxime Chevallier wrote:
> > This tagging protocol is designed for the situation where the link
> > between the MAC and the Switch is designed such that the Destination
> > Port, which is usually embedded in some part of the Ethernet
> > Header, is sent out-of-band, and isn't present at all in the
> > Ethernet frame.
> > 
> > This can happen when the MAC and Switch are tightly integrated on an
> > SoC, as is the case with the Qualcomm IPQ4019 for example, where
> > the DSA tag is inserted directly into the DMA descriptors. In that
> > case, the MAC driver is responsible for sending the tag to the
> > switch using the out-of-band medium. To do so, the MAC driver needs
> > to have the information of the destination port for that skb.
> > 
> > This out-of-band tagging protocol is using the very beggining of
> > the skb headroom to store the tag. The drawback of this approch is
> > that the headroom isn't initialized upon allocating it, therefore
> > we have a chance that the garbage data that lies there at
> > allocation time actually ressembles a valid oob tag. This is only
> > problematic if we are sending/receiving traffic on the master port,
> > which isn't a valid DSA use-case from the beggining. When dealing
> > from traffic to/from a slave port, then the oob tag will be
> > initialized properly by the tagger or the mac driver through the
> > use of the dsa_oob_tag_push() call.
> > 
> > Signed-off-by: Maxime Chevallier <maxime.chevallier at bootlin.com>  
> 
> This must had been asked on v1 but there's no trace of it in the
> current submission afaict...

No you're correct, this wasn't explained.

> If the tag is passed in the descriptor how is this not a pure
> switchdev driver? The explanation must be preserved somehow.

The main reason is that although the MAC and switch are rightly coupled
on that platform, the switch is actually a QC8K that can live on it's
own, as an external switch. Here, it's just a slightly modified version
of this IP.

The same goes for the MAC IP, but so far we don't support any other
platform that have the MAC as a standalone controller. As far as we can
tell, platforms that have this MAC also include a QCA8K, but the
datasheet also mentions other modes (like outputing RGMII).

Is this valid to have it as a standalone ethernet driver in that
situation ?

Thanks,

Maxime