[ovs-dev] [PATCH 03/12] odp-util: Bump up maximum number of ODP actions.
jesse at nicira.com
Tue Dec 7 12:59:01 PST 2010
On Tue, Dec 7, 2010 at 12:17 PM, Ben Pfaff <blp at nicira.com> wrote:
> On Tue, Dec 07, 2010 at 11:34:38AM -0800, Jesse Gross wrote:
>> On Tue, Dec 7, 2010 at 11:00 AM, Ben Pfaff <blp at nicira.com> wrote:
>> > The kernel supports more than a single page of actions now, so userspace
>> > should be able to take advantage of this.
>> > Upcoming commits will completely replace this data structure but this
>> > commit makes the bug fix clear and is suitable for cherry-picking to
>> > long-term support branches.
>> MAX_ODP_ACTIONS isn't just a theoretical maximum - it's an array size
>> in "struct odp_actions". So every time that we use it, we end up
>> putting 16 pages on the stack. That doesn't seem like a great idea to
>> me. It's also overkill: the kernel only allows a maximum of 2 * the
>> maximum number of ports. At 1024 ports and 8 bytes per action, that's
>> a maximum of 16k that we could usefully use.
> I don't see why we should care about 64 kB on the stack. It's just a
> single "subl $65536, %esp" instruction. The stack is both paged and
> growable. And we never have more than one of these things on the stack
> at once, and we only have one thread.
Sure, it's OK on Linux. I was thinking about less flexible platforms
though, like an embedded system on a switch.
> But I'll happily reduce the 64 kB to 16 kB. For now I've applied that
> The upcoming patches change the actions to be dynamically allocated
> using struct ofpbuf.
OK, that's fine. In the future, we won't use this and we don't
currently run on any platform except for Linux.
>> I know that we had to bump up the number of actions in the kernel to
>> handle flooding on large numbers of ports. So in reality, it looks
>> like it was just wrapping around the array and overwriting some of the
>> earlier ports?
> Yes. This didn't go up to the kernel, though: the overwrites get
> detected in xlate_actions(), recorded, and the flow setup is aborted.
> So those packets would get dropped, I guess, until the MAC address was
Hmm, that does appear to be what's happening. However, I thought that
the kernel changes fixed at least some errors, so some flows must have
More information about the dev