[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110920185918.GX21309@gospo.rdu.redhat.com>
Date: Tue, 20 Sep 2011 14:59:18 -0400
From: Andy Gospodarek <andy@...yhouse.net>
To: Ben Hutchings <bhutchings@...arflare.com>
Cc: Stephen Hemminger <stephen.hemminger@...tta.com>,
jeffrey t kirsher <jeffrey.t.kirsher@...el.com>,
David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
gospo@...hat.com, Alexander H Duyck <alexander.h.duyck@...el.com>,
nhorman@...driver.com
Subject: Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable
On Tue, Sep 20, 2011 at 01:10:01AM +0100, Ben Hutchings wrote:
> On Mon, 2011-09-19 at 16:42 -0700, Stephen Hemminger wrote:
> > I would like to see a general solution to allow configuring
> > napi weight. The Rx weight isn't easily configurable either.
>
> Indeed.
>
> > Probably needs to be through ethtool callback since actual value range
> > and dev -> napi relationship is device specific.
>
> The maximum meaningful value is device specific but I'm not sure that
> really matters.
>
> And as David said it's really a many-to-one mapping of queue -> NAPI.
> At netconf we talked about having 'irq' as an attribute of each queue
> but maybe we should expose NAPI contexts through sysfs and make queues
> refer to them instead. NAPI contexts would be named (in the same way as
> the corresponding IRQ handlers) and have irq, weight, etc.
>
> (Still short of time to work on this myself, alas.)
>
I've been having a similar discussion with Neil Horman about how we can
better control all sorts of device values (interrupts, number of queues,
queue to node mapping, etc.). Some of this is based on what I would
like to see and some is from Stephen's talk at LPC two weeks ago. I
think the sysfs work Neil has done and posted to lkml can easily be
expanded to allow enhanced configuration of each device. Having napi
weight in there too seems like a reasonable addition to this.
--
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