[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1416005912.17262.76.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Fri, 14 Nov 2014 14:58:32 -0800
From: Eric Dumazet <eric.dumazet@...il.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Tom Herbert <therbert@...gle.com>,
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 14:27 -0800, Andy Lutomirski wrote:
> The people at the other end will be really pissed if that results in
> lots of reconnections.
No reconnections necessary.
I believe you misunderstood : On the 4-tuple (SADDR,SPORT,DADDR,DPORT),
you can pick for example SPORT so that hash(SADDR,SPORT,DADDR,DPORT)
maps to a known and wanted RX queue number.
Once you know that, you use bind(SADDR, SPORT), then
connect(DADDR,DPORT).
Anyway, if your hardware is able to cope with the few number of flows,
just use the hardware and be happy.
Here we want about 10 millions sockets, there is little hope for
hardware being helpful.
--
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