linux-kernel - Re: [RFC PATCH net-next 3/3] net: dsa: listen for SWITCHDEV_{FDB,DEL}_ADD_TO

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 for Android: free password hash cracker in your pocket

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

Message-ID: <e8aa4a48-b8b2-99e1-b308-b54adb5f0dc4@linux.ibm.com>
Date:   Mon, 16 Nov 2020 09:02:29 +0100
From:   Alexandra Winter <wintera@...ux.ibm.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     DENG Qingfang <dqfext@...il.com>, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        netdev <netdev@...r.kernel.org>, linux-kernel@...r.kernel.org,
        Tobias Waldekranz <tobias@...dekranz.com>,
        Marek Behun <marek.behun@....cz>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>
Subject: Re: [RFC PATCH net-next 3/3] net: dsa: listen for
 SWITCHDEV_{FDB,DEL}_ADD_TO_DEVICE on foreign bridge neighbors



On 12.11.20 14:49, Vladimir Oltean wrote:
> On Wed, Nov 11, 2020 at 03:14:26PM +0100, Alexandra Winter wrote:
>> On 11.11.20 11:36, Vladimir Oltean wrote:
>>> Hi Alexandra,
>>>
>>> On Wed, Nov 11, 2020 at 11:13:03AM +0100, Alexandra Winter wrote:
>>>> On 08.11.20 18:23, Vladimir Oltean wrote:
>>>>> On Sun, Nov 08, 2020 at 10:09:25PM +0800, DENG Qingfang wrote:
>>>>>> Can it be turned off for switches that support SA learning from CPU?
>>>>>
>>>>> Is there a good reason I would add another property per switch and not
>>>>> just do it unconditionally?
>>>>>
>>>> I have a similar concern for a future patch, where I want to turn on or off, whether the
>>>> device driver listens to SWITCHDEV_{FDB,DEL}_ADD_TO_DEVICE for a certain interface.
>>>> (Options will be: static MACs only, learning in the device or learning in bridge and notifications to device)
>>>> What about 'bridge link set dev $netdev learning_sync on self' respectively the corresponding netlink message?
>>>
>>> My understanding is that "learning_sync" is for pushing learnt addresses
>>> from device to bridge, not from bridge to device.
>>>
>> uh, sorry copy-paste error. I meant:
>> 'bridge link set dev $netdev learning on self'
> 
> Even with "learning" instead of "learning_sync", I don't understand what
> the "self" modifier would mean and how it would help, sorry.
> 
With the self modifier, the command is not executed by the linux bridge but instead sent to the device driver of the
respective bridgeport. So AFAIU 'learning on self' would mean, that instead of only the bridge doing the learning on this
bridgeport, the device itself should do the learning. Which sounds to me like a good fit for SA learning from CPU.

It seems that the self modifier is not used on hardware switches today, but rather on virtualized network cards, where
it is e.g. used ot turn VEPA mode on or off per virtual interface. In drivers/s390/net/qeth we use 'learning_sync on self',
to control whether a virtualized interface should synchronize the card's fdb with an attached linux bridge.