| Message ID | 20190410005700.31582-8-olteanv@gmail.com |
|---|---|
| State | Changes Requested |
| Delegated to: | David Miller |
| Headers | show |
| Series | NXP SJA1105 DSA driver | expand |
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@gmail.com> 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?
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@gmail.com> > > 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
diff --git a/include/uapi/linux/if_ether.h b/include/uapi/linux/if_ether.h index 3a45b4ad71a3..3158ba672b72 100644 --- a/include/uapi/linux/if_ether.h +++ b/include/uapi/linux/if_ether.h @@ -109,6 +109,7 @@ #define ETH_P_QINQ2 0x9200 /* deprecated QinQ VLAN [ NOT AN OFFICIALLY REGISTERED ID ] */ #define ETH_P_QINQ3 0x9300 /* deprecated QinQ VLAN [ NOT AN OFFICIALLY REGISTERED ID ] */ #define ETH_P_EDSA 0xDADA /* Ethertype DSA [ NOT AN OFFICIALLY REGISTERED ID ] */ +#define ETH_P_DSA_8021Q 0xDADB /* Fake VLAN Header for DSA [ NOT AN OFFICIALLY REGISTERED ID ] */ #define ETH_P_IFE 0xED3E /* ForCES inter-FE LFB type */ #define ETH_P_AF_IUCV 0xFBFB /* IBM af_iucv [ NOT AN OFFICIALLY REGISTERED ID ] */
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@gmail.com> --- Changes in v2: New patch. include/uapi/linux/if_ether.h | 1 + 1 file changed, 1 insertion(+)