netdev - Re: [PATCH net-next] net: introduce SO_INCOMING

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: <1415993614.17262.55.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Fri, 14 Nov 2014 11:33:34 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Michael Kerrisk <mtk.manpages@...il.com>,
	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>, Ying Cai <ycai@...gle.com>,
	Willem de Bruijn <willemb@...gle.com>,
	Neal Cardwell <ncardwell@...gle.com>,
	Linux API <linux-api@...r.kernel.org>
Subject: Re: [PATCH net-next] net: introduce SO_INCOMING_CPU

On Fri, 2014-11-14 at 09:17 -0800, Andy Lutomirski wrote:

> As a heavy user of RFS (and finder of bugs in it, too), here's my
> question about this API:
> 
> How does an application tell whether the socket represents a
> non-actively-steered flow?  If the flow is subject to RFS, then moving
> the application handling to the socket's CPU seems problematic, as the
> socket's CPU might move as well.  The current implementation in this
> patch seems to tell me which CPU the most recent packet came in on,
> which is not necessarily very useful.

Its the cpu that hit the TCP stack, bringing dozens of cache lines in
its cache. This is all that matters,

> 
> Some possibilities:
> 
> 1. Let SO_INCOMING_CPU fail if RFS or RPS are in play.

Well, idea is to not use RFS at all. Otherwise, it is useless.

RFS is the other way around : You want the flow to follow your thread.

RPS wont be a problem if you have sensible RPS settings.

> 
> 2. Change the interface a bit to report the socket's preferred CPU
> (where it would go without RFS, for example) and then let the
> application use setsockopt to tell the socket to stay put (i.e. turn
> off RFS and RPS for that flow).
> 
> 3. Report the preferred CPU as in (2) but let the application ask for
> something different.
> 
> For example, I have flows for which I know which CPU I want.  A nice
> API to put the flow there would be quite useful.
> 
> 
> Also, it may be worth changing the naming to indicate that these are
> about the rx cpu (they are, right?).  For some applications (sparse,
> low-latency flows, for example), it can be useful to keep the tx
> completion handling on a different CPU.

SO_INCOMING_CPU is rx, like incoming ;)


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