On Sun, 5 May 2019 at 01:49, Vivien Didelot <vivien.dide...@gmail.com> wrote: > > Hi Vladimir, > > On Sat, 4 May 2019 16:59:13 +0300, Vladimir Oltean <olte...@gmail.com> wrote: > > Frames get processed by DSA and redirected to switch port net devices > > based on the ETH_P_XDSA multiplexed packet_type handler found by the > > network stack when calling eth_type_trans(). > > > > The running assumption is that once the DSA .rcv function is called, DSA > > is always able to decode the switch tag in order to change the skb->dev > > from its master. > > > > However there are tagging protocols (such as the new DSA_TAG_PROTO_SJA1105, > > user of DSA_TAG_PROTO_8021Q) where this assumption is not completely > > true, since switch tagging piggybacks on the absence of a vlan_filtering > > bridge. Moreover, management traffic (BPDU, PTP) for this switch doesn't > > rely on switch tagging, but on a different mechanism. So it would make > > sense to at least be able to terminate that. > > > > Having DSA receive traffic it can't decode would put it in an impossible > > situation: the eth_type_trans() function would invoke the DSA .rcv(), > > which could not change skb->dev, then eth_type_trans() would be invoked > > again, which again would call the DSA .rcv, and the packet would never > > be able to exit the DSA filter and would spiral in a loop until the > > whole system dies. > > > > This happens because eth_type_trans() doesn't actually look at the skb > > (so as to identify a potential tag) when it deems it as being > > ETH_P_XDSA. It just checks whether skb->dev has a DSA private pointer > > installed (therefore it's a DSA master) and that there exists a .rcv > > callback (everybody except DSA_TAG_PROTO_NONE has that). This is > > understandable as there are many switch tags out there, and exhaustively > > checking for all of them is far from ideal. > > > > The solution lies in introducing a filtering function for each tagging > > protocol. In the absence of a filtering function, all traffic is passed > > to the .rcv DSA callback. The tagging protocol should see the filtering > > function as a pre-validation that it can decode the incoming skb. The > > traffic that doesn't match the filter will bypass the DSA .rcv callback > > and be left on the master netdevice, which wasn't previously possible. > > > > Signed-off-by: Vladimir Oltean <olte...@gmail.com> > > Looks promising, I'll try to give this a try soon! > > Thanks, > Vivien
Hi Vivien, Thanks but what do you mean by trying it out? -Vladimir
