82557/8/9 Ethernet Pro 100 interrupt mitigation support

82557/8/9 Ethernet Pro 100 interrupt mitigation support

[John Sigler]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

(Please ignore previous message, it was sent from the wrong account.)

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?

Regards.


[-- Attachment #2: adlink.lspci --]
[-- Type: text/plain, Size: 2331 bytes --]

00:08.0 Ethernet controller: Intel Corporation 82557/8/9 Ethernet Pro 100 (rev 08)
	Subsystem: Intel Corporation EtherExpress PRO/100B (TX)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at e6400000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at d800 [size=64]
	Region 2: Memory at e6100000 (32-bit, non-prefetchable) [size=1M]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=2 PME-

00:09.0 Ethernet controller: Intel Corporation 82557/8/9 Ethernet Pro 100 (rev 08)
	Subsystem: Intel Corporation EtherExpress PRO/100B (TX)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at e6403000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at dc00 [size=64]
	Region 2: Memory at e6200000 (32-bit, non-prefetchable) [size=1M]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=2 PME-

00:0a.0 Ethernet controller: Intel Corporation 82557/8/9 Ethernet Pro 100 (rev 08)
	Subsystem: Intel Corporation EtherExpress PRO/100B (TX)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 12
	Region 0: Memory at e6402000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at e000 [size=64]
	Region 2: Memory at e6000000 (32-bit, non-prefetchable) [size=1M]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=2 PME-

Re: 82557/8/9 Ethernet Pro 100 interrupt mitigation support

[John Sigler]

John Sigler wrote:

> 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?
> 
> 00:08.0 Ethernet controller: Intel Corporation 82557/8/9 Ethernet Pro 100 (rev 08)
> 	Subsystem: Intel Corporation EtherExpress PRO/100B (TX)
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 32 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
> 	Interrupt: pin A routed to IRQ 10
> 	Region 0: Memory at e6400000 (32-bit, non-prefetchable) [size=4K]
> 	Region 1: I/O ports at d800 [size=64]
> 	Region 2: Memory at e6100000 (32-bit, non-prefetchable) [size=1M]
> 	Capabilities: [dc] Power Management version 2
> 		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
> 		Status: D0 PME-Enable- DSel=0 DScale=2 PME-
> 
> 00:09.0 Ethernet controller: Intel Corporation 82557/8/9 Ethernet Pro 100 (rev 08)
> 	Subsystem: Intel Corporation EtherExpress PRO/100B (TX)
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 32 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
> 	Interrupt: pin A routed to IRQ 11
> 	Region 0: Memory at e6403000 (32-bit, non-prefetchable) [size=4K]
> 	Region 1: I/O ports at dc00 [size=64]
> 	Region 2: Memory at e6200000 (32-bit, non-prefetchable) [size=1M]
> 	Capabilities: [dc] Power Management version 2
> 		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
> 		Status: D0 PME-Enable- DSel=0 DScale=2 PME-
> 
> 00:0a.0 Ethernet controller: Intel Corporation 82557/8/9 Ethernet Pro 100 (rev 08)
> 	Subsystem: Intel Corporation EtherExpress PRO/100B (TX)
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 32 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
> 	Interrupt: pin A routed to IRQ 12
> 	Region 0: Memory at e6402000 (32-bit, non-prefetchable) [size=4K]
> 	Region 1: I/O ports at e000 [size=64]
> 	Region 2: Memory at e6000000 (32-bit, non-prefetchable) [size=1M]
> 	Capabilities: [dc] Power Management version 2
> 		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
> 		Status: D0 PME-Enable- DSel=0 DScale=2 PME-

Here is Intel's page for the 82559:
http://www.intel.com/design/network/products/lan/controllers/82559.htm

The "82559ER Fast Ethernet PCI Controller" data sheet mentions a 3 KB 
receive FIFO. I suppose that's too small to aggregate several frames?

The "8255x Controller Family Open Source Software Developer Manual" 
mentions the features supported by the 82559. I don't see anything 
related to interrupt mitigation support.

Does NAPI work well when there is no hardware interrupt mitigation support?

Regards.

Re: 82557/8/9 Ethernet Pro 100 interrupt mitigation support

[James Chapman]

John 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?

82558/9 hardware does, sort of. But the e100 driver doesn't use it 
because it uses NAPI to minimize rx & tx interrupts.

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

Use NAPI. The e100 driver has been NAPI-only for a while.

-- 
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development

82557/8/9 Ethernet Pro 100 interrupt mitigation support

[Marc Sigler]

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

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?

Regards.

[-- Attachment #2: adlink.lspci --]
[-- Type: text/plain, Size: 2330 bytes --]

00:08.0 Ethernet controller: Intel Corporation 82557/8/9 Ethernet Pro 100 (rev 08)
	Subsystem: Intel Corporation EtherExpress PRO/100B (TX)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at e6400000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at d800 [size=64]
	Region 2: Memory at e6100000 (32-bit, non-prefetchable) [size=1M]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=2 PME-

00:09.0 Ethernet controller: Intel Corporation 82557/8/9 Ethernet Pro 100 (rev 08)
	Subsystem: Intel Corporation EtherExpress PRO/100B (TX)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at e6403000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at dc00 [size=64]
	Region 2: Memory at e6200000 (32-bit, non-prefetchable) [size=1M]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=2 PME-

00:0a.0 Ethernet controller: Intel Corporation 82557/8/9 Ethernet Pro 100 (rev 08)
	Subsystem: Intel Corporation EtherExpress PRO/100B (TX)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 12
	Region 0: Memory at e6402000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at e000 [size=64]
	Region 2: Memory at e6000000 (32-bit, non-prefetchable) [size=1M]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=2 PME-

Re: 82557/8/9 Ethernet Pro 100 interrupt mitigation support

[Kok, Auke]

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=1040083200&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).

Cheers,

Auke

RE: 82557/8/9 Ethernet Pro 100 interrupt mitigation support

[Brandeburg, Jesse]

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

Re: 82557/8/9 Ethernet Pro 100 interrupt mitigation support

[John Sigler]

Jesse Brandeburg wrote:

> Auke Kok wrote:
> 
>> Marc Sigler wrote:
>> 
>>> 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? 
>> 
>> 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)

