Hello Jakub, On Fri, 4 Nov 2022 20:05:30 -0700 Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > On Fri, 4 Nov 2022 18:41:49 +0100 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. > > > > Add a new tagging protocol based on SKB extensions to convey the > > information about the destination port to the MAC driver > > This is what METADATA_HW_PORT_MUX is for, you shouldn't have > to allocate a piece of memory for every single packet. Does this work with DSA ? The information conveyed in the extension is the DSA port identifier. I'm not familiar at all with METADATA_HW_PORT_MUX, should we extend that mechanism to convey the DSA port id ? I also agree that allocating data isn't the best way to go, but from the history of this series, we've tried 3 approaches so far : - Adding a new field to struct sk_buff, which isn't a good idea - Using the skb headroom, but then we can't know for sure is the skb contains a DSA tag or not - Using skb extensions, that comes with the cost of this memory allocation. Is this approach also incorrect then ? > Also the series doesn't build. Can you elaborate more ? I can't reproduce the build failure on my side, and I didn't get any reports from the kbuild bot, are you using a specific config file ? Thanks, Maxime
