em driver - issue #2

[EM1897 at aol.com]

>Some more info on this:
>
>netstat -m, after the "lockup" of the em driver shows:
>
>>533/5533/80000 mbufs in use
>>532/1532/20000 mbuf clusters in use
>
>So there really shouldn't have been any failure to get a replacement 
>buffer in the first place. The max clusters is interestingly exactly
>1000 clusters over the idle amount, and mbufs is exactly 5000
>more, which can't be a coincidence. Could there be some sort of 
>threshold in play here?

Ok, I have some more info on this that may help to sort it out.

I set the m_getcl() in em_get_buf to MB_WAIT and the symptoms are
interesting. After about 5 seconds, the mbuf exhausted message
appears again. But, it doesn't lock up. For a short time the NIC is 
issuing flow controls (as the transmit stream is being held up to a 
lower than optimal volume), after awhile the box is able to handle 
the full stream normally, showing ~144000 received packets in the 
ICMP unreachable message, as is expected.

I assume this is some sort of memory cache that gets built up over
time. Something that is pre-allocated in FreeBSD but not in Dfly?

It appears that the lockup is a bug in the em driver; one that perhaps
just doesnt happen often enough for anyone to have gone to the trouble
of tracking it down. But its exasperated by the mbuf problem, so if that 
can be cleared up it should be "good enough", at least for the time being.