>
> 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
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
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
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:
[]
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 ---
>
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
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.
>
>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
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.
> >
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
>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
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
>
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
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:
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
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
16 matches
Mail list logo