netif_rx_schedule_prep() returning false?

netif_rx_schedule_prep() returning false?

[Asim Shankar]

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

Re: netif_rx_schedule_prep() returning false?

[Scott Feldman]

On Wed, 2005-02-02 at 10:04, Asim Shankar wrote:
> 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.

I'm running the same setup with delays turned off and I'm not seeing
what you're seeing.  What e1000 controller are you using?  Send lspci
-n.

-scott

Re: netif_rx_schedule_prep() returning false?

[Asim Shankar]

> I'm running the same setup with delays turned off and I'm not seeing
> what you're seeing.  What e1000 controller are you using?  Send lspci
> -n.

lspci -n:
00:00.0 Class 0600: 8086:7190 (rev 03)
00:01.0 Class 0604: 8086:7191 (rev 03)
00:07.0 Class 0601: 8086:7110 (rev 02)
00:07.1 Class 0101: 8086:7111 (rev 01)
00:07.2 Class 0c03: 8086:7112 (rev 01)
00:07.3 Class 0680: 8086:7113 (rev 02)
00:10.0 Class 0200: 8086:1076
00:11.0 Class 0200: 10b7:9055
00:13.0 Class 0604: 1011:0024 (rev 03)
01:00.0 Class 0300: 10de:0028 (rev 11)

This happens when a more "powerful" machine sends to a less powerful
one and not the reverse. My setup is so:
Machine A: Dual Xeon 2.8Ghz, 1GB RAM Dell PowerEdge 1800
Machine B: Dual P-III 500Mhz, 512MB RAM, old Dell Precision 410

I'm using netperf, so B is running a "netserver" and the netperf
client application is started on A. "lspci" shown above is from "B".

When reversed, B sending TO A, then machine A doesn't complain at all.
Machine A also has the same card: Intel PRO/1000 MT Desktop Adapter -
Class 0200: 8086:1076.

Thanks,
Regards,

-- Asim

P.S. Changes to e1000_intr() in order to check this:
o Added "int rx_sched = test_bit(__LINK_STATE_RX_SCHED, &netdev->state);
o Later, added an "else" to the "if
(likely(netif_rx_schedule_prep(nedev))" block where I do a printk()