mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alexandra Winter <wintera@linux.ibm.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: DENG Qingfang <dqfext@gmail.com>, Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>, netdev <netdev@vger.kernel.org>,
	linux-kernel@vger.kernel.org,
	Tobias Waldekranz <tobias@waldekranz.com>,
	Marek Behun <marek.behun@nic.cz>,
	Russell King - ARM Linux admin <linux@armlinux.org.uk>
Subject: Re: [RFC PATCH net-next 3/3] net: dsa: listen for SWITCHDEV_{FDB,DEL}_ADD_TO_DEVICE on foreign bridge neighbors
Date: Mon, 16 Nov 2020 09:02:29 +0100	[thread overview]
Message-ID: <e8aa4a48-b8b2-99e1-b308-b54adb5f0dc4@linux.ibm.com> (raw)
In-Reply-To: <20201112134910.jpbfrjfwlb3734im@skbuf>



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.

      reply	other threads:[~2020-11-16  8:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-08 13:19 [RFC PATCH net-next 0/3] Offload learnt bridge addresses to DSA Vladimir Oltean
2020-11-08 13:19 ` [RFC PATCH net-next 1/3] net: dsa: don't use switchdev_notifier_fdb_info in dsa_switchdev_event_work Vladimir Oltean
2020-11-08 23:57   ` Vladimir Oltean
2020-11-08 13:19 ` [RFC PATCH net-next 2/3] net: dsa: move switchdev event implementation under the same switch/case statement Vladimir Oltean
2020-11-11  3:44   ` Florian Fainelli
2020-11-08 13:19 ` [RFC PATCH net-next 3/3] net: dsa: listen for SWITCHDEV_{FDB,DEL}_ADD_TO_DEVICE on foreign bridge neighbors Vladimir Oltean
2020-11-08 14:09   ` DENG Qingfang
2020-11-08 17:23     ` Vladimir Oltean
2020-11-08 23:59       ` Andrew Lunn
2020-11-09  0:30         ` Vladimir Oltean
2020-11-09  1:06           ` Andrew Lunn
2020-11-09  8:09           ` Tobias Waldekranz
2020-11-09 10:03             ` Vladimir Oltean
2020-11-09 11:05               ` Tobias Waldekranz
2020-11-09 12:31                 ` Vladimir Oltean
2020-11-09 12:38                   ` Vladimir Oltean
2020-11-09 12:54                     ` Tobias Waldekranz
2020-11-13  3:48                     ` Florian Fainelli
2020-11-11 10:13       ` Alexandra Winter
2020-11-11 10:36         ` Vladimir Oltean
2020-11-11 14:14           ` Alexandra Winter
2020-11-12 13:49             ` Vladimir Oltean
2020-11-16  8:02               ` Alexandra Winter [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e8aa4a48-b8b2-99e1-b308-b54adb5f0dc4@linux.ibm.com \
    --to=wintera@linux.ibm.com \
    --cc=andrew@lunn.ch \
    --cc=dqfext@gmail.com \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=marek.behun@nic.cz \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=tobias@waldekranz.com \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome