lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