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  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]
Date:	Sun, 21 Mar 2010 20:21:59 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	peter.chubb@...ta.com.au
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] Improved network performance by balancing Rx against
 other work

From: Peter Chubb <peter.chubb@...ta.com.au>
Date: Wed, 17 Mar 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.

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

> In addition, because so much runs with interrupts disabled,
> real-time performance sucks.

Please respin your analysis to be done with a sane driver, one that
does not disable hardware interrupts.  Doing so is a driver, rather
than a fundamental, issue of NAPI.

Avoiding hardware interrupt disabling also has another huge benefit,
it means that the transmit path of the driver need not disable
hardware interrupts either since that already runs in software
interrupt disabled context.

Your analysis was essentially done with broken driver(s), so I think
I can stop reading here.
--
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