Florian Fainelli
2018-Dec-16 17:14 UTC
[Bridge] [PATCH net-next] Documentation: networking: Clarify switchdev devices behavior
Le 12/16/18 ? 12:25 AM, Ido Schimmel a ?crit?:> On Wed, Dec 12, 2018 at 03:09:43PM -0800, Florian Fainelli wrote: >> This patch provides details on the expected behavior of switchdev >> enabled network devices when operating in a "stand alone" mode, as well >> as when being bridge members. This clarifies a number of things that >> recently came up during a bug fixing session on the b53 DSA switch >> driver. >> >> Signed-off-by: Florian Fainelli <f.fainelli at gmail.com> >> --- >> Hi all, >> >> Please review carefully, and let me know if you think some of the >> behaviors described below do not make any sense. Thanks! >> >> Documentation/networking/switchdev.txt | 86 ++++++++++++++++++++++++++ >> 1 file changed, 86 insertions(+) >> >> diff --git a/Documentation/networking/switchdev.txt b/Documentation/networking/switchdev.txt >> index 82236a17b5e6..8c83174b477b 100644 >> --- a/Documentation/networking/switchdev.txt >> +++ b/Documentation/networking/switchdev.txt >> @@ -392,3 +392,89 @@ switchdev_trans_item_dequeue() >> >> If a transaction is aborted during "prepare" phase, switchdev code will handle >> cleanup of the queued-up objects. >> + >> +Switchdev enabled network device expected behavior >> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> + >> +Below is a set of defined behavior that switchdev enabled network device must be >> +adhering to. >> + >> +Configuration less state >> +------------------------ >> + >> +Upon driver bring up, the network devices must be fully operational, and the >> +backing driver must be configuring the network device such that it is possible >> +to send and receive to this network device such that it is properly separate >> +from other network devices/ports (e.g: as is frequenty with a switch ASIC). How >> +this is achieved is heavily hardware dependent, but a simple solution can be to >> +use per-port VLAN identifiers. >> + >> +The network device must be capable of running a full IP protocol stack must be >> +working, including multicast, DHCP, IPv4/6, etc. If necessary, it should be >> +programming the appropriate filters for VLAN, multicast, unicast etc. The >> +underlying device driver must effectively be configured in a similar fashion to >> +what it would do when IGMP snooping is enabled for IP multicast over these >> +switchdev network devices and unsollicited multicast must be filtered as early >> +as possible into the hardware. >> + >> +When configuring VLANs on top of the network device, all VLANs must be working, >> +irrespective of the state of other network devices (e.g: other ports being part >> +of a VLAN aware bridge doing ingress VID checking). See below for details. >> + >> +Bridged network devices >> +----------------------- >> + >> +When a switchdev enabled network device is added as a bridge member, it should >> +not be disrupting any functionality of non-bridged network devices and they >> +should continue to behave as normal network devices. Depending on the bridge >> +configuration knobs below, the expected behavior is documented. >> + >> +VLAN filtering >> +~~~~~~~~~~~~~~ >> + >> +The Linux bridge allows the configuration of a VLAN filtering mode (compile and >> +run time) which must be observed by the underlying switchdev network >> +device/hardware: >> + >> +- with VLAN filtering turned off: frames ingressing the device with a VID that >> + is not programmed into the bridge/switch's VLAN table must be forwarded. > > mlxsw doesn't support it. These bridges are mainly used with VLAN > devices where the packets ingress the bridge untagged. When configured > over physical ports, we only allow untagged packets into such a bridge.I suppose I got confused about the meaning of VLAN filtering on a Linux bridge when offloaded to a switch, VLAN filtering turned off effectively means: no VLAN awareness, everything untagged. There are really many misnomers within the bridge code then, like MC_DISABLED, this really means: flood or do not flood multicast, not "disable multicast" which would be madness.> >> + >> +- with VLAN filtering turned on: frames ingressing the device with a VID that is >> + not programmed into the bridges/switch's VLAN table must be dropped. > > ack > >> + >> +Non-bridged network ports of the same switch fabric must not be disturbed in any >> +way, shape or form by the enabling of VLAN filtering. >> + >> +VLAN devices configured on top of a switchdev network device (e.g: sw0p1.100) >> +which is a bridge port member must also observe the following behavior: >> + >> +- with VLAN filtering turned off, these VLAN devices must be fully functional >> + since the hardware is allowed VID frames >> + >> +- with VLAN filtering turned on, these VLAN devices are not going to be >> + functional unless the bridge's VLAN database is also configured to have that >> + VID enabled for the underlying network device/port >> + (e.g: bridge vlan add vid 100 dev sw0p1) > > mlxsw forbids the enslavement of VLAN devices to VLAN-aware bridges. It > doesn't really make sense to enable VLAN filtering when all the packets > are untagged.Did you mean VLAN-unaware here, otherwise that would contradict the statement that VLAN-aware bridges mean everything untagged, or am I incorrectly understanding things here?> > But I disagree with the comment about the underlying port. When you > configured the VLAN device, it should have enabled the VLAN filters on > the real device via ndo_vlan_rx_add_vid().That is really why I submitted this patch, because right now I have a patch (yet to be submitted) which adds ndo_vlan_rx_{add,kill}_vid() and if the underlying device is enslaved into a bridge, I just do nothing and let the bridge control the VLAN membership, hence my comment and example here. What you are saying is that we should have these two cases: 1) VLAN devices on top of VLAN unaware bridge: allow the VLAN device and program VLAN filter on the underlying switch port to permit VLAN tagging 2) VLAN devices on top of a VLAN aware bridge: deny the VLAN device creation and let the bridge, which is VLAN aware manage the port VLAN membership In case 1) or 2) if the desire is to have a VLAN aware network device this can be either done through a VLAN device on top of the switch port, or through a VLAN device on top of the bridge master itself, and in either case, this amounts to doing about the same thing. Did I get this right?> >> + >> +Because VLAN filtering can be turned on/off at runtime, the switchdev driver >> +must be able to re-configure the underlying hardware on the fly to honor the >> +toggling of that option and behave appropriately. > > Please mention that switchdev drivers can refuse the operation. >Will do, thanks! -- Florian
Ido Schimmel
2018-Dec-18 07:01 UTC
[Bridge] [PATCH net-next] Documentation: networking: Clarify switchdev devices behavior
On Sun, Dec 16, 2018 at 09:14:09AM -0800, Florian Fainelli wrote:> Le 12/16/18 ? 12:25 AM, Ido Schimmel a ?crit?: > > On Wed, Dec 12, 2018 at 03:09:43PM -0800, Florian Fainelli wrote: > >> +Non-bridged network ports of the same switch fabric must not be disturbed in any > >> +way, shape or form by the enabling of VLAN filtering. > >> + > >> +VLAN devices configured on top of a switchdev network device (e.g: sw0p1.100) > >> +which is a bridge port member must also observe the following behavior: > >> + > >> +- with VLAN filtering turned off, these VLAN devices must be fully functional > >> + since the hardware is allowed VID frames > >> + > >> +- with VLAN filtering turned on, these VLAN devices are not going to be > >> + functional unless the bridge's VLAN database is also configured to have that > >> + VID enabled for the underlying network device/port > >> + (e.g: bridge vlan add vid 100 dev sw0p1) > > > > mlxsw forbids the enslavement of VLAN devices to VLAN-aware bridges. It > > doesn't really make sense to enable VLAN filtering when all the packets > > are untagged. > > Did you mean VLAN-unaware here, otherwise that would contradict the > statement that VLAN-aware bridges mean everything untagged, or am I > incorrectly understanding things here?I meant VLAN-aware... In a VLAN-unaware bridge the VLAN is meaningless. For example, there is no filtering based on VLAN at ingress/egress and FDB entries are only searched based on MAC (VLAN is always 0). This is in contrast to a VLAN-aware bridge. When you enslave VLAN netdevs to a bridge, the bridge sees untagged packets. The VLAN tag is pulled from the packet in Rx path and then the packet is injected to the bridge via the Rx handler configured on the VLAN netdev. Therefore, there is point in enslaving these device to a VLAN-aware bridge. Also, mlxsw only supports a single VLAN-aware bridge. You can however, configure 1K VLAN-unaware bridges.> > But I disagree with the comment about the underlying port. When you > > configured the VLAN device, it should have enabled the VLAN filters on > > the real device via ndo_vlan_rx_add_vid(). > > That is really why I submitted this patch, because right now I have a > patch (yet to be submitted) which adds ndo_vlan_rx_{add,kill}_vid() and > if the underlying device is enslaved into a bridge, I just do nothing > and let the bridge control the VLAN membership, hence my comment and > example here. > > What you are saying is that we should have these two cases: > > 1) VLAN devices on top of VLAN unaware bridge: allow the VLAN device and > program VLAN filter on the underlying switch port to permit VLAN taggingWhen you say "on top" you mean enslaved to?> 2) VLAN devices on top of a VLAN aware bridge: deny the VLAN device > creation and let the bridge, which is VLAN aware manage the port VLAN > membershipmlxsw does not forbid the creation of the VLAN device. It only forbids its enslavement to a VLAN-aware bridge.> In case 1) or 2) if the desire is to have a VLAN aware network device > this can be either done through a VLAN device on top of the switch port, > or through a VLAN device on top of the bridge master itself, and in > either case, this amounts to doing about the same thing. > > Did I get this right?I'm saying that a VLAN-aware bridge with VIDs 10-100 (for example) is equivalent to VLAN devices with VIDs 10-100 enslaved to br10-br100, respectively. It is up to you if you want to / can support both modes. We support both, but most / all users use the VLAN-aware bridge.