Re: [PATCH 3/6] net: thunderx: Increase transmit queue length

2015-12-02 Thread Sunil Kovvuri
> > If the performance increase is 4 %, then surely using twice more memory > is not worth it. I haven't mentioned anywhere that i am seeing 4% increase in performance. Anyways as said already i will recheck and resubmit. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the

Re: [PATCH 3/6] net: thunderx: Increase transmit queue length

2015-12-02 Thread David Miller
From: Sunil Kovvuri Date: Wed, 2 Dec 2015 11:18:43 +0530 >>The driver should successfully recover from out of memory situations >> and not stop RX/TX completely. > This memory allocation is while interface bringup/initialization and not > during > packet I/O. > >>Don't

Re: [PATCH 3/6] net: thunderx: Increase transmit queue length

2015-12-02 Thread Eric Dumazet
On Wed, 2015-12-02 at 22:20 +0530, Sunil Kovvuri wrote: > > > > If the performance increase is 4 %, then surely using twice more memory > > is not worth it. > I haven't mentioned anywhere that i am seeing 4% increase in performance. Yes, this is the complain I made : No numbers, just a patch

RE: [PATCH 3/6] net: thunderx: Increase transmit queue length

2015-12-02 Thread Pavel Fedin
Hello! > Probably you might have to set "coherent_pool" size in bootargs to a > higher value. > Can you please check. I have tried to do this. I was able to enlarge the pool up to 4MB, and still got allocation failures. At 8MB pool preallocation stops working: --- cut --- Call trace: []

RE: [PATCH 3/6] net: thunderx: Increase transmit queue length

2015-12-02 Thread Pavel Fedin
Hello! > > Probably you might have to set "coherent_pool" size in bootargs to a > > higher value. > > Can you please check. > > I have tried to do this. I was able to enlarge the pool up to 4MB, and still > got allocation > failures. At 8MB pool preallocation stops working: > --- cut --- >

RE: [PATCH 3/6] net: thunderx: Increase transmit queue length

2015-12-02 Thread Pavel Fedin
Hello! > > swiotlb: coherent allocation failed for device 0002:01:08.4 size=4198400 > > CPU: 2 PID: 3655 Comm: NetworkManager Tainted: GW O4.2.6+ #201 > > Hardware name: Cavium ThunderX CN88XX > > Are you sure 4.2.6 kernel is suitable for backporting this patch aimed > for

RE: [PATCH 3/6] net: thunderx: Increase transmit queue length

2015-12-02 Thread Pavel Fedin
Hello! > > So, i see several possible ways to solve this: > > > > 1. Introduce some mechanism which would allow the driver to tell the kernel > > that it needs > > coherent pool of large size. Can be problematic because the driver can be a > > module, and pool > > allocation happens early. >

Re: [PATCH 3/6] net: thunderx: Increase transmit queue length

2015-12-02 Thread Sunil Kovvuri
>After getting it working in guest i tried to apply it to host. With total of >128 virtual functions (= 128 interfaces) it does not work at all. > Even after bumping cma region size to insane value of 2GB more than half of > interfaces still failed to allocate queues. > And after setting cma=3G

RE: [PATCH 3/6] net: thunderx: Increase transmit queue length

2015-12-02 Thread Pavel Fedin
Hello! > >After getting it working in guest i tried to apply it to host. With total of > >128 virtual > functions (= 128 interfaces) it does not work at all. > > Even after bumping cma region size to insane value of 2GB more than half of > > interfaces still > failed to allocate queues. > >

Re: [PATCH 3/6] net: thunderx: Increase transmit queue length

2015-12-02 Thread Eric Dumazet
On Wed, 2015-12-02 at 11:18 +0530, Sunil Kovvuri wrote: > >The driver should successfully recover from out of memory situations > > and not stop RX/TX completely. > This memory allocation is while interface bringup/initialization and not > during > packet I/O. > > >Don't put this off as not

Re: [PATCH 3/6] net: thunderx: Increase transmit queue length

2015-12-01 Thread Sunil Kovvuri
>The driver should successfully recover from out of memory situations > and not stop RX/TX completely. This memory allocation is while interface bringup/initialization and not during packet I/O. >Don't put this off as not "related" to your patch, it is as this >introduces the behavior for this

Re: [PATCH 3/6] net: thunderx: Increase transmit queue length

2015-12-01 Thread David Miller
From: Sunil Kovvuri Date: Tue, 1 Dec 2015 22:00:49 +0530 > Increasing descriptor ring size will lead to more memory allocation. > And what you are seeing is a memory alloc failure and doesn't seem > to be due to this driver change. I mean it looks like the behavior >

[PATCH 3/6] net: thunderx: Increase transmit queue length

2015-12-01 Thread Sunil Goutham
From: Sunil Goutham Under high transmit rates and with TSO enabled observing fluctuations in TX performance. Seen especially with iperf3 application. Since TSO is taken care at driver level, with 64KB of TSO packets and when window size is also high the rate at which CPU

Re: [PATCH 3/6] net: thunderx: Increase transmit queue length

2015-12-01 Thread Eric Dumazet
On Tue, 2015-12-01 at 17:40 +0300, Pavel Fedin wrote: > Hello! > > This one breaks networking on my machine: > --- cut --- > swiotlb: coherent allocation failed for device 0002:01:08.4 size=4198400 > CPU: 2 PID: 3655 Comm: NetworkManager Tainted: GW O4.2.6+ #201 > Hardware name:

RE: [PATCH 3/6] net: thunderx: Increase transmit queue length

2015-12-01 Thread Pavel Fedin
ut...@caviumnetworks.com; Sunil Goutham > Subject: [PATCH 3/6] net: thunderx: Increase transmit queue length > > From: Sunil Goutham <sgout...@cavium.com> > > Under high transmit rates and with TSO enabled observing fluctuations > in TX performance. Seen especially with

Re: [PATCH 3/6] net: thunderx: Increase transmit queue length

2015-12-01 Thread Sunil Kovvuri
Hi Pavel Fedin, Increasing descriptor ring size will lead to more memory allocation. And what you are seeing is a memory alloc failure and doesn't seem to be due to this driver change. I mean it looks like the behavior will be same for other drivers as well. Probably you might have to set