[ovs-dev] [PATCH 1/2] datapath: Add loop checking.
jesse at nicira.com
Tue Jul 13 13:44:01 PDT 2010
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...
More information about the dev