[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1185330794.1803.452.camel@localhost.localdomain>
Date: Wed, 25 Jul 2007 12:33:14 +1000
From: Rusty Russell <rusty@...tcorp.com.au>
To: David Miller <davem@...emloft.net>
Cc: netdev@...r.kernel.org, shemminger@...ux-foundation.org,
jgarzik@...ox.com, hadi@...erus.ca
Subject: Re: [PATCH RFX]: napi_struct V3
On Tue, 2007-07-24 at 18:47 -0700, David Miller wrote:
> One thing that's peculiar is that when netif_rx_schedule_prep()
> fails, we don't disable interrupts but we also don't clear the
> condition that is causing the interrupt to occur.
I think we're ok, but this stuff is tricky.
In the driver in -rc1, I think it will only fail if racing with the
netif_rx_reschedule, which will do the right thing.
In your version, there is only one place where prep can fail (ie.
interrupts are enabled, but netif_rx_complete() hasn't been called):
when ibmveth_poll saw pending buffers and disabled the irq (which has
already been delivered and is spinning on the poll_lock)
In this case, we're ok because the irqs really are disabled now: the
running handler is a relic.
> Perhaps the lock is avoidable somehow, who knows :)
Maybe by adding YA state bit? Hold on, this might get ugly...
Say netif_rx_schedule_prep() sets the MORE_TODO bit (atomically instead
of setting __LINK_STATE_RX_SCHED) if it's going to fail, and
netif_rx_complete() returns 0 if it was set, or 1 if it's OK. Now
callers do:
reenable_interrupts();
if (rx_pending() || !netif_rx_complete(netdev, napi))
disable_interrupts();
I'm going to go absorb some more caffeine before you reply 8)
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists