[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <06ac1128-92dc-4330-a68b-ae29dfd7105e@alu.unizg.hr>
Date: Tue, 31 Oct 2023 14:27:00 +0100
From: Mirsad Todorovac <mirsad.todorovac@....hr>
To: Andrew Lunn <andrew@...n.ch>,
Mirsad Todorovac <mirsad.todorovac@....unizg.hr>
Cc: Heiner Kallweit <hkallweit1@...il.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, nic_swsd@...ltek.com,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Marco Elver <elver@...gle.com>
Subject: Re: [PATCH v3 1/1] r8169: Coalesce RTL8411b PHY power-down recovery
programming instructions to reduce spinlock stalls
On 10/31/2023 1:38 PM, Andrew Lunn wrote:
> On Tue, Oct 31, 2023 at 04:35:19AM +0100, Mirsad Todorovac wrote:
>> On 10/31/23 02:21, Andrew Lunn wrote:
>>>> I will not contradict, but the cummulative amount of memory barriers on each MMIO read/write
>>>> in each single one of the drivers could amount to some degrading of overall performance and
>>>> latency in a multicore system.
>>>
>>> For optimisations, we like to see benchmark results which show some
>>> improvements. Do you have any numbers?
>>
>> Hi, Andrew,
>>
>> Thank you for your interest in RTL NIC driver optimisations.
>>
>> My knowledge about the timing costs of synchronisation is mostly theoretical.
>
> The kernel tends to be very practical. Maybe try to turn the
> theoretical knowledge into practice. Write a benchmark test, or see if
> any of the existing RT Linux tests show there is a real problem here,
> and your changes fix it.
I stand corrected. Real benchmarks would indeed say more than the visual
inspection of the code.
As I see, as a maintainer of the PHYLIB you certainly have a greater
insight. What I've done is maybe too aggressive "loophole optimisation",
without much consideration of what Mr. Heiner Kallweit addressed as hot
paths and not so hot (less trodden) paths.
Best regards,
Mirsad Todorovac
Powered by blists - more mailing lists