mainlining shenanigans
beeee08ca1
Vladimir Oltean says:
====================
Traffic termination for sja1105 ports under VLAN-aware bridge
This set of patches updates the sja1105 DSA driver to be able to send
and receive network stack packets on behalf of a VLAN-aware upper bridge
interface.
The reasons why this has traditionally been a problem are explained in
the "Traffic support" section of Documentation/networking/dsa/sja1105.rst.
(the entire documentation will be revised in a separate patch series).
The limitations that have prevented us from doing this so far have now
been partially lifted by the bridge's ability to send a packet with
skb->offload_fwd_mark = true, which means that the accelerator is
allowed to look up its hardware FDB when sending a packet and deliver it
to those destination ports. Basically skb->dev is now just a conduit to
the switchdev driver's ndo_start_xmit(), and does not guarantee that the
packet will really be transmitted on that port (but it will be
transmitted where it should, nonetheless).
Apart from the ability to perform IP termination on VLAN-aware bridges
on top of sja1105 interfaces, we also gain the following features:
- VLAN-aware software bridging between sja1105 ports and "foreign"
(non-DSA) interfaces
- software bridging between sja1105 bridge ports, and software LAG
uppers of sja1105 ports (as long as the bridge is VLAN-aware)
The only things that don't work are:
1. to create an AF_PACKET socket on top of a sja1105 port that is under
a VLAN-aware bridge. This is because the "imprecise RX" procedure
selects an RX port for data plane* packets based on the assumption
that the packet will land in the bridge's data path. If ebtables
rules are added to remove some packets from the bridge's data path,
that assumption will be broken. Nonetheless, this is not a limitation
that negatively impacts the known use cases with this switch. If
there was a way to impose user space restrictions against creating
AF_PACKET sockets on this particular configuration, I could be
interested in adding those restrictions, but I think there are other
known broken configs already which are not checked by the kernel
today (like for example that the bridge's rx_handler steals packets
anyway from AF_PACKET sockets with exact-match ptype handlers, as
opposed to ptype_all which are processed earlier; this is precisely
the reason why ebtables rules are generally needed to avoid that).
2. to send traffic on behalf of an 8021q upper of a standalone interface,
while other sja1105 ports are part of a VLAN-aware bridge. This is
because sja1105 sets ds->vlan_filtering_is_global = true, so we
cannot make the standalone port ignore the VLAN header from the
packet on RX, so we cannot make tag_8021q enforce its own pvid for
the packets belonging to that port's 8021q upper. So we cannot
determine in the first place that packets come from that port, unless
we iterate through all 8021q uppers of all ports, and enforce
uniqueness of VLAN IDs. I am not sure if this is what I want / if it
is worth it, so currently all 8021q uppers are denied, regardless of
whether the switch has ports under a VLAN-aware bridge or not
(otherwise it becomes complicated even to track the state).
Nonetheless, the VID uniqueness of all 8021q uppers does raise
another question: what to do with VID 0, which has no 8021q upper,
but the 8021q module adds it to our RX filter with vlan_vid_add().
I am honestly not sure what to do. The best I can do is enable a
hardware bit in sja1105 which reclassifies VID 0 frames to the PVID,
and they will be sent on the CPU port using either the tag_8021q pvid
of standalone ports, or the bridge pvid of VLAN-aware ports. So at
the very least, those packets are still 'kinda' processed as if they
were untagged, but the VID 0 is lost, though. In my defence, Marvell
appears to do the same thing with reclassifying VID 0 frames, see
commit
|
||
|---|---|---|
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| fs | ||
| include | ||
| init | ||
| ipc | ||
| kernel | ||
| lib | ||
| LICENSES | ||
| mm | ||
| net | ||
| samples | ||
| scripts | ||
| security | ||
| sound | ||
| tools | ||
| usr | ||
| virt | ||
| .clang-format | ||
| .cocciconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| COPYING | ||
| CREDITS | ||
| Kbuild | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| README | ||
Linux kernel
============
There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.
In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``. The formatted documentation can also be read online at:
https://www.kernel.org/doc/html/latest/
There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.
Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.