netdev - Re: [PATCH net-next] rps: overflow prevention for saturated cpus

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <50C12E22.3030206@hp.com>
Date:	Thu, 06 Dec 2012 15:45:38 -0800
From:	Rick Jones <rick.jones2@...com>
To:	Willem de Bruijn <willemb@...gle.com>
CC:	netdev@...r.kernel.org, David Miller <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Tom Herbert <therbert@...gle.com>
Subject: Re: [PATCH net-next] rps: overflow prevention for saturated cpus

On 12/06/2012 03:04 PM, Willem de Bruijn wrote:
> On Thu, Dec 6, 2012 at 5:25 PM, Rick Jones <rick.jones2@...com> wrote:
>> I thought (one of) the ideas behind RFS at least was to give the CPU
>> scheduler control over where network processing took place instead of it
>> being dictated solely by the addressing. I would have expected the CPU
>> scheduler to migrate some work off the saturated CPU.  Or will this only
>> affect RPS and not RFS?
>
> I wrote it with RPS in mind, indeed. With RFS, for sufficiently
> multithreaded applications that are unpinned, the scheduler will
> likely spread the threads across as many cpus as possible. In that
> case, the mechanism will not kick in, or as quickly. Even with RFS,
> pinned threads and single-threaded applications will likely also
> benefit during high load from redirecting kernel receive
> processing away from the cpu that runs the application thread. I
> haven't tested that case independently.

Unless that single-threaded application (or single receiving thread) is 
pinned to a CPU, isn't there a non-trivial chance that incoming traffic 
flowing up different CPUs will cause it to be bounced from one CPU to 
another, taking its cache lines with it and not just the "intra-stack" 
cache lines?

Long (?) ago and far away it was possible to say that a given IRQ should 
be potentially serviced by more than one CPU (if I recall though not 
phrase correctly).  Didn't that get taken away because it did such nasty 
things like reordering and such?  (Admittedly, I'm really stretching the 
limits of my dimm memory there)

>> What kind of workload is this targeting that calls for
>> such intra-flow parallelism?
>
> Packet processing middeboxes that rather operate in degraded mode
> (reordering) than drop packets. Intrusion detection systems and proxies,
> for instance. These boxes are actually likely to have RPS enabled and
> RFS disabled.
>
>> With respect to the examples given, what happens when it is TCP traffic
>> rather than UDP?
>
> That should be identical. RFS is supported for both protocols. In the
> test, it is turned off to demonstrate the effect solely with RPS.

Will it be identical with TCP?  If anything, I would think causing 
reordering of the TCP segments within flows would only further increase 
the workload of the middlebox because it will increase the ACK rates. 
Perhaps quite significantly if GRO was effective at the receivers before 
the reordering started.

At least unless/until the reordering is bad enough to cause the sending 
TCPs to fast retransmit and so throttle back.  And unless we are talking 
about being overloaded by massive herds of "mice" I'd think that the TCP 
flows would be throttling back to what the single CPU in the middlebox 
could handle.

rick
--
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