2013/10/30 Felix Fietkau [off-list ref]:

quoted

With DSA, you would bridge between port1.4 and port2.400.  I'm still
not sure what your argument is arguing for or against.

I'm saying most switches that we support cannot do DSA-style packet port
tagging for ingress/egress. That kind of setup can be done with some
software bridging when setting up VLAN tables appropriately, but I'm not
sure it's possible to emulate this if you're treating the switch as a
'bridge' and trying to do handle this via the FDB API, which is what we
were discussing earlier.

DSA works nicely because it has its own Ethertype, and also because
the switches are configurable enough to allow for the insertion of a
custom Ethertype for which you can register a corresponding
dev_add_pack() handler. Even on some switches which support custom
tags appended or prepended such as those from Broadcom, a tag is
usually inserted between ethe Ethernet Source Address and the
Ethertype, but this tag has variable fields. I could imagine that we
extend the dev_add_pack() to include a mask to perform the matching,
but this is going to add an "and" logical operation in a hot-path,
would that be acceptable?

And this only works when the tag is prepended, if it is appended, we
are kind of stuck because we do not really have any way to look for it
at the end of the frame but assume that is here/not here...
-- 
Florian