[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