Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware

[jamal <hadi@cyberus.ca>]

On Thu, 2012-02-16 at 03:58 +0000, Ben Hutchings wrote:

> 
> 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.

For the scenario where there is no h/w bridge - the s/ware bridge should
be usable. There's no way working around that.
My contention is only with the case where there is a h/w bridge and
there being two FDB tables; one in hardware and another in s/w.
And both the h/w and s/w bridges doing flooding and learning.
It is desirable to have options to use one or other or both with
some synchronization.

> 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.
> 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.

In the scheme i described to John in last email, libvirt needs not be aware of 
existence of hardware offloading (and migration should be transparent of whether
h/w bridge exists or not)...

cheers,
jamal