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: <201105111937.47448.oliver@neukum.org>
Date:	Wed, 11 May 2011 19:37:47 +0200
From:	Oliver Neukum <oliver@...kum.org>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Ming Lei <tom.leiming@...il.com>, netdev@...r.kernel.org,
	linux-usb@...r.kernel.org
Subject: Re: future developments of usbnet

Am Montag, 9. Mai 2011, 17:46:49 schrieb Stephen Hemminger:
> On Mon, 9 May 2011 11:31:16 -0400 (EDT)
> Alan Stern <stern@...land.harvard.edu> wrote:

> > How do other network drivers handle this problem?  Can the same 
> > strategy be used?
> > 
> > Alan Stern
> 
> Most Ethernet drivers have a fixed size receive ring and pass preallocated
> memory (skb's or pages) for the hardware to fill in. When NAPI poll is run
> it refills the ring and passes the data up to netif_receive_skb. NAPI allows
> the poll routine to process a limited number of packets (weight) and after
> that the poll loop exits and gets rerun by soft interrupt.  If data is
> arriving faster than the kernel can process, eventually the receive ring
> passed to hardware gets exhausted and the hardware drops packets.

How is the frequency NAPI uses to poll determined? We could abuse
this and resubmit the rx URBs only at poll time, but this feels dirty,
because we would still leave interrupts enabled.

Is there no other driver which faces this problem?

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