netdev - Re: [PATCH v10 net-next 0/6] net: low latency Ethernet device polling

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51B6EDE8.7020009@linux.intel.com>
Date:	Tue, 11 Jun 2013 12:29:12 +0300
From:	Eliezer Tamir <eliezer.tamir@...ux.intel.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	David Miller <davem@...emloft.net>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, jesse.brandeburg@...el.com,
	donald.c.skidmore@...el.com, e1000-devel@...ts.sourceforge.net,
	willemb@...gle.com, bhutchings@...arflare.com, andi@...stfloor.org,
	hpa@...or.com, eilong@...adcom.com, or.gerlitz@...il.com,
	amirv@...lanox.com, eliezer@...ir.org.il
Subject: Re: [PATCH v10 net-next 0/6] net: low latency Ethernet device polling

On 11/06/2013 10:32, Eric Dumazet wrote:
> On Tue, 2013-06-11 at 09:49 +0300, Eliezer Tamir wrote:
>
>> I would like to hear opinions on what needs to be added to make this
>> feature complete.
>>
>> The list I have so far is:
>> 1. add a socket option
>
> Yes, please. I do not believe all sockets on the machine are candidate
> for low latency. In fact very few of them should be, depending on the
> number of cpu and/or RX queues.

I have a patch for that, along a patch for sockperf I will use for
testing.
One I will test it some more, I will send it in.

>> 3. support for epoll
>
> For this one, I honestly do not know how to proceed.
>
> epoll Edge Trigger model is driven by the wakeups events.
>
> The wakeups come from frames being delivered by the NIC (for UDP/TCP
> sockets)
>
> If epoll_wait() has to scan the list of epitem to be able to perform the
> llpoll callback, it will be too slow : We come back to poll() model,
> with O(N) execution time.
>
> Ideally we would have to callback llpoll not from the tcp_poll(), but
> right before putting current thread in wait mode.

We have a few ideas, I will do a POC and see if any of them actually
work.

One thing that would really help is information about use-cases that
people care about:

Number and type of sockets, how active are they.
How many active Ethernet ports are there.
Can bulk and low latency traffic be steered to separate cores or
separated in any other way.

Thanks,
Eliezer
--
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