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
| ||
|
Message-ID: <1272714179.2230.151.camel@edumazet-laptop> Date: Sat, 01 May 2010 13:42:59 +0200 From: Eric Dumazet <eric.dumazet@...il.com> To: hadi@...erus.ca Cc: Changli Gao <xiaosuo@...il.com>, David Miller <davem@...emloft.net>, therbert@...gle.com, shemminger@...tta.com, netdev@...r.kernel.org, Eilon Greenstein <eilong@...adcom.com>, Brian Bloniarz <bmb@...enacr.com> Subject: Re: [PATCH net-next-2.6] net: speedup udp receive path Le samedi 01 mai 2010 à 07:23 -0400, jamal a écrit : > On Sat, 2010-05-01 at 07:57 +0200, Eric Dumazet wrote: > > > I changed your program a bit to use EV_PERSIST, (to avoid epoll_ctl() > > overhead for each packet...) > > Thats a different test case then ;-> You can also get rid of the timer > (I doubt it will show much difference in results) - I have it in there > because it i am trying to replicate what i saw causing the regression. > > > RPS off : 220.000 pps > > > > RPS on (ee mask) : 700.000 pps (with a slightly modified tg3 driver) > > 96% of delivered packets > > > > That's a very very huge gap. What were the numbers before you changed to > EV_PERSIST? But, whole point of epoll is to not change interest each time you get an event. Without EV_PERSIST, you need two more syscalls per recvfrom() epoll_wait() epoll_ctl(REMOVE) epoll_ctl(ADD) recvfrom() Even poll() would be faster in your case poll(one fd) recvfrom() > Note: i did not add any of your other patches for dst refcnt, sockets > etc. Were you running with those patches in these tests? I will try the > next opportunity i get to have latest kernel + those patches. > > > This is on tg3 adapter, and tg3 has copybreak feature : small packets > > are copied into skb of the right size. > > Ok, so the driver tuning is also important then (and it shows in the > profile). I always thought copybreak was borderline... It can help to reduce memory footprint (allocating 128 bytes instead of 2048/4096 bytes per frame), but with RPS, it would make sense to perform copybreak after RPS, not before. Reducing memory footprint also means less changes on udp_memory_allocated /tcp_memory_allocate (memory reclaim logic) -- 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