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

- From: jamal \<hidden\>
- Date: 2012-02-17 14:37:50 
- List: netdev
- Page: https://ratatoskr.run/netdev/2012/02/10888991
- Thread: https://ratatoskr.run/netdev/2012/02/10888296/t.md

```text
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

```