netdev - Re: future developments of usbnet

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]

Message-ID: <Pine.LNX.4.44L0.1105121025360.1917-100000@iolanthe.rowland.org>
Date:	Thu, 12 May 2011 10:37:28 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Oliver Neukum <oliver@...kum.org>
cc:	David Miller <davem@...emloft.net>, <shemminger@...tta.com>,
	<tom.leiming@...il.com>, <netdev@...r.kernel.org>,
	<linux-usb@...r.kernel.org>
Subject: Re: future developments of usbnet

On Thu, 12 May 2011, Oliver Neukum wrote:

> Am Mittwoch, 11. Mai 2011, 19:47:27 schrieb David Miller:
> 
> > Basically once you take you interrupt, and disable device interrupts,
> > the generic net device layer calls your ->poll() routing with a "weight"
> > You should not process more RX packets than this value.
> > 
> > If you have less than "weight" work to do, you should do a napi_complete(),
> > which takes you out of the polling group, and re-enable device interrupts.
> > 
> > So the idea is that you keep getting ->poll()'d until there is no more
> > RX work to do.
> > 
> > The "weight" argument implements fairness amongst competing, actively
> > polling, devices on the same CPU.
> > 
> 
> Thank you, this is very informative. Our problem here is that USB doesn't work
> sanely without interrupts. We can stop IO regarding rx, but we cannot stop
> interrupts if we want to do rx.

The idea behind NAPI can be adapted to the usbnet context.  The basic
idea is that the driver is allowed to accept only a limited number of 
packets, driven by polling from the NAPI core.

Therefore usbnet's poll routine should take the "weight" argument as an
indication of how many outstanding rx URBs are allowed.  Each time the
poll routine is called, it should check to see if any rx URBs have
completed since the previous poll.  If not then there is no network
traffic, so usbnet can take itself out of the poll loop.  Otherwise,
the number of outstanding URBs should be adjusted (by unlinking some or
submitting more -- subject to some fixed maximum limit) to match the
new "weight".

Does that make sense?

Alan Stern

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