Re: [RFT] pcnet32 NAPI changes

[Jon Mason <jdmason@us.ibm.com>]

On Mon, Jun 19, 2006 at 04:49:33PM -0400, Lennart Sorensen wrote:
> On Mon, Jun 19, 2006 at 03:41:40PM -0500, Jon Mason wrote:
> > I believe it is preferred to be a compile option for non-gigabit
> > drivers, given that it will be eating a lot of cycles for infrequent
> > packets (especially for the 10Mb).  I believe there was a thread about
> > this last year when e100 was having NAPI problems.
> 
> How does NAPI eat cycles?  It goes back to interrupt mode when the queue
> is empty, and only on RX interrupt does it turn on polling again.

The amount of polls per received packet is very low, thus removing the
benefit of NAPI.  A compile time option would allow those users who know
better to DTRT.

> It is certainly possible that there are bugs in a NAPI conversion, which
> I guess could be a reason to have the option to stick with the old
> method, although then again not having the option ensures the bugs get
> found sooner.
> 
> > A general nit.  There are ALOT of magic numbers in the code, most
> > existing prior to this patch.  The driver would benefit from a little
> > clean-up.
> > 
> > Also nothing to do with this patch, but I noticed it when the code was
> > moved.  A comment about why the following is necessary might be nice:
> > lp->rx_ring[i].buf_length = le16_to_cpu(2 - PKT_BUF_SZ);
> 
> I suspect many drivers are in need of some cleanup.

Yup, but the "everyone else is doing it" argument never worked with my
parents. All it takes is one brave soul to determine the reasoning
behind the magic numbers and convert them into #define's.  Shouldn't be
more than one day's work.

> 
> Len Sorensen
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html