Re: [PATCH v2 net-next 07/22] ether: Add dedicated Ethertype for pseudo-802.1Q DSA tagging

[Vladimir Oltean]

On 4/10/19 5:04 AM, Florian Fainelli wrote:
> On 4/9/2019 5:56 PM, Vladimir Oltean wrote:
> > With the newly added DSA_TAG_PROTO_8021Q, switch devices that don't
> > support a native insertion/extraction header on the CPU port may still
> > enjoy the benefits of port isolation with a custom VLAN tag.
> >
> > For this, they need to have a customizable TPID in hardware and a new
> > Ethertype to distinguish between real 802.1Q traffic and the private
> > tags used for port separation.
> >
> > Signed-off-by: Vladimir Oltean <olteanv@xxxxxxxxx>
>
> Why was not using ETH_P_EDSA not suitable? Also how do we intend to use
> this from user-space? The latest libpcap/tcpdump changes essentially
> look at the dsa/tagging sysfs attribute for the master network device to
> determine what type of underlying tagging protocol is used, since you
> allocated a new one (NET_DSA_TAG_8021Q) you could have added a matching
> string in sysfs so we can recognize it?

I'll freely admit that I hardly gave a second thoughts to Andrew's 
previous reply, who said that tcpdump will parse these frames as MEDSA 
and not much can be done about it.

But thanks for the hint, I was completely unaware of the recent pull 
requests you guys made for DSA data link types in libpcap. As a pleb I 
am only using the latest tcpdump/libpcap release tag.
I didn't look closely at the pull requests, but you're saying that it's 
possible to discern based on /sys/class/net/eth2/dsa/tagging (which 
returns "sja1105") and figure out that it's not MEDSA?

Also remember that NET_DSA_TAG_8021Q in my proposal is not a real 
tagging protocol and therefore you won't see it in sysfs.

Awaiting some further advice on this, as I have obviously missed out on 
quite a lot.

Thanks,
-Vladimir