netdev - Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20110928170713.GA16532@hmsreliant.think-freely.org>
Date:	Wed, 28 Sep 2011 13:07:13 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	Ben Hutchings <bhutchings@...arflare.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	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>
Subject: Re: [net-next 11/13] igb: Make Tx budget for NAPI user adjustable

On Wed, Sep 28, 2011 at 08:11:58AM -0700, Stephen Hemminger wrote:
> On Wed, 28 Sep 2011 07:00:55 -0400
> Neil Horman <nhorman@...driver.com> wrote:
> 
> > I was thinking of something along the lines of two more attributes in
> > /sys/class/net/<if>/queues:
> > napi_weight
> > irq
> > 
> > The former is the napi weight of a given napi instance associated with a queue,
> > while the latter is a symlink either to ../device/irq or ../device/msi_irqs/<n>/
> > (or perhaps to ../devices/msi_irqs/<n>/irq if we want more consistency).   This
> > lets us tune the napi weight of a queue and know what interrupt is associated
> > with it.  That seems fairly sane to me.
> 
> This breaks for the case of some corner case devices like multi-port Marvell boards.
> There can be a N to 1 or 1 to N relationship between NAPI and the device.
> 

I don't see that it has to explicitly _break_ anything.  If a multiqueue device
uses a single napi instance to handle all queues, we can still create a napi
weight attribute for each queue, and simply let the device driver tie all the
weight sysfs objects to the same napi instance.  It would be odd for certain,
but doable.  In fact, since we'd have to get the driver involved in the creation
of such a per-queue napi weight attribute (since the driver is the only thing
with any knoweldge about which queue maps to which napi instance), we might be
able to explicitly export this information by allowing a single queue to hold
the napi wieght, and allowing the other queues sysfs symlinks back to that
object.  

I'm just spitballing here on implementation, but I don't think the idea is
broken.
Neil

--
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