[PATCH net-next 0/8] tg3: Bugfixes and updates

[PATCH net-next 0/8] tg3: Bugfixes and updates

[Matt Carlson]

This patchset implements some bugfixes, removes the 5724 device
ID and introduces extended rx buffer rings.

Re: [PATCH net-next 0/8] tg3: Bugfixes and updates

[David Miller]

From: "Matt Carlson" <mcarlson@broadcom.com>
Date: Thu, 30 Sep 2010 13:34:29 -0700

> This patchset implements some bugfixes, removes the 5724 device
> ID and introduces extended rx buffer rings.

All applied....

But really, I want to hear some real justification for a 2048 entry RX
ring at gigabit speeds.  I even think 512 is way too large for gigabit
parts.

Any machine that gets one of these newer 5717 parts does not need that
much queueing, and too deep queues tend to hurt locality and thus
performance.

Re: [PATCH net-next 0/8] tg3: Bugfixes and updates

[Matt Carlson]

On Fri, Oct 01, 2010 at 12:26:28AM -0700, David Miller wrote:
> From: "Matt Carlson" <mcarlson@broadcom.com>
> Date: Thu, 30 Sep 2010 13:34:29 -0700
> 
> > This patchset implements some bugfixes, removes the 5724 device
> > ID and introduces extended rx buffer rings.
> 
> All applied....
> 
> But really, I want to hear some real justification for a 2048 entry RX
> ring at gigabit speeds.  I even think 512 is way too large for gigabit
> parts.

I don't have any personal experience where a larger ring size could
benefit.  However, I have heard of situations in the past where people
have said increasing the amount of rx buffers available has smoothed
over some bursty traffic / cpu usage patterns.  These people really did
want more than 512 rx buffers.

> Any machine that gets one of these newer 5717 parts does not need that
> much queueing, and too deep queues tend to hurt locality and thus
> performance.

Good point.  I'll see if we can scale the BD ring size based on the
number of rx buffers the administrator has configured.