Subject: kern/2478: ep driver allocates mbufs at splhigh
To: None <gnats-bugs@NetBSD.ORG>
From: Bill Sommerfeld <firstname.lastname@example.org>
Date: 05/28/1996 16:16:36
>Synopsis: ep driver allocates mbufs at splhigh
>Responsible: kern-bug-people (Kernel Bug People)
>Arrival-Date: Tue May 28 13:05:04 1996
>Originator: Bill Sommerfeld
>Release: NetBSD 1.1-current as of mid-april
System: NetBSD orchard.medford.ma.us 1.1B NetBSD 1.1B (ORCHARD) #9: Wed Apr 17 19:17:15 EDT 1996 email@example.com:/home/src/netbsd-krb5/sys/arch/i386/compile/ORCHARD i386
A complaint was sent to port-i386; it appears that Dennis is right
To: firstname.lastname@example.org (Christos Zoulas)
Subject: Re: com driver troubles on NetBSD/i386
From: Dennis Ferguson <email@example.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.