[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090327.145502.214872726.davem@davemloft.net>
Date: Fri, 27 Mar 2009 14:55:02 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: Joakim.Tjernlund@...nsmode.se
Cc: leoli@...escale.com, avorontsov@...mvista.com,
linuxppc-dev@...abs.org, netdev@...r.kernel.org, pku.leo@...il.com
Subject: Re: [PATCH 1/2] ucc_geth: Move freeing of TX packets to NAPI
context.
From: Joakim Tjernlund <Joakim.Tjernlund@...nsmode.se>
Date: Fri, 27 Mar 2009 12:52:41 +0100
> pku.leo@...il.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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists