Re: interface queue transmit mitigation (again)

2018-04-28 Thread Hrvoje Popovski
On 28.3.2018. 11:42, Hrvoje Popovski wrote: > On 28.3.2018. 3:28, David Gwynne wrote: >> On Thu, Mar 15, 2018 at 03:25:46PM +0100, Martin Pieuchot wrote: >>> On 14/03/18(Wed) 13:00, David Gwynne wrote: this adds transmit mitigation back to the tree. it is basically the same diff as

Re: interface queue transmit mitigation (again)

2018-04-01 Thread Hrvoje Popovski
On 28.3.2018. 11:42, Hrvoje Popovski wrote: > Hi all, > > with this diff i'm getting 1.43Mpps on > 12 x Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 2400.01 MHz > > with plain kernel i'm getting 1.12Mpps and with older diff's i was > getting 1.31Mpps ... On box with 6 x Intel(R) Xeon(R) CPU

Re: interface queue transmit mitigation (again)

2018-03-28 Thread Hrvoje Popovski
On 28.3.2018. 3:28, David Gwynne wrote: > On Thu, Mar 15, 2018 at 03:25:46PM +0100, Martin Pieuchot wrote: >> On 14/03/18(Wed) 13:00, David Gwynne wrote: >>> this adds transmit mitigation back to the tree. >>> >>> it is basically the same diff as last time. the big difference this >>> time is that

Re: interface queue transmit mitigation (again)

2018-03-28 Thread Martin Pieuchot
On 28/03/18(Wed) 11:28, David Gwynne wrote: > On Thu, Mar 15, 2018 at 03:25:46PM +0100, Martin Pieuchot wrote: > > On 14/03/18(Wed) 13:00, David Gwynne wrote: > > > this adds transmit mitigation back to the tree. > > > > > > it is basically the same diff as last time. the big difference this > >

Re: interface queue transmit mitigation (again)

2018-03-27 Thread Michael Price
On Tue, Mar 27, 2018 at 9:30 PM David Gwynne wrote: > On Thu, Mar 15, 2018 at 03:25:46PM +0100, Martin Pieuchot wrote: > > On 14/03/18(Wed) 13:00, David Gwynne wrote: > > > this adds transmit mitigation back to the tree. > > > > > > it is basically the same diff as last time.

Re: interface queue transmit mitigation (again)

2018-03-27 Thread David Gwynne
On Thu, Mar 15, 2018 at 03:25:46PM +0100, Martin Pieuchot wrote: > On 14/03/18(Wed) 13:00, David Gwynne wrote: > > this adds transmit mitigation back to the tree. > > > > it is basically the same diff as last time. the big difference this > > time is that all the tunnel drivers all defer

Re: interface queue transmit mitigation (again)

2018-03-15 Thread Martin Pieuchot
On 14/03/18(Wed) 13:00, David Gwynne wrote: > this adds transmit mitigation back to the tree. > > it is basically the same diff as last time. the big difference this > time is that all the tunnel drivers all defer ip_output calls, which > avoids having to play games with NET_LOCK in the ifq

interface queue transmit mitigation (again)

2018-03-13 Thread David Gwynne
this adds transmit mitigation back to the tree. it is basically the same diff as last time. the big difference this time is that all the tunnel drivers all defer ip_output calls, which avoids having to play games with NET_LOCK in the ifq transmit paths. tests? ok? Index: ifq.c