netdev
[Top] [All Lists]

netif_rx_schedule_prep() returning false?

To: netdev@xxxxxxxxxxx
Subject: netif_rx_schedule_prep() returning false?
From: Asim Shankar <asimshankar@xxxxxxxxx>
Date: Wed, 2 Feb 2005 12:04:38 -0600
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=U7R7Tt3Ax6KHJ9+m995Opl8A6PkQ582XT+Oduw0wR5kSa8eSUnjpkJYBZH9R4d5/B+hHejIhY2d6/F1KLIHyVKeQAe15b+0Ib7fgmuLegQTUnZjoAuknTbAEzAUoN3rOQf0m+tGgsOtsAc9yIxzZsFT1pa55xT52v/2uLL/IkZA=
Reply-to: Asim Shankar <asimshankar@xxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
Hi,

In NAPI related drivers, is it expected that netif_rx_schedule_prep()
will return false? Does the fact that it returns false mean something
is wrong?

Specifically, in e1000 driver, when loaded with TxIntDelay=0,
RxIntDelay=0, InterruptThrottleRate=0 (i.e., no hardware
interrupt-coalescing), I've observed that the call to
netif_rx_schedule_prep() in the interrupt handler (e1000_intr())
ocassionally returns false. Further investigation shows that this is
because the __LINK_STATE_RX_SCHED bit of the struct net_device's state
is already set (netif_running(dev) is always true). I also checked the
interrupt cause register (ICR) in the interrupt handler and it seems
the interrupts were caused by packet receives (ICR == E1000_ICR_RXT0,
no other bits in the ICR register were set), which by my understanding
should have not been possible.

In other words, it seems the device is already scheduled for polling
when a receive-related interrupt is received and handled.

Is this behavior normal?

Thanks,

-- Asim

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