Subject: Re: [PATCH RFC 0/7] Non-promisc bidge ports support

From: "Michael S. Tsirkin" <[email-masked]>
Date: Thu, 27 Feb 2014 09:20:06 +0200

On Wed, Feb 26, 2014 at 06:59:29PM -0500, Jamal Hadi Salim wrote:
> On 02/26/14 10:18, Vlad Yasevich wrote:
> >This patch series is a complete re-design and re-implementation of
> >prior attempts to support non-promiscuous bridge ports.
> >
> >The basic design is as follows.  The bridge keeps track of
> >all the ports that flood packets to unknown destinations.  If
> >the flooding is disabled on the port, to get traffic to flow
> >through, user/management would need to add an fdb describing
> >such traffic.  When such fdb is added, we save the address
> >to bridge private hardware address list.
> 
> Entering the addresses in the uc list on other bridgeports seems
> reasonable for the scenario described.
> But would it _also_ need to be added to the fdb of the bridge?
> i.e how does the bridge (if the packet was to be handed to it)
> know where to forward?
> BTW: on the comment that flooding off implies learning off: I would like
> to be able to turn off flooding on a specific bridge port but
> still want to learn from it. I dont think those two are mutually
> exclusive.
> 
> cheers,
> jamal

I agree.

It seems a reasonable tradeoff to limit any specific
optimization to !flood && !learn if this simplifies the
implementation significantly and if everything works
as it did before even with learning on.

-- 
MST