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

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 put this off as not

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

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

> > 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 linux-kernel"

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

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

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

>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

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

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

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

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

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

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

> > 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 linux-kernel"

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

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

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

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

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

>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

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

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

>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

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 > will be same for other

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

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

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

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

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: Cavium ThunderX CN88XX board (DT) Call trace: []

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

>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

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 >

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

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

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: Cavium ThunderX CN88XX board (DT) Call trace: []

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

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