Is interrupt priority supported ?

Is interrupt priority supported ?

[Jose Luis Marchetti]

Hi,

I am experiencing serial (115K) data loss when I have concurrent heavy Ethernet traffic. I have added some basic trace into the UART driver and could confirm the Ethernet data interrupt, if with enough data and happening in the right place would cause the UART FIFO to fill.
BTW this is happening on a embedded processor, not on the usual ( and fast ) PC.
Then I tried to set the serial interrupt priority to be higher than the Ethernet interrupt priority, just because the UART I am using have just 4 bytes of FIFO while the Ethernet have thousands...

But I am not able to find where this is done in Linux, is interrupt priority supported at all ?

Thanks in advance for any comments,

José Luís Marchetti


      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

Re: Is interrupt priority supported ?

[Andreas Mohr]

Hi,

it has been for a looong time (those things tend to almost get outdated already -
witness the floppy controller misery):

# apt-cache show hwtools
Package: hwtools
Status: install ok installed
Priority: optional
Section: utils
Installed-Size: 312
Maintainer: Pierre Ancelot <eternityos@free.fr>
Architecture: i386
Version: 0.8-5.1
Depends: debconf, libc6 (>= 2.3.5-1)
Suggests: sysutils, hdparm, scsitools, memtest86
Conffiles:
 /etc/init.d/hwtools 137e3fbdc26d90bec745a36d1ffd8661
Description: collection of tools for low-level hardware management
 This package is a collection of tools useful for hardware
 troubleshooting and optimization (for ix86 machines):
 .
  irqtune: adjusts priority of interrupts (improves serial performance),
  scanport: scans for hardware not already handled by Linux drivers,
  memmxtest: a real mode memory test, with MMX support.  You may want
  to look at package memtest86 as well.
  qic-02 driver and configuration utilities. Adds the qic-02 tapes support
 .
 Be aware that these tools require some knowledge of what are they
 doing to be used properly, otherwise they may cause damage to your system.
 .
 Some programs that were previously part of this package have been
 moved to their own packages (hdparm, scsitools, memtest86)





I don't have any recent experience with irqtune myself, though, and I cannot
authoritatively state that it actually works at the moment,
but I'd be relatively surprised if it didn't.

You might want to enable some unfortunately often still default-disabled
hardware transceiver offloading of Ethernet frames, too, via ethtool -k or so,
to possibly reduce latency.

Plus PCI latency timings, via setpci or so (but that probably won't
matter).

HTHHAND,

Andreas Mohr

Re: Is interrupt priority supported ?

[Robert Hancock]

Jose Luis Marchetti wrote:
> Hi,
> 
> I am experiencing serial (115K) data loss when I have concurrent heavy Ethernet traffic. I have added some basic trace into the UART driver and could confirm the Ethernet data interrupt, if with enough data and happening in the right place would cause the UART FIFO to fill.
> BTW this is happening on a embedded processor, not on the usual ( and fast ) PC.
> Then I tried to set the serial interrupt priority to be higher than the Ethernet interrupt priority, just because the UART I am using have just 4 bytes of FIFO while the Ethernet have thousands...
> 
> But I am not able to find where this is done in Linux, is interrupt priority supported at all ?
> 
> Thanks in advance for any comments,

You didn't say what platform this was, it likely matters a fair bit.

I don't know that changing interrupt priority is necessarily likely to 
do much, though. If the network card driver is disabling interrupts 
while handling packets and that's what's causing the problem, then it 
won't help.

Re: Is interrupt priority supported ?

[Jose Luis Marchetti]

> 
> it has been for a looong time (those things tend to almost
> get outdated already -
> witness the floppy controller misery):

He he, I am from the same era..., I appreciate your answer, but I am afraid your suggestion is not exactly what I was expecting.
The tools you mention appears to act on the hardware level, not on Linux by itself, they apply only to x86 processors ( as you can see by the name ), and I am not running Linux in one of those processors.
Roughly, this is what I have seen in other OSs that support interrupt priority:
Imagine a table with interrupt IDs, in my example they are in decreased priority order:
interrupt priority table:
Serial,
Ethernet,
Keyboard,
etc...
Then, when one interrupt happen, lets say the Ethernet, the OS disable all lower priority interrupts ( keyboard in my example ), but allow the Serial interrupt nest into the Ethernet interrupt.
In my example the serial is the highest priority interrupt and no one could nest into it.

