>Number:         2478
>Category:       kern
>Synopsis:       ep driver allocates mbufs at splhigh
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Tue May 28 13:05:04 1996
>Last-Modified:
>Originator:     Bill Sommerfeld
>Organization:
	
>Release:        NetBSD 1.1-current as of mid-april
>Environment:
	
System: NetBSD orchard.medford.ma.us 1.1B NetBSD 1.1B (ORCHARD) #9: Wed Apr 17 19:17:15 EDT 1996 sommerfeld@orchard.medford.ma.us:/home/src/netbsd-krb5/sys/arch/i386/compile/ORCHARD i386


>Description:

A complaint was sent to port-i386; it appears that Dennis is right
about this..

	To: christos@deshaw.com (Christos Zoulas)
	cc: port-i386@NetBSD.ORG
	Subject: Re: com driver troubles on NetBSD/i386 
	From: Dennis Ferguson <dennis@jnx.com>
	
	> Yes, the ep driver sets splhigh() while reading a packet. If
	> you are on a busy network, that can cause problems.

	The ep driver also seems to do this a little strangely, which
	probably makes it worse than it needs to be.  In particular
	the driver not only reads the packet at splhigh(), but does
	some (though not all) of its mbuf allocation there as well,
	even though it knows the length of the packet before hand and
	could fairly handily have done all buffer allocation prior to
	starting to read the packet at elevated priority.

	Not that mbuf allocation takes a lot of time in the normal
	case, but if it finds the allocation bucket empty and needs to
	go to the kvm system for more memory it can end up executing a
	pretty substantial amount of code with the interrupts blocked.
	In contrast the actual copying of the packet from the device,
	which appears to be the part which actually needs the
	interrupt protection, takes a relatively short, bounded amount
	of work if you've already got the memory.

	In fact, now that I think about it, this code also depends on
	the call to splimp() in the memory allocation code to not
	enable interrupts when called from splhigh().  This does not
	seem to be a universal truth among all architectures, so
	moving the memory allocation out of the splhigh() loop seems
	like a win all around.

	Dennis Ferguson

>How-To-Repeat:
	N/A
>Fix:
	
>Audit-Trail:
>Unformatted: