public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: Benjamin LaHaise <bcrl@redhat.com>
Cc: "David S. Miller" <davem@redhat.com>,
	whitney@math.berkeley.edu, rgooch@ras.ucalgary.ca,
	linux-kernel@vger.kernel.org, marcelo@conectiva.com.br
Subject: Re: [patch] ns83820 0.17 (Re: Broadcom 5700/5701 Gigabit Ethernet Adapters)
Date: Thu, 14 Mar 2002 04:54:03 -0500	[thread overview]
Message-ID: <3C90733B.4020205@mandrakesoft.com> (raw)
In-Reply-To: <200203110205.g2B25Ar05044@adsl-209-76-109-63.dsl.snfc21.pacbell.net> <20020310.180456.91344522.davem@redhat.com> <20020310212210.A27870@redhat.com> <20020310.183033.67792009.davem@redhat.com> <20020312004036.A3441@redhat.com>

Benjamin LaHaise wrote:

>A day's tweaking later, and I'm getting 810mbit/s with netperf between 
>two Athlons with default settings (1500 byte packets).  What I've found 
>is that increasing the size of the RX/TX rings or the max sizes of the 
>tcp r/wmem backlogs really slows things down, so I'm not doing that 
>anymore.  The pair of P3s shows 262mbit/s (up from 67).
>
>Interrupt mitigation is now pretty stupid, but it helped: the irq 
>handler disables the rx interrupt and then triggers a tasklet to run 
>through the rx ring.  The tasklet later enables rx interrupts again.  
>More tweaking tomorrow...
>
>Marcelo, please apply the patch below to the next 2.4 prepatch: it 
>also has a fix for a tx hang problem, and a few other nasties.  Thanks!
>

Comments:

1) What were the test conditions leading to your decision to decrease 
the RX/TX ring count?  I'm not questioning the decision, but looking to 
be better informed...  other gigabit drivers normally have larger rings. 
 I also wonder if the slowdown you see could be related to a small-sized 
FIFO on the natsemi chips, that would probably not be present on other 
gigabit chips.

2) PCI latency timer is set with pci_set_master(), as in:  if it's not 
correctly set, fix it up.  If it's correctly set, leave it alone and let 
the user tune in BIOS Setup.

3) Seeing "volatile" in your code.  Cruft?  volatile's meaning change in 
recent gcc versions implies to me that your code may need some addition 
rmb/wmb calls perhaps, which are getting hidden via the driver's 
dependency on a compiler-version-specific implementation of "volatile."

4) Do you really mean to allocate memory for "REAL_RX_BUF_SIZE + 16"? 
 Why not plain old REAL_RX_BUF_SIZE?

5) Random question, do you call netif_carrier_{on,off,ok} for link 
status manipulation?  (if not, you should...)

6) skb_mangle_for_davem is pretty gross...  curious: what sort of NIC 
alignment restrictions are there on rx and tx buffers (not descriptors)? 
 None? 32-bit?  Ignore CPU alignment for a moment here...

7) What are the criteria for netif_wake_queue?  If you are waking when 
the TX is still "mostly full" you probably generate excessive wakeups...

8) There is no cabal.



  parent reply	other threads:[~2002-03-14  9:54 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-15 12:58 Broadcom 5700/5701 Gigabit Ethernet Adapters Frank Elsner
2002-02-15 13:06 ` Jeff Garzik
2002-02-15 14:36   ` Thomas Langås
2002-02-15 14:45     ` Jeff Garzik
2002-02-15 14:55       ` Thomas Langås
2002-02-15 15:00         ` Jeff Garzik
2002-02-15 15:36           ` Thomas Langås
2002-02-15 20:20     ` David S. Miller
2002-02-19  0:18       ` Thomas Langås
2002-02-15 15:03   ` Jason Lunz
2002-02-26 20:09     ` Jes Sorensen
2002-02-15 14:43 ` J Sloan
2002-02-27 14:12   ` Stephan von Krawczynski
2002-03-10 15:33     ` Harald Welte
2002-03-10 19:10       ` Jeff Garzik
2002-03-10 21:35         ` Harald Welte
2002-03-11  0:41       ` David S. Miller
2002-03-11  0:55         ` Richard Gooch
2002-03-11  1:03           ` David S. Miller
2002-03-11  1:14             ` Richard Gooch
2002-03-11  1:31               ` David S. Miller
2002-03-11  1:31               ` Jeff Garzik
2002-03-11  2:05               ` Wayne Whitney
2002-03-11  2:04                 ` David S. Miller
2002-03-11  2:10                   ` Richard Gooch
2002-03-11  2:15                     ` David S. Miller
2002-03-11  2:22                   ` Benjamin LaHaise
2002-03-11  2:28                     ` Mike Fedyk
2002-03-11  2:32                       ` David S. Miller
2002-03-11  2:30                     ` David S. Miller
2002-03-11  3:15                       ` Benjamin LaHaise
2002-03-11  4:20                         ` Michael Clark
2002-03-11  4:28                           ` Benjamin LaHaise
2002-03-11 19:48                       ` Richard Gooch
2002-03-12  6:04                         ` David S. Miller
2002-03-12  6:20                           ` Richard Gooch
2002-03-12  5:40                       ` [patch] ns83820 0.17 (Re: Broadcom 5700/5701 Gigabit Ethernet Adapters) Benjamin LaHaise
2002-03-12 11:00                         ` Michael Clark
2002-03-12 11:15                           ` [patch] ns83820 0.17 David S. Miller
2002-03-12 13:03                             ` dean gaudet
2002-03-12 13:03                               ` David S. Miller
2002-03-12 18:12                             ` Trever L. Adams
2002-03-12 18:17                               ` David S. Miller
2002-03-12 18:31                                 ` Trever L. Adams
2002-03-12 19:52                                 ` pjd
2002-03-12 19:06                               ` Charles Cazabon
2002-03-12 19:39                               ` Pedro M. Rodrigues
2002-03-14  9:54                         ` Jeff Garzik [this message]
2002-03-14 20:37                           ` [patch] ns83820 0.17 (Re: Broadcom 5700/5701 Gigabit Ethernet Adapters) Benjamin LaHaise
2002-03-15  1:02                             ` Jeff Garzik
2002-03-15  8:56                             ` Daniel Phillips
2002-04-08  5:14                         ` Richard Gooch
2002-03-11  2:04             ` Broadcom 5700/5701 Gigabit Ethernet Adapters Ben Collins
2002-03-11  2:13               ` David S. Miller
2002-03-11  2:22                 ` Ben Collins
2002-03-11  2:31                   ` David S. Miller
2002-03-21 20:39             ` Thomas Langås
2002-03-11  6:07         ` Harald Welte

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=3C90733B.4020205@mandrakesoft.com \
    --to=jgarzik@mandrakesoft.com \
    --cc=bcrl@redhat.com \
    --cc=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --cc=rgooch@ras.ucalgary.ca \
    --cc=whitney@math.berkeley.edu \
    /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