linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: Joakim.Tjernlund@transmode.se
Cc: linuxppc-dev@ozlabs.org, leoli@freescale.com, pku.leo@gmail.com,
	netdev@vger.kernel.org
Subject: Re: [PATCH 1/2] ucc_geth: Move freeing of TX packets to NAPI context.
Date: Fri, 27 Mar 2009 14:55:02 -0700 (PDT)	[thread overview]
Message-ID: <20090327.145502.214872726.davem@davemloft.net> (raw)
In-Reply-To: <OF073D5C49.F0D791DE-ONC1257586.0040163D-C1257586.00413F47@transmode.se>

From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Fri, 27 Mar 2009 12:52:41 +0100

> pku.leo@gmail.com wrote on 27/03/2009 11:50:09:
> > It doesn't make sense to have larger napi budget than the size of RX
> > BD ring.  You can't have more BDs than RX_BD_RING_LEN in backlog for
> > napi_poll to process.  Increase the RX_BD_RING_LEN if you want to
> > increase UCC_GETH_DEV_WEIGHT.  However please also provide the
> > performance comparison for this kind of change.  Thanks
> 
> Bring it up with David Miller.

Right I told him to make this very change.

Pretty soon the driver's won't be able to select this value
and it will default to 64 everwhere anyways.

"performance comparison"?  He can't do that unless he tests
performance with two active NAPI devices on the same exact
cpu as the weight value is for fairness between devices.

So you don't tweak "weight" to make one device perform better,
you tweak it to eliminate unfairness between multiple devices.
And the only way to achieve that is to use similar values
across all devices, perhaps link-speed rated which we can't
do just yet, and that's why I told him to use 64 just like
every other driver basically does.

  reply	other threads:[~2009-03-27 21:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-26 12:54 [PATCH 1/2] ucc_geth: Move freeing of TX packets to NAPI context Joakim Tjernlund
2009-03-26 12:54 ` [PATCH 2/2] ucc_geth: Rework the TX logic Joakim Tjernlund
2009-03-26 13:39   ` Anton Vorontsov
2009-03-26 16:43     ` Joakim Tjernlund
2009-03-26 18:05       ` Anton Vorontsov
2009-03-26 18:20         ` Joakim Tjernlund
2009-03-27  7:42           ` David Miller
2009-03-27  9:37             ` Joakim Tjernlund
2009-03-26 14:15 ` [PATCH 1/2] ucc_geth: Move freeing of TX packets to NAPI context Eric Dumazet
2009-03-26 16:55   ` Joakim Tjernlund
2009-03-27 10:50 ` Li Yang
2009-03-27 11:52   ` Joakim Tjernlund
2009-03-27 21:55     ` David Miller [this message]
2009-03-30  7:36     ` Li Yang
2009-03-30  7:48       ` Joakim Tjernlund
2009-03-30  7:57         ` Li Yang

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=20090327.145502.214872726.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=Joakim.Tjernlund@transmode.se \
    --cc=leoli@freescale.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=netdev@vger.kernel.org \
    --cc=pku.leo@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).