[ovs-dev] [PATCH] bridge: Eject NORMAL flows from datapath after bridge flush.

Ben Pfaff blp at nicira.com
Thu Oct 22 18:45:15 UTC 2009

Jesse Gross <jesse at nicira.com> writes:

> Ben Pfaff wrote:
>> Jesse Gross <jesse at nicira.com> writes:
>>> During a bridge flush we clear the learning table and revalidate all
>>> flows.  When revalidating NORMAL flows we consult the empty learning
>>> table and install flows that flood packets.  This means that existing
>>> flows can continue as is but flooding packets because we don't learn
>>> the MAC addresses as the flows never come to userspace.  The problem
>>> is worse with bonding because we can receive one of the flooded
>>> packets back on a bond slave and learn that port, causing us to send
>>> traffic to the wrong location.
>> This seems like a reasonable stopgap.  We have the opportunity to
>> do better:
>>         - We shouldn't need to flush the bridge in so many cases.
> I'm not sure that it is ever necessary to explicitly flush the
> learning table though clearly there are several configuration changes
> that require revalidation of flows.  The only situation that I can
> think of where the learning table would be important is if a VM
> migrates, in which case it should send a gratuitous ARP to update the
> learning table.

First, some history.  I introduced bridge_flush() to deal with
two kinds of situations.  The first is simply when we need to
re-validate every flow.  We can't do that by setting the
revalidate tag-set to all-1-bits, because some flows might not
have any tags.  I don't think that is the problem here.

The second situation is when the topology of the network changes
in some significant way, for example when a port is deleted or
the VLAN of a port is changed.  That kind of change has a major
effect on the MAC learning table.  Either we have to write code
for updating the learning table to deal with these cases (I'm not
sure that's a good idea except possibly in very simple cases--it
would be difficult to test) or we have to flush (some?) of the
learning table.  

It really is important to flush entries of ports that change in
an important way or that get deleted.  If a port disappears then
you want to flood packets that were being switched to it so that
you can find where that MAC is now.  So we need some solution; I
do think that we can do better than we do now.

>>         - We ought to feed flow stats back into the learning
>>           table.
> This is definitely important, though at this point I think that it's
> going to have to wait for the future.  

I don't think it would be too hard.  Have you taken a look at how
it would be implemented?

> In the meantime, I realized that this patch should be
> generalized a little bit to eject flows that are being
> revalidated without a learning table entry.  Since flows can be
> revalidated at essentially any time, this will prevent bad
> things from happening to flows with an expired learning entry.
> I'm going to push this version of the patch to hold us over
> until we have time for the larger changes.


More information about the dev mailing list