netdev
[Top] [All Lists]

Re: [PATCH] [RFT] 2.6.4 - epic100 napi

To: OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>
Subject: Re: [PATCH] [RFT] 2.6.4 - epic100 napi
From: Francois Romieu <romieu@xxxxxxxxxxxxx>
Date: Wed, 24 Mar 2004 13:33:39 +0100
Cc: Jeff Garzik <jgarzik@xxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <87lllrdkiu.fsf@xxxxxxxxxxxxxxxxxx>; from hirofumi@xxxxxxxxxxxxxxxxxx on Wed, Mar 24, 2004 at 11:52:09AM +0900
References: <20040320152109.A31118@xxxxxxxxxxxxxxxxxxxxxxxxxx> <405DDDC6.7030007@xxxxxxxxx> <8765cvmyaq.fsf@xxxxxxxxxxxxxxxxxxx> <20040323195119.A14062@xxxxxxxxxxxxxxxxxxxxxxxxxx> <871xnjgwrs.fsf@xxxxxxxxxxxxxxxxxxx> <20040324014140.A16202@xxxxxxxxxxxxxxxxxxxxxxxxxx> <87lllrdkiu.fsf@xxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.2.5.1i
OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> :
[...]
> Do you care the lost interrupt? If so, I was miss reading it.
> 
> IIRC, PCI spec requires the level-trigger. So devices asserts IRQ
> signal until the driver clears the pending interrupt. No?

<insert usual "correct me if I'm wrong" disclaimer here>

The driver only masks the interruptions which are napi related so
epic_poll() and epic_interrupt() are always racing. I completely agree that
it "wastes" the nice behavior of level-triggered irq. If one wants to avoid
the race, everything should go to the poll() handler. It implies polled
access to the INTSTAT register (as done in epic_rx_err).

I could not find in the archives some general napi-wisdom which suggests
that everything has to go to the poll() handler, be it for simplicity or
for a real gain. So I hesitate to follow the other way and exchange the
polled access for some (locked) traffic between the poll() and the irq
handler.

Comments welcome.

--
Ueimor

<Prev in Thread] Current Thread [Next in Thread>