netdev - Re: [PATCH 0/4] RFC CPSW switchdev mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 6 Jun 2018 01:40:21 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Grygorii Strashko <grygorii.strashko@...com>
Cc:     Ilias Apalodimas <ilias.apalodimas@...aro.org>,
        Ivan Vecera <ivecera@...hat.com>,
        Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
        ivan.khoronzhuk@...aro.org, nsekhar@...com,
        francois.ozog@...aro.org, yogeshs@...com, spatton@...com
Subject: Re: [PATCH 0/4] RFC CPSW switchdev mode

> So, my understanding for (1) "blocked FDB entry support" is reasonable
> extension for bridge/switchdev ("green").

You might have to justify it, but yes.

> > Does the network stack need for forward specific multicast MAC
> > addresses between bridge ports independent of the state? If there is
> > no need for it, you don't need to accelerate it.
> 
> Assume this is about item 2 - this question is related to STP packets.
> CPSW/ALE will drop STP packets if receiving port is in blocking/learning states 
> unless corresponding  mcast entry exist in ALE entry with (Supervisory Packet) flag set
> (Actually ALE mcast entry has two fields (TRM): 
> Supervisory Packet (SUPER): When set, this field indicates that the packet
>  with a matching multicast destination address is a supervisory packet.
> Multicast Forward State (MCAST_FWD_STATE): Indicates the port state(s) required for the received port
> on a destination address lookup in order for the multicast packet to be forwarded to
> the transmit port(s). A transmit port must be in the Forwarding state in
> order to forward the packet.)

So i this case, i would expect your driver to just add these entries
to the ALE. No need for configuration for above. Just do it as soon as
a port is made a member of a bridge. And remove it when the port
leaves the bridge.

DSA devices are smarter. They all have hardware which looks for BPDU
and forwards them to the host independent of the state of the port.
They also tend to have hardware looking for IGMP packets, and will
forward them to the host, even if the multicast address is not being
forwarded to the host.

> ** "unknown vlan configuration"
> 
> This is about following use case. Non static network configuration when
> CPSW based device knows what traffic it can accept (Host port 0), but
> it has no knowledge (or limited) about network segments attached to Port 1 and Port 2.
> 
> For example: Host 0 can accept only vlan 100 traffic coming from Port 1.
> ALE entry: vid =100, port_mask 0x3
> 
> But there can be vlan 50 created in attached network segments.
> Unknown VLAN Force Untagged Egress ports Mask = 0x0
> Unknown VLAN Registered Multicast Flood Ports Mask = 0x6 (P1|P2)
> Unknown VLAN Multicast Flood ports Mask = 0x6 (P1|P2)
> Unknown VLAN Member ports List  = 0x6 (P1|P2)
> 
> with above configuration packets with "unknown vlan" (no ALE entry) will
> still be forwarded between port 1 and 2, but not Port 0. 
> 
> So, is it reasonable to add "unknown vlan configuration" to bridge/switchdev
> if not exist yet? will any other hw known benefit from it?

You need to think about the case of two e1000e. How do you configure
this setup to do what you want? It probably is already possible.

     Andrew