[ovs-dev] [loops 6/6] datapath: Detect and suppress flows that are implicated in loops.

Jesse Gross jesse at nicira.com
Tue Jul 27 20:13:43 UTC 2010


On Tue, Jul 27, 2010 at 11:27 AM, Ben Pfaff <blp at nicira.com> wrote:

> On Tue, Jul 27, 2010 at 10:23:35AM -0700, Ben Pfaff wrote:
> > At least as much as review of the implementation (which you did better
> > than I did on the implementation), I was also looking for an opinion
> > whether you think that this is a good way to solve the problem.  Do you?
>
> I just noticed that everything is simplified slightly if we do the loop
> counting and checking in dp_process_received_packet() or
> execute_actions() instead of vport_send().  I think that this is
> equivalent, since every vport_send() occurs via these functions (or
> close enough).  Plus, we'd do fewer checks total in the common case,
> since they'd happen once per datapath traversal instead of once per
> output port.
>
> What do you think of that idea?
>

That sounds like a good idea to me - dp_process_received_packet() probably
makes more sense than execute_actions().

As far as the general merits of the approach, I'm somewhat on the fence.  In
general, it doesn't thrill me simply because I don't like the idea of having
runtime loop detection in general and this makes it slightly more expensive.
 I do think the idea of shutting down the flow is a good one.  One question
that occurs to me is whether is worth doing the extra common case work to
shutdown the root flow, instead of just the one in which the loop is
detected (in many cases it will probably be the same).  The extra work is
pretty minimal though, so it is probably fine.

Do we actually need to keep track of max_count?  Is it possible to just set
a flag when the loop detection is triggered and avoid one of the extra
branches?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20100727/30a893a6/attachment-0003.html>


More information about the dev mailing list