http://lxr.linux.no/source/drivers/net/e100.c#L1176

OK.

How do I tell which revision id I have?

00:08.0 0200: 8086:1229 (rev 08)
00:09.0 0200: 8086:1229 (rev 08)
00:0a.0 0200: 8086:1229 (rev 08)

How much memory is available on the board to bundle packets? 3000 bytes?

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

I forgot to mention I'm running 2.6.22.1-rt9.
I'm not sure why you mention 2.4.35?
The problem with e100 is that it fails to properly set up all three 
interfaces, which is why I'm stuck with eepro100.

Regards.

RE: 82557/8/9 Ethernet Pro 100 interrupt mitigation support

[Brandeburg, Jesse]

John Sigler wrote:
> Jesse Brandeburg wrote:
> 
>> Auke Kok wrote:
>> 
>>> Marc Sigler wrote:
>>> 
>>>> 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?
>>> 
>>> 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)
> 
> http://lxr.linux.no/source/drivers/net/e100.c#L1176
> 
> OK.
> 
> How do I tell which revision id I have?
> 
> 00:08.0 0200: 8086:1229 (rev 08)
> 00:09.0 0200: 8086:1229 (rev 08)
> 00:0a.0 0200: 8086:1229 (rev 08)
                           ^^^^^^ 
rev 8

> How much memory is available on the board to bundle packets? 3000
> bytes? 

yes, well, 3kB.  I don't remember if the chip actually bundles
interrupts after the dma complets or pends the dma while delaying the
interrupt (I would guess it is the former)

>> 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.
> 
> I forgot to mention I'm running 2.6.22.1-rt9.
> I'm not sure why you mention 2.4.35?

because 2.4.35 has the "old" e100 driver from Intel, which has all sorts
of support (and all sorts of complexity) for offloading and interrupt
bundling, etc.

> The problem with e100 is that it fails to properly set up all three
> interfaces, which is why I'm stuck with eepro100.

I remember working with you on this, but we left the issue with no
solution because it appears your hardware has some specific issue with
strange eeprom timings that we cannot reproduce.

you can try loading the ucode (that matches your revision id) using
eepro100.

Jesse