[ovs-dev] [PATCH 1/2] datapath: Add loop checking.

[Jesse Gross]

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

> On Mon, Jul 12, 2010 at 02:31:16PM -0700, Jesse Gross wrote:
> > New types of vports such as patch and GRE make it possible to
> > connect multiple (or the same) datapaths together, which introduces
> > the possibility of loops on a single machine.  Local loops are
> > even worse than network loops because they will quickly crash the
> > machine once the kernel stack is exhausted.  This adds loop
> > checking within the OVS datapath that will drop packets that have
> > been seen more than 5 times.
>
> I'd be tempted to use local atomic operations (see
> Documentation/local_ops.txt) instead of separate interrupt and
> non-interrupt counters to maintain the counts.  They seem tailor-made
> for the purpose.  Did you consider them?
>

They don't really address the issue in this case.  These operations ensure
that modifying the counters are atomic with respect to interrupts (on x86
they are anyways) but I actually want independent counters: imagine that you
have one packet that has looped 5 times and then another one comes in on an
interrupt; since they share a counter that second packet will get dropped
immediately.  This means that the stack depth is potentially twice what we
specify as the limit but at least it is deterministic for a given packet.


>
> Have you done any kind of analysis or reasoning to figure out the amount
> of stack required by 5-deep recursion?
>

Nothing particularly scientific.  If we assume worst case that the kernel
has 4k stacks enabled and we are at our max recursion depth in both
interrupt and non-interrupt context, that leaves us about 400 bytes per
round trip.  That's definitely fine for patch ports; GRE is  worse due to
the IP stack.  I think it is probably fine but there is always a potential
for some kind of long and twisted path.  If we want an extra margin we could
lower it to 3 - that's what we're currently using - and should be plenty for
all sane use cases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/dev/attachments/20100713/df55be8b/attachment.htm>