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] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 22 Feb 2007 03:18:58 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	benh@...nel.crashing.org
Cc:	shemminger@...l.org, netdev@...r.kernel.org, ebs@...home.net,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] split NAPI from network device.

From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Date: Thu, 22 Feb 2007 10:24:31 +1100

> The device has a single interrupt though that interrupt at least can
> tell you which queues need servicing. It can't mask the interrupt per
> queue though, which is the main issue.

Right, which effectively turns it into a single interrupt
for multiple queues as far as NAPI is concerned.

> So while I think this scheme would work (the driver, ibm_emac, currently
> uses a fake net_device and that sort-of works, budget is set a CONFIG_*
> time though, I'm sure that can/needs to be improved), I've been
> wondering all along if I could do something smarter by doing some
> interrupt soft-disabling instead, though I have to get my head around
> properly kicking softirqs from task context (if I need to re-trigger
> from a enable_*() call occuring at task context).

If you cannot make use of it sanely in your driver, it's hard to
justify this patch just in the cleanup sense since it breaks
NAPI interfaces and makes driver maintainence harder than it would
need to be.

Whereas if it makes a straightforward implementation in drivers
like ibm_emac possible, this tends to tip things over the edge
such that we can justify the maintainence hassles to some extent.

I think the intention with these changes, is that you would
have a napi struct per-queue.  It would be embedded in some
private per-queue software state struct, and from which you
could also get to the device.  So you'd do the "container_of()"
bit a little bit differently at the beginning of your ->poll()
method.

This way you don't need the dummy netdevices.

Anyways, please let us know what you come up with once you get
a chance to investigate this.

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