I am not aware of "hardware transceiver offloading of Ethernet frames", thanks for that info and I am going to investigate it.

Thanks!




      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

Re: Is interrupt priority supported ?

[Jose Luis Marchetti]

> 
> You didn't say what platform this was, it likely
> matters a fair bit.

Mips processor, is this what you asked ?

> 
> I don't know that changing interrupt priority is
> necessarily likely to do much, though. If the network card
> driver is disabling interrupts while handling packets and
> that's what's causing the problem, then it won't
> help.

Yes, I checked that, the Ethernet driver is not disabling the interrupts.

Jose Luis Marchetti


      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

Re: Is interrupt priority supported ?

[Robert Hancock]

Jose Luis Marchetti wrote:
>> it has been for a looong time (those things tend to almost
>> get outdated already -
>> witness the floppy controller misery):
> 
> He he, I am from the same era..., I appreciate your answer, but I am afraid your suggestion is not exactly what I was expecting.
> The tools you mention appears to act on the hardware level, not on Linux by itself, they apply only to x86 processors ( as you can see by the name ), and I am not running Linux in one of those processors.
> Roughly, this is what I have seen in other OSs that support interrupt priority:
> Imagine a table with interrupt IDs, in my example they are in decreased priority order:
> interrupt priority table:
> Serial,
> Ethernet,
> Keyboard,
> etc...
> Then, when one interrupt happen, lets say the Ethernet, the OS disable all lower priority interrupts ( keyboard in my example ), but allow the Serial interrupt nest into the Ethernet interrupt.
> In my example the serial is the highest priority interrupt and no one could nest into it.

It doesn't really work that way in Linux. Normally disabling interrupts 
is all or nothing. Whether or not other devices can cause interrupts 
during an interrupt handler execution by default is a bit 
platform-dependent, I think (unless the driver requests IRQF_DISABLED 
which requests that other interrupts should not run).

Normally in Ethernet drivers these days only very minimal processing is 
done during the interrupt handler, the rest is deferred to softirq 
context which runs with interrupts enabled so other interrupts can 
happen. That's not to say that all Ethernet drivers are so well-behaved, 
however, especially if they haven't been updated to use NAPI. (In the 
NAPI case, the driver disables further interrupts from the device until 
the softirq is able to run and process the packets.) In your case it 
seems likely that yours is not behaving so well, as one would expect the 
interrupt handler to complete in less than the time  it takes one 
character to arrive on the serial port..

Re: Is interrupt priority supported ?

[Jose Luis Marchetti]

> It doesn't really work that way in Linux. Normally
> disabling interrupts is all or nothing. Whether or not other
> devices can cause interrupts during an interrupt handler
> execution by default is a bit platform-dependent, I think
> (unless the driver requests IRQF_DISABLED which requests
> that other interrupts should not run).
> 
> Normally in Ethernet drivers these days only very minimal
> processing is done during the interrupt handler, the rest is
> deferred to softirq context which runs with interrupts
> enabled so other interrupts can happen. That's not to
> say that all Ethernet drivers are so well-behaved, however,
> especially if they haven't been updated to use NAPI. (In
> the NAPI case, the driver disables further interrupts from
> the device until the softirq is able to run and process the
> packets.) In your case it seems likely that yours is not
> behaving so well, as one would expect the interrupt handler
> to complete in less than the time  it takes one character to
> arrive on the serial port..

Interesting, thanks for all the info, I had to research before responding.
It appears network cards was one of the reasons for the softirqs, there is two definitions for network cards in softirqs.
Yes, I looked the DM9000 driver and saw the data being read inside the interrupts so... you are right, that driver was not changed to use softirqs.
I also saw how the IRQF_DISABLED flag works.
I Think using this flag is the way to go for my 4 byte FIFO uart, I would say a 4 byte FIFO is critical enough to be read inside an interrupt.
I know it is kind of strange, the correct way it would be to fix the Ethernet driver and instead of doing that I will not allow any other interrupt inside the uart interrupt, which degrades the system somehow.
What do you think ?
Do you know if the same kind of problem I am having with Ethernet is also seen with USBs ?

Thanks again for all your response.



      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com