On 2015/09/30 12:32, Martin Pieuchot wrote:
> > Could use some further testing of course.
>
> Tested on:
>
> em0 at pci1 dev 0 function 0 "Intel I210" rev 0x03: msi
> em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi
> em2 at pci0 dev 20 function 0 "Intel I354 SGMII" rev 0x03: msi
em1
On 28/09/15(Mon) 23:53, Mark Kettenis wrote:
> This diff makes the tx completion path run without the kernel lock
> held. With this change, the interrupt handler will not grab the
> kernel lock under normal circumstances. The diff follows the same
> approach as dlg@ took with vmx(4).
>
> The
On 2015 Sep 28 (Mon) at 23:53:13 +0200 (+0200), Mark Kettenis wrote:
:This diff makes the tx completion path run without the kernel lock
:held. With this change, the interrupt handler will not grab the
:kernel lock under normal circumstances. The diff follows the same
:approach as dlg@ took with
On 29.9.2015. 1:00, Hrvoje Popovski wrote:
> On 28.9.2015. 23:53, Mark Kettenis wrote:
>> This diff makes the tx completion path run without the kernel lock
>> held. With this change, the interrupt handler will not grab the
>> kernel lock under normal circumstances. The diff follows the same
>>
This diff makes the tx completion path run without the kernel lock
held. With this change, the interrupt handler will not grab the
kernel lock under normal circumstances. The diff follows the same
approach as dlg@ took with vmx(4).
The diff removes the code that tries to reclaim tx descriptors
On 28.9.2015. 23:53, Mark Kettenis wrote:
> This diff makes the tx completion path run without the kernel lock
> held. With this change, the interrupt handler will not grab the
> kernel lock under normal circumstances. The diff follows the same
> approach as dlg@ took with vmx(4).
>
> The diff
