All of lore.kernel.org
 help / color / mirror / Atom feed
From: Auke Kok <auke-jan.h.kok@intel.com>
To: hadi@cyberus.ca
Cc: "David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org, jesse.brandeburg@intel.com,
	Robert Olsson <Robert.Olsson@data.slu.se>,
	john.ronciak@intel.com, Ben Greear <greearb@candelatech.com>,
	Auke Kok <auke-jan.h.kok@intel.com>,
	Jeff Garzik <jgarzik@pobox.com>
Subject: Re: [e1000]:  flow control on by default - good idea really?
Date: Wed, 05 Jul 2006 09:23:54 -0700	[thread overview]
Message-ID: <44ABE79A.1060603@intel.com> (raw)
In-Reply-To: <1152040839.5276.25.camel@jzny2>

jamal wrote:
> On Tue, 2006-04-07 at 13:11 -0400, jamal wrote:
>> I have a device connected to a e1000 that was erroneously advertising
>> both tx/rx flow control but wasnt properly reacting to it. 
>> The default setup on the e1000 has rx flow control turned on.
>> I was sending at wire rate gige from the device - which is about
>> 1.48Mpps. The e1000 was in turn sending me flow control packets
>> as per default/expected behavior. Unfortunately, it was sending
>> a very large amount of packets. At one point i was seeing upto
>> 1Mpps and on average, the flow control packets were consuming
>> 60-70% of the bandwidth. Even when i fixed this behavior to act
>> properly, allowing flow control on consumed up to 15% of the bandwidth. 
>> Clearly, this is a bad thing. Yes, the device in the first instance was
>> at fault. But i have argued in the past that NAPI does just fine without
>> flow control being turned on, so even chewing 5% of bandwidth on flow
>> control is a bad thing..
>>
>> As a compromise, can we declare flow control as an advanced feature
>> and turn it off by default? People who feel it is valuable and know
>> what they are doing can turn it off.
> 
> I meant turn it on.
> 
> BTW, As an addendum this default behavior changed around 2.6.16 it
> seems.

Flow Control is using the EEPROM provided value, the module driver itself does 
not choose a default:

e1000_param.c:

/* User Specified Flow Control Override
  *
  * Valid Range: 0-3
  *  - 0 - No Flow Control
  *  - 1 - Rx only, respond to PAUSE frames but do not generate them
  *  - 2 - Tx only, generate PAUSE frames but ignore them on receive
  *  - 3 - Full Flow Control Support
  *
  * Default Value: Read flow control settings from the EEPROM
  */

Turning flow control off usually (i.e. almost always) causes (significantly) 
_degraded_ performance. We should really leave it the way it is (as per eeprom 
setting), and this is best for most if not all people. The card itself has 
this value programmed, which makes it possible for the user to turn on/off 
flowcontrol per card consistently, which makes much more sense to me. Also 
considering e1000 hardware varies significantly.

Moreover, most support calls here where people complain about degraded 
performance are about users who turned flow control _off_. :)


Cheers,

Auke

  reply	other threads:[~2006-07-05 16:25 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-04 17:11 [e1000]: flow control on by default - good idea really? jamal
2006-07-04 19:20 ` jamal
2006-07-05 16:23   ` Auke Kok [this message]
2006-07-05 20:37     ` Krzysztof Oledzki
2006-07-05 18:22   ` David Miller
2006-07-05 18:32     ` Auke Kok
2006-07-05 20:45       ` Krzysztof Oledzki
2006-07-05 21:13         ` Auke Kok
2006-07-06 13:03         ` jamal
2006-07-06 18:25           ` Auke Kok
2006-07-07  3:09             ` jamal
2006-07-07  6:59           ` David Miller
2006-07-07 12:28             ` jamal
2006-07-20 20:15               ` Bug in e1000 + semantics of flow control WAS(Re: " jamal
2006-08-03 12:29                 ` jamal
2006-10-16 18:55               ` Auke Kok
2006-10-17 13:05                 ` jamal
2006-10-17 17:18                   ` Auke Kok
2006-10-17 18:25                   ` Stephen Hemminger
2006-10-17 21:02                   ` Auke Kok
2006-10-18 13:35                     ` jamal
2006-10-18 14:57                       ` Auke Kok
2006-10-17 21:46                   ` David Miller
2006-07-05 16:57 ` Robert Olsson
2006-07-05 18:21 ` David Miller
  -- strict thread matches above, loose matches on Subject: below --
2006-07-07  4:43 Michael Chan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44ABE79A.1060603@intel.com \
    --to=auke-jan.h.kok@intel.com \
    --cc=Robert.Olsson@data.slu.se \
    --cc=davem@davemloft.net \
    --cc=greearb@candelatech.com \
    --cc=hadi@cyberus.ca \
    --cc=jesse.brandeburg@intel.com \
    --cc=jgarzik@pobox.com \
    --cc=john.ronciak@intel.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.