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:   Sun, 3 Jun 2018 02:49:37 +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

Hi Grygorii

> Don't know howto:
> 1) add FDB entry with "blocked" flag - ALE can discard all packets with SRC/DST
> address = blocked MAC
> 2) add multicast MAC address with Supervisory Packet flag set. 
> Such packets will bypass most of checks inside ALE and will be forwarded in all port's
> states except "disabled".
> 3) add "unknown vlan configuration" : ALE provides possibility to configure
> default behavior for tagged packets with "unknown vlan" by configuring 
> - Unknown VLAN Force Untagged Egress ports Mask.
> - Unknown VLAN Registered Multicast Flood Ports Mask
> - Unknown VLAN Multicast Flood ports Mask
> - Unknown VLAN Member ports List
> 4) The way to detect "brctl stp br0 on/off"

You are probably looking at this from the wrong direction. Yes, the
switch can do these things. But the real question is, why would the
network stack want to do this? As i've said before, you are
accelerating the network stack by offloading things to the hardware.

Does the software bridge support FDB with a blocked flag? I don't
think it does. So you first need to extend the software bridge with
this concept. Then you can offload it to the hardware to accelerate
it.

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.

   Andrew