ixgbe rx & tx locks

[Jack Vogel]

After looking at the code again I think this is just what's happening,
mq_start
will schedule the task when it can't get the lock (due to the interrupt
already
holding it presumeably), so you get the tasklet code in contention with the
interrupt.

Anyone with a clever notion of how to do things better?

Jack


On Mon, Aug 13, 2012 at 2:40 PM, Jack Vogel <jfvogel at gmail.com> wrote:

> Hmmm, this is odd, because the interrupt vector is not being re-enabled
> unless
> you are not scheduling the task, and when you are the interrupt isn't
> enabled til
> the end.... Something funny going on.
>
> You could get contention due to mq_start however, you sure about where its
> coming from?
>
> Jack
>
>
>
>
> On Mon, Aug 13, 2012 at 2:15 PM, Vijay Singh <vijju.singh at gmail.com>wrote:
>
>> Folks, I've been looking into lock contention on the ixgbe rx & tx locks.
>>
>> I have collected this data:
>>
>> debug.lock.prof.stats:
>>      max  wait_max       total  wait_total       count    avg wait_avg
>> cnt_hold cnt_lock name
>>      263       304     1329357      858873      322010      4      2
>> 0  45210 sys/dev/ixgbe/ixgbe.c:1349 (sleep mutex:e2a:tx(0))
>>      415       189    14314889       62933      739895     19      0
>> 0  13694 sys/dev/ixgbe/ixgbe.c:1445 (sleep mutex:e2a:tx(0))
>>
>> So the lock contention is coming from lock acquisitions in
>> ixgbe_handle_que() and ixgbe_msix_que().
>>
>> I am unable to understand why, since I would not expect the deferred
>> task to execute in parallel with the msix interrupt handler.
>>
>> rx is similar:
>>
>> debug.lock.prof.stats:
>>      max  wait_max       total  wait_total       count    avg wait_avg
>> cnt_hold cnt_lock name
>>       88       893      672058      269855      821847      0      0
>> 0    753 sys/dev/ixgbe/ixgbe.c:4211 (sleep mutex:e6b:rx(0))
>>      893        25     3994289        1937     1093238      3      0
>> 0    561 sys/dev/ixgbe/ixgbe.c:4276 (sleep mutex:e6b:rx(0))
>>
>> Any thoughts?
>>
>> -vijay
>> _______________________________________________
>> freebsd-net at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>
>
>