netdev - Re: [PATCH net-next v10 4/7] net: tn40xx: add basic Tx handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20240617.144427.323441716293852123.fujita.tomonori@gmail.com>
Date: Mon, 17 Jun 2024 14:44:27 +0900 (JST)
From: FUJITA Tomonori <fujita.tomonori@...il.com>
To: andrew@...n.ch
Cc: fujita.tomonori@...il.com, hfdevel@....net, kuba@...nel.org,
 netdev@...r.kernel.org, horms@...nel.org, jiri@...nulli.us,
 pabeni@...hat.com, linux@...linux.org.uk, naveenm@...vell.com,
 jdamato@...tly.com
Subject: Re: [PATCH net-next v10 4/7] net: tn40xx: add basic Tx handling

On Sun, 16 Jun 2024 16:59:22 +0200
Andrew Lunn <andrew@...n.ch> wrote:

>> > I did wounder if calculating the value as needed would be any
>> > slower/faster than doing a table access. Doing arithmetic is very
>> > cheap compared to a cache miss for a table lookup. Something which
>> > could be bench marked and optimised later.
>> 
>> Indeed, that might be faster. I'll drop the table in the next
>> version. I'll put that experiment on my to-do list.
> 
> I would generally recommend getting something merged, and then
> optimise it. This could be in the noise, it makes no real difference.
> By getting code merged, you make it easier for others to contribute to
> this driver, and there does appear to be others who would like to work
> on this code.

Fully agreed. I want to get the driver merged soon.

I thought that calculating the values as needed is the simplest
approach, then others could optimize it with the table.

What needs to be addressed before merged is if the driver uses the
table, it needs to be initialized before the PCI probe. Seems that
there are three options:

1) initializing the table in module_init.

2) embedding the calculated values (as Hans suggested).

3) calculating the values as needed instead of using the table.

Which one were you thinking? I have no preference here.