[vnet] [epair] epair interface stops working after some time

Bjoern A. Zeeb bzeeb-lists at lists.zabbadoz.net
Tue Mar 27 14:48:37 UTC 2018


On 27 Mar 2018, at 14:40, Kristof Provost wrote:

> (Re-cc freebsd-net, because this is useful information)
>
> On 27 Mar 2018, at 13:07, Reshad Patuck wrote:
>> The epair crash occurred again today running the epair module code 
>> with the added dtrace sdt providers.
>>>> Running the same command as last time, 'dtrace -n ::epair\*:' returns 
>> the following:
>> ```
>> CPU     ID                    FUNCTION:NAME
>>>   0  66499   epair_transmit_locked:enqueued
>> ```
>
>> Looks like its filled up a queue somewhere and is dropping 
>> connections post that.
>>>> The value of the 'error' is 55 I can see both the ifp and m structs 
>> but don't know what to look for in them.
>>
> That’s useful. Error 55 is ENOBUFS, which in IFQ_ENQUEUE() means 
> we’re hitting _IF_QFULL().
> There don’t seem to be counters for that drop though, so that makes 
> it hard to diagnose without these extra probe points.
> It also explains why you don’t really see any drop counters 
> incrementing.
>
> The fact that this queue is full presumably means that the other side 
> is not reading packets off it any more.
> That’s supposed to happen in epair_start_locked() (Look for the 
> IFQ_DEQUEUE() calls).
>
> It’s not at all clear to my how, but it looks like the receive side 
> is not doing its work.
>
> It looks like the IFQ code is already a fallback for when the netisr 
> queue is full.
> That code might be broken, or there might be a different issue that 
> will just mean you’ll always end up in the same situation, 
> regardless of queue size.
>
> It’s probably worth trying to play with 
> ‘net.route.netisr_maxqlen’. I’d recommend *lowering* it, to see 
> if the problem happens more frequently that way. If it does it’ll be 
> helpful in reproducing and trying to fix this. If it doesn’t the 
> full queues is probably a consequence rather than a cause/trigger.
> (Of course, once you’ve confirmed that lowering the netisr_maxqlen 
> makes the problem more frequent go ahead and increase it.)

netstat -Q  will be useful


More information about the freebsd-net mailing list