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

Jesse Gross jesse at nicira.com
Thu Oct 22 20:02:43 UTC 2009

Ben Pfaff wrote:
> Jesse Gross <jesse at nicira.com> writes:
>> 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.

I agree, this part isn't a problem.

> 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 could flush the entries for a port/vlan if it changes or is deleted.  
It seems like that wouldn't overly complicate things.  However, the 
physical switches in a virtualized environment also have this problem 
and they have essentially no information about migrations or other 
configuration changes.  The are completely dependent on the broadcast 
ARP after a migration to reset their learning tables.  I'm not saying 
that we can't do better to make the process more robust but flushing the 
table doesn't seem to be strictly necessary.

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

I don't think it would be too hard either but I just think we have too 
much to do right now and I don't want to introduce additional code 
churn.  I filed a high priority feature request (#2209) so we should get 
to this in the near future.

More information about the dev mailing list