[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+FuTSc4mhCMg5RJV08KGGsEw=4=Dy79wkaRQsKi2ipSqPx7KQ@mail.gmail.com>
Date: Mon, 10 Dec 2012 15:09:53 -0500
From: Willem de Bruijn <willemb@...gle.com>
To: David Miller <davem@...emloft.net>,
Ben Hutchings <bhutchings@...arflare.com>,
Rick Jones <rick.jones2@...com>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH net-next] rps: overflow prevention for saturated cpus
On Fri, Dec 7, 2012 at 2:20 PM, David Miller <davem@...emloft.net> wrote:
> From: Willem de Bruijn <willemb@...gle.com>
> Date: Thu, 6 Dec 2012 15:36:34 -0500
>
>> This patch maintains flow affinity in normal conditions, but
>> trades it for throughput when a cpu becomes saturated. Then, packets
>> destined to that cpu (only) are redirected to the lightest loaded cpu
>> in the rxqueue's rps_map. This breaks flow affinity under high load
>> for some flows, in favor of processing packets up to the capacity
>> of the complete rps_map cpuset in all circumstances.
>
> We specifically built-in very strict checks to make sure we never
> deliver packets out-of-order. Those mechanisms must be used and
> enforced in any change of this nature.
Okay. I'm working on a table-based revision to redirect flows consistently
when backlogged and to drop flows that are too big for any cpu to handle.
Revising and testing will take some time. If results are good, I'll post
a v2 soon. Thanks for all feedback so far.
Flow redirection when backlogged should improve resilience against
unbalanced load (such as synfloods) for all rps/rfs applications, not
just middleboxes. For that case, I'd like to be able to spray packets
instead of drop them when a single flow exceeds cpu capacity, but
that's a separate issue.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists