Re: em driver - issue #2

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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. 

    My guess is that what is going on is that the EM device is unable
    to allocate a buffer to the receive ring.  This creates 'holes'
    in the receive ring.  The EM device's RX interrupt is stopping either
    when it hits a hole, or if there are no good descriptors left in the
    receive ring.  The restart only occurs on the next em_poll() or
    em_intr() which in this case would be a transmit interrupt.

    The best solution is probably to create a 'dummy' mbuf to act as filler
    when the device is unable to allocate a new one, and then ignore such
    mbufs (drop the related packets) when they are encountered.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>