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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <36D9DB17C6DE9E40B059440DB8D95F520344439B@orsmsx418.amr.corp.intel.com>
Date:	Tue, 4 Sep 2007 09:12:09 -0700
From:	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>
To:	"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>,
	"Marc Sigler" <marc.sigler@...iatvcom.com>
Cc:	<netdev@...r.kernel.org>, <linux-net@...r.kernel.org>
Subject: RE: 82557/8/9 Ethernet Pro 100 interrupt mitigation support

Kok, Auke wrote:
> Marc Sigler wrote:
>> Hello everyone,
>> 
>> I have several systems with three integrated Intel 82559 (I *think*).
>> 
>> Does someone know if these boards support hardware interrupt
>> mitigation? I.e. is it possible to configure them to raise an IRQ
>> only if their hardware buffer is full OR if some given time (say 1
>> ms) has passed and packets are available in their hardware buffer.
>> 
>> I've been using the eepro100 driver up to now, but I'm about to try
>> the e100 driver. Would I have to use NAPI? Or is this an orthogonal
>> feature? 
> 
> the software developers manual for this part is available on our
> e1000.sf.net page here:
> 
>
http://downloads.sourceforge.net/e1000/OpenSDM_55x_10c.pdf?modtime=10400
83200&big_mirror=0
> 
> e100 hardware (as far as I can see from the specs) doesn't support
> any irq mitigation, so you'll need to run in NAPI mode if you want to
> throttle irq's. the in-kernel e100 already runs in NAPI mode, so
> that's already covered. 
> 
> beware that the eepro100 driver is scheduled for removal (2.6.25 or
> so). 

We support mitigation of interrupts in a downloadable microcode on only
a few pieces of hardware (revision id specific) in e100.c (see
e100_setup_ucode)

If you really really wanted mitigation you could probably backport the
microcode from the e100 driver in the 2.4.35 kernel for your specific
hardware.  This driver is versioned 2.X.

Beyond that I can't really offer much help in this case, but would
certainly accept patches!

Jesse
-
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