[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080104.232504.238436937.davem@davemloft.net>
Date: Fri, 04 Jan 2008 23:25:04 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: jchapman@...alix.com
Cc: netdev@...r.kernel.org, auke-jan.h.kok@...el.com
Subject: Re: NAPI poll behavior in various Intel drivers
From: James Chapman <jchapman@...alix.com>
Date: Sat, 05 Jan 2008 00:18:31 +0000
> David Miller wrote:
> > From: James Chapman <jchapman@...alix.com>
> > Date: Fri, 04 Jan 2008 20:10:30 +0000
> >
> >> With the latest NAPI, this code has to change. But rather than remove
> >> the tx_cleaned logic completely, shouldn't transmit processing be
> >> included in the work_done accounting when a driver does transmit cleanup
> >> processing in the poll?
> >
> > Most other NAPI drivers don't do this, they just process all the
> > pending TX work unconditionally and do not account it into the NAPI
> > poll work.
>
> This will cause the interface to thrash in/out of polled mode very
> quickly when it is doing almost all transmit work. That's something to
> avoid, no?
I see your point although I've never seen this in practice
with tg3 or niu.
For a heavy transmit load with TCP, the cpu killer is the ACK receive
processing.
I guess for a datagram send situation it might start to edge up.
However, you're likely deferring TX events (say every 1/4 of the TX
ring or similar) which should make the effect matter much less.
But anyways, it's someone else's driver so if they want to take
TX work into account sure. :-) I'll keep this in mind in my NAPI
changes.
Thanks.
--
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