[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d4cc1576-f4c3-a074-9bf4-937cdd3ff56d@nvidia.com>
Date: Wed, 23 Aug 2023 17:43:27 +0300
From: Gal Pressman <gal@...dia.com>
To: David Ahern <dsahern@...nel.org>,
Richard Gobert <richardbgobert@...il.com>, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
aleksander.lobakin@...el.com, lixiaoyan@...gle.com, lucien.xin@...il.com,
alexanderduyck@...com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/1] gro: decrease size of CB
On 28/06/2023 17:19, David Ahern wrote:
> On 6/28/23 6:42 AM, Gal Pressman wrote:
>> On 27/06/2023 17:21, David Ahern wrote:
>>> On 6/26/23 2:55 AM, Gal Pressman wrote:
>>>> I believe this commit broke gro over udp tunnels.
>>>> I'm running iperf tcp traffic over geneve interfaces and the bandwidth
>>>> is pretty much zero.
>>>>
>>>
>>> Could you add a test script to tools/testing/selftests/net? It will help
>>> catch future regressions.
>>>
>>
>> I'm checking internally, someone from the team might be able to work on
>> this, though I'm not sure that a test that verifies bandwidth makes much
>> sense as a selftest.
>>
>
> With veth and namespaces I expect up to 25-30G performance levels,
> depending on the test. When something fundamental breaks like this patch
> a drop to < 1G would be a red flag, so there is value to the test.
Circling back to this, I believe such test already exists:
tools/testing/selftests/net/udpgro_fwd.sh
And it indeed fails before Richard's fix.
I guess all that's left is to actually run these tests :)?
Powered by blists - more mailing lists