[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1347577875.13258.70.camel@deadeye.wl.decadent.org.uk>
Date: Fri, 14 Sep 2012 00:11:15 +0100
From: Ben Hutchings <bhutchings@...arflare.com>
To: David Miller <davem@...emloft.net>
CC: <peppe.cavallaro@...com>, <netdev@...r.kernel.org>
Subject: Re: [net-next.git 3/8 (V2)] stmmac: add the initial tx coalesce
schema
On Thu, 2012-09-13 at 17:37 -0400, David Miller wrote:
> From: Ben Hutchings <bhutchings@...arflare.com>
> Date: Thu, 13 Sep 2012 22:10:50 +0100
>
> > On Thu, 2012-09-13 at 16:46 -0400, David Miller wrote:
> >> From: Ben Hutchings <bhutchings@...arflare.com>
> >> Date: Thu, 13 Sep 2012 21:42:51 +0100
> >>
> >> Well written NAPI drivers never need to disable hardware interrupts
> >> in their ->poll() method and it's callers, neither should you.
> >
> > Perhaps you should get round to reviewing netpoll, because it does
> > exactly this.
>
> Then I don't understand the point you're trying to make.
>
> Hardware interrupt disabling has absolutely no place in the
> NAPI polling fast paths.
>
> If NAPI drivers can't be implemented without hardware interrupt
> toggling in ->poll(), we've failed.
Right.
The problem being that NAPI poll functions *are* sometimes called in
hardware interrupt context. Thus, any spinlock that may be taken by a
NAPI handler, may well need to be taken with spinlock_irq or
spinlock_irqsave elsewhere. (This is horrible and I think it's well
past time that we ripped the NAPI polling out of netpoll.)
I think you're right that stmmac_tx() (completion handler?) doesn't need
to disable hardware interrupts, but sadly stmmac_xmit() does right now
unless Giuseppe can work out how to make their interaction lockless.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
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