Subject: Re: com driver troubles on NetBSD/i386
To: Christos Zoulas <christos@deshaw.com>
From: Dennis Ferguson <dennis@jnx.com>
List: port-i386
Date: 05/26/1996 12:50:53
> 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