From: Roopa Prabhu <roprabhu@cisco•com>
To: John Fastabend <john.r.fastabend@intel•com>,
Stephen Hemminger <shemminger@vyatta•com>
Cc: <bhutchings@solarflare•com>, <netdev@vger•kernel.org>,
<mst@redhat•com>, <chrisw@redhat•com>, <davem@davemloft•net>,
<gregory.v.rose@intel•com>, <kvm@vger•kernel.org>,
<sri@us•ibm.com>
Subject: Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware
Date: Fri, 10 Feb 2012 05:45:29 -0800 [thread overview]
Message-ID: <CB5A5F79.44211%roprabhu@cisco.com> (raw)
In-Reply-To: <4F34042F.6090806@intel.com>
On 2/9/12 9:36 AM, "John Fastabend" <john.r.fastabend@intel•com> wrote:
> On 2/8/2012 8:36 PM, Stephen Hemminger wrote:
>> On Wed, 08 Feb 2012 19:22:06 -0800
>> John Fastabend <john.r.fastabend@intel•com> wrote:
>>
>>> Propagate software FDB table into hardware uc, mc lists when
>>> the NETIF_F_HW_FDB is set.
>>>
>>> This resolves the case below where an embedded switch is used
>>> in hardware to do inter-VF or VF-PF switching. This patch
>>> pushes the FDB entry (specifically the MAC address) into the
>>> embedded switch with dev_add_uc and dev_add_mc so the switch
>>> "learns" about the software bridge.
>>>
>>>
>>> veth0 veth2
>>> | |
>>> ------------
>>> | bridge0 | <---- software bridging
>>> ------------
>>> /
>>> /
>>> ethx.y ethx
>>> VF PF
>>> \ \ <---- propagate FDB entries to HW
>>> \ \
>>> --------------------
>>> | Embedded Bridge | <---- hardware offloaded switching
>>> --------------------
>>>
>>> This is only an RFC couple more changes are needed.
>>>
>>> (1) Optimize HW FDB set/del to only walk list if an FDB offloaded
>>> device is attached. Or decide it doesn't matter from unlikely()
>>> path.
>>>
>>> (2) Is it good enough to just call dev_uc_{add|del} or
>>> dev_mc_{add|del}? Or do some devices really need a new netdev
>>> callback to do this operation correctly. I think it should be
>>> good enough as is.
>>>
>>> (3) wrapped list walk in rcu_read_lock() just in case maybe every
>>> case is already inside rcu_read_lock()/unlock().
>>>
>>> Also this is in response to this thread regarding the macvlan and
>>> exposing rx filters posting now to see if folks think this is the
>>> right idea and if it will resolve at least the bridge case.
>>>
>>> http://lists.openwall.net/netdev/2011/11/08/135
>>>
>>> Signed-off-by: John Fastabend <john.r.fastabend@intel•com>
>>> ---
>>>
>>> include/linux/netdev_features.h | 2 ++
>>> net/bridge/br_fdb.c | 34 ++++++++++++++++++++++++++++++++++
>>> 2 files changed, 36 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/include/linux/netdev_features.h
>>> b/include/linux/netdev_features.h
>>> index 77f5202..5936fae 100644
>>
>> Rather than yet another device feature, I would rather use netlink_notifier
>> callback. The notifier is more general and generic without messing with
>> internals
>> of bridge.
>>
>
> But the device features makes it easy for user space to learn that the device
> supports this sort of offload. Now if all SR-IOV devices support this then it
> doesn't matter but I thought there were SR-IOV devices that didn't do any
> switching? I'll dig through the SR-IOV drivers to check there are not too
> many of them.
Correct. Our 802.1Qbh sriov device (enic) does not do local switching.
>
> By netlink_notifier do you mean adding a notifier_block and using
> atomic_notifier_call_chain()
> probably in rtnl_notify()? Then drivers could register with the notifier chain
> with
> atomic_notifier_chain_register() and receive the events correctly. Or did I
> miss
> some notifier chain that already exists?
>
> Thanks,
> John
>
next prev parent reply other threads:[~2012-02-10 13:45 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-09 3:22 [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware John Fastabend
2012-02-09 3:22 ` [RFC PATCH v0 2/2] ixgbe: add NETIF_F_HW_FDB to supported flags John Fastabend
2012-02-09 4:36 ` [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware Stephen Hemminger
2012-02-09 17:36 ` John Fastabend
2012-02-09 17:40 ` Stephen Hemminger
2012-02-09 17:52 ` John Fastabend
2012-02-09 21:11 ` jamal
2012-02-10 2:14 ` John Fastabend
2012-02-10 4:14 ` John Fastabend
2012-02-10 15:18 ` jamal
2012-02-10 16:39 ` Stephen Hemminger
2012-02-13 13:54 ` jamal
2012-02-13 15:13 ` John Fastabend
2012-02-14 13:18 ` jamal
2012-02-14 18:57 ` John Fastabend
2012-02-14 19:05 ` Stephen Hemminger
2012-02-14 19:08 ` John Fastabend
2012-02-15 14:10 ` Jamal Hadi Salim
2012-02-16 1:26 ` John Fastabend
2012-02-17 14:28 ` jamal
2012-02-17 17:10 ` John Fastabend
2012-02-18 12:41 ` jamal
2012-02-29 4:40 ` John Fastabend
2012-02-29 5:14 ` John Fastabend
2012-02-29 13:57 ` Jamal Hadi Salim
2012-02-29 13:56 ` Jamal Hadi Salim
2012-02-29 17:25 ` John Fastabend
2012-02-29 17:52 ` Stephen Hemminger
2012-02-29 18:19 ` John Fastabend
2012-03-01 13:36 ` Jamal Hadi Salim
2012-03-01 22:17 ` John Fastabend
2012-03-02 13:20 ` jamal
2012-03-05 17:00 ` Lennert Buytenhek
2012-03-01 13:24 ` Jamal Hadi Salim
2012-03-01 14:14 ` Michael S. Tsirkin
2012-03-01 22:10 ` John Fastabend
2012-03-05 16:53 ` Lennert Buytenhek
2012-03-06 3:45 ` John Fastabend
2012-03-06 14:15 ` Lennert Buytenhek
2012-03-06 13:42 ` jamal
2012-03-06 14:09 ` Lennert Buytenhek
2012-03-07 14:11 ` Jamal Hadi Salim
2012-03-12 8:48 ` Lennert Buytenhek
2012-03-13 13:52 ` Jamal Hadi Salim
2012-02-16 3:58 ` Ben Hutchings
2012-02-16 19:18 ` Shradha Shah
2012-02-17 14:37 ` jamal
2012-02-10 13:45 ` Roopa Prabhu [this message]
2012-02-09 18:14 ` Sridhar Samudrala
2012-02-09 20:30 ` John Fastabend
2012-02-10 0:39 ` Sridhar Samudrala
2012-02-10 0:51 ` John Fastabend
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=CB5A5F79.44211%roprabhu@cisco.com \
--to=roprabhu@cisco$(echo .)com \
--cc=bhutchings@solarflare$(echo .)com \
--cc=chrisw@redhat$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=gregory.v.rose@intel$(echo .)com \
--cc=john.r.fastabend@intel$(echo .)com \
--cc=kvm@vger$(echo .)kernel.org \
--cc=mst@redhat$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=shemminger@vyatta$(echo .)com \
--cc=sri@us$(echo .)ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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