[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1347570650.13258.40.camel@deadeye.wl.decadent.org.uk>
Date: Thu, 13 Sep 2012 22:10:50 +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 16:46 -0400, David Miller wrote:
> From: Ben Hutchings <bhutchings@...arflare.com>
> Date: Thu, 13 Sep 2012 21:42:51 +0100
>
> > On Thu, 2012-09-13 at 16:23 -0400, David Miller wrote:
> >> From: Giuseppe CAVALLARO <peppe.cavallaro@...com>
> >> Date: Tue, 11 Sep 2012 08:55:09 +0200
> >>
> >> > + unsigned long flags;
> >> > +
> >> > + spin_lock_irqsave(&priv->tx_lock, flags);
> >> >
> >> > - spin_lock(&priv->tx_lock);
> >> > + priv->xstats.tx_clean++;
> >>
> >> You are changing the locking here for the sake of the new timer.
> >>
> >> But timers run in software interrupt context, so this change is
> >> completely unnecessary since NAPI runs in software interrupt context
> >> as well, and neither timers nor NAPI run in hardware interrupts
> >> context.
> >
> > NAPI pollers can be called by netpoll in hardware interrupt context, and
> > this driver supports netpoll.
>
> And the netpoll handler need to make amends to make sure that
> hardware the environment expected by the software interrupt
> code is preserved.
>
> 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.
> I'm not considering your patches until you implement this properly.
These aren't my patches.
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