netdev - Re: [PATCH] Improved network performance by balancing Rx against other work

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: <877hp5rohj.wl%peterc@chubb.wattle.id.au>
Date:	Mon, 22 Mar 2010 15:04:24 +1100
From:	Peter Chubb <peter.chubb@...ta.com.au>
To:	David Miller <davem@...emloft.net>
Cc:	<peter.chubb@...ta.com.au>, <netdev@...r.kernel.org>
Subject: Re: [PATCH] Improved network performance by balancing Rx against other work

>>>>> "David" == David Miller <davem@...emloft.net> writes:

David> From: Peter Chubb <peter.chubb@...ta.com.au> Date: Wed, 17 Mar
David> 2010 13:55:58 +1100

>> The general approach is to restrict the work done in the Rx-side
>> processing to just 32 or so packets at a time then call
>> sys_sched_yield() to allow other system processing to get a look
>> in.  Currently, NAPI processing happens in soft IRQ context, and
>> much of it with interrupts off.

David> This is a deficiency in the locking done by such drivers.  Many
David> drivers lock properly and do not disable hardware interrupts
David> during NAPI processing.  Not only is this more efficient, it
David> also makes the driver more profilable.  For example, on cpus
David> with only timer based profiling everything done in NAPI context
David> can be seen.

Actually, the e1000 does not appear to disable interrupts during NAPI
processing.  However, softIRQ processing is still not being preempted
by a real-time process that wakes up.

The performance issue is not this, however, but the receive livelock problem
caused by too many packets being queued to higher layers --- more than
can be handled before the next interrupt causes more packets to be
batched up.  When the NAPI budget is consumed, but there are more packets
to handle, the NAPI layer currently reraises the softIRQ --- which
fires before anything else gets a go on the processor.

Anyway, if you think the e1000 driver is broken, I'll try with a
different one.  I had a look at the Broadcom tg3, but it looks too
hard to modify; so I'm now looking at the Realtek r8169 driver.  It
might take a few days.

PeterC
--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia
--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia
--
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