public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: jamal <hadi@cyberus.ca>
To: Auke Kok <auke-jan.h.kok@intel.com>
Cc: David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, jesse.brandeburg@intel.com,
	Robert.Olsson@data.slu.se, john.ronciak@intel.com,
	greearb@candelatech.com, jgarzik@pobox.com,
	Krzysztof Oledzki <olel@ans.pl>
Subject: Re: [e1000]: flow control on by default - good idea really?
Date: Thu, 06 Jul 2006 23:09:18 -0400	[thread overview]
Message-ID: <1152241758.5341.9.camel@jzny2> (raw)
In-Reply-To: <44AD55B2.3030900@intel.com>

On Thu, 2006-06-07 at 11:25 -0700, Auke Kok wrote:
> jamal wrote:

> > hadi@jzny2:~/Desktop/maemo$ sudo ethtool -a eth0
> > Pause parameters for eth0:
> > Autonegotiate:  on
> > RX:             off
> > TX:             off
> 
> mine says it's on :)


Dell D610:
hadi@jzny2:~$ sudo lspci | grep -i bcm
0000:02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751
Gigabit Ethernet PCI Express (rev 01)

Whats yours?
So ok, from what you say below i take it that even with the e1000s
you didnt find consistency on different machines.
Can you double check at least the kernels are >= 2.6.16?
I can tell you this hardware that caused me problems never had flow
control working in the earlier kernels.

> > Maybe it is read from the eeprom and mine has it off?
> > 
> > Again, note that: It is consuming > 10% (13-15% range) of my bandwidth.
> > Granted that is at high speeds with small packets so may not be
> > reflective of 96% of the world. But that would be > 50kpps of my
> > forwarding capacity being chewed unreasonably. So Auke, did you say
> > "performance" was what people mostly bitched about? ;->
> 
> yes, but that's linked with hardware that doesn't handle flowcontrol events 
> properly, 

As i mentioned earlier: This is actually hardware that works with flow
control ;->
When it doesnt work - as in the case of the one i found advertising but
not respecting flow control the bandwidth being consumed was > 60% ;->
To give you perspective, on average that is > 500Mbps

> if you were doing large message TCP transfers over that you'd 
> probably see even worse performance I bet (retransmits being dropped etc).
> 

I havent tested that, but it does seem unlikely.

> Jesse is working on performance stuff, he'll gladly look into it :)
> 

Jesse, if you want to reproduce this talk to me and i will give you a
description of how to do it. Make sure you can record flow control
packets both in send and receive.


> >>> As said earlier, e1000 always honors the EEPROM setting for this, which has 
> >>> been _on_ by default for all cards (AFAIK, that is).
> > 
> > It has _never ever_ worked on e1000 for as long as i have used e1000. If
> > it was intended to work, it must have been fixed in 2.6.16. So it is new
> > behavior.
> 
> Turns out that of the e1000 cards I can find around here that are plugged in 
> actually are 50-50 distributed on/off, so I was wrong about it being on by 
> default everywhere.
> 
> Looking back through the code I see no changes affecting flow control setup as 
> early as 2.6.12 ... There are some minor (new) HW changes but nothing that 
> should have boken fc.
> 

It could be something very basic. Since you have access to a variety of
hardware (and variety of kernels i take it), you can go by elimination
and find it.

cheers,
jamal


  reply	other threads:[~2006-07-07  3:09 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
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 [this message]
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=1152241758.5341.9.camel@jzny2 \
    --to=hadi@cyberus.ca \
    --cc=Robert.Olsson@data.slu.se \
    --cc=auke-jan.h.kok@intel.com \
    --cc=davem@davemloft.net \
    --cc=greearb@candelatech.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=jgarzik@pobox.com \
    --cc=john.ronciak@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=olel@ans.pl \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox