From: Shradha Shah <sshah@solarflare•com>
To: Ben Hutchings <bhutchings@solarflare•com>
Cc: <jhs@mojatatu•com>, John Fastabend <john.r.fastabend@intel•com>,
Stephen Hemminger <shemminger@vyatta•com>, <roprabhu@cisco•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: Thu, 16 Feb 2012 19:18:57 +0000 [thread overview]
Message-ID: <4F3D56A1.3030502@solarflare.com> (raw)
In-Reply-To: <1329364728.3048.159.camel@deadeye>
Hello,
Please find my comments inline.
Regards,
Shradha Shah
On 02/16/2012 03:58 AM, Ben Hutchings wrote:
> [I'm just catching up with this after getting my own driver changes into
> shape.]
>
> On Fri, 2012-02-10 at 10:18 -0500, jamal wrote:
>> Hi John,
>>
>> I went backwards to summarize at the top after going through your email.
>>
>> TL;DR version 0.1:
>> you provide a good use case where it makes sense to do things in the
>> kernel. IMO, you could make the same arguement if your embedded switch
>> could do ACLs, IPv4 forwarding etc. And the kernel bloats.
>> I am always bigoted to move all policy control to user space instead of
>> bloating in the kernel.
> [...]
>>> Now here is the potential issue,
>>>
>>> (G) The frame transmitted from ethx.y with the destination address of
>>> veth0 but the embedded switch is not a learning switch. If the FDB
>>> update is done in user space its possible (likely?) that the FDB
>>> entry for veth0 has not been added to the embedded switch yet.
>>
>> Ok, got it - so the catch here is the switch is not capable of learning.
>> I think this depends on where learning is done. Your intent is to
>> use the S/W bridge as something that does the learning for you i.e in
>> the kernel. This makes the s/w bridge part of MUST-have-for-this-to-run.
>> And that maybe the case for your use case.
> [...]
>
> Well, in addition, there are SR-IOV network adapters that don't have any
> bridge. For these, the software bridge is necessary to handle
> multicast, broadcast and forwarding between local ports, not only to do
> learning.
>
> Solarflare's implementation of accelerated guest networking (which
> Shradha and I are gradually sending upstream) builds on libvirt's
> existing support for software bridges and assigns VFs to guests as a
> means to offload some of the forwarding.
I am also trying to work with bridging using macvtap. Libvirt supports
macvtap in four modes; vepa, bridge, private and passthrough mode.
Macvtap used in the bridge mode will work similar to a software bridge and
will improve performance.
>
> If and when we implement a hardware bridge, we would probably still want
> to keep the software bridge as a fallback. If a guest is dependent on a
> VF that's connected to a hardware bridge, it becomes impossible or at
> least very disruptive to migrate it to another host that doesn't have a
> compatible VF available.
>
> Ben.
>
next prev parent reply other threads:[~2012-02-16 19:18 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 [this message]
2012-02-17 14:37 ` jamal
2012-02-10 13:45 ` Roopa Prabhu
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=4F3D56A1.3030502@solarflare.com \
--to=sshah@solarflare$(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=jhs@mojatatu$(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=roprabhu@cisco$(echo .)com \
--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