Remove this trivial bit of inefficiency from the rx receive loop,
results in increase of a few Mbps in iperf3. Tested on Intel Core2
platform.
Signed-off-by: Sieng Piaw Liew <redacted>
---
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
On Fri, Mar 19, 2021 at 12:04:47PM +0800, Sieng Piaw Liew wrote:
quoted hunk
Remove this trivial bit of inefficiency from the rx receive loop,
results in increase of a few Mbps in iperf3. Tested on Intel Core2
platform.
Signed-off-by: Sieng Piaw Liew <redacted>
---
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
It should not change anything, or only based on the compiler's optimization
and should not result in a measurable difference because what it does is
exactly the same. Have you really compared the compiled output code to
explain the difference ? I strongly suspect you'll find no difference at
all.
Thus for me it's certainly not an optimization, it could be qualified as
a cleanup to improve code readability however.
Willy
On Fri, Mar 19, 2021 at 05:15:35AM +0100, Willy Tarreau wrote:
On Fri, Mar 19, 2021 at 12:04:47PM +0800, Sieng Piaw Liew wrote:
quoted
Remove this trivial bit of inefficiency from the rx receive loop,
results in increase of a few Mbps in iperf3. Tested on Intel Core2
platform.
Signed-off-by: Sieng Piaw Liew <redacted>
---
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
It should not change anything, or only based on the compiler's optimization
and should not result in a measurable difference because what it does is
exactly the same. Have you really compared the compiled output code to
explain the difference ? I strongly suspect you'll find no difference at
all.
Thus for me it's certainly not an optimization, it could be qualified as
a cleanup to improve code readability however.
Willy
You're right. Objdump and diff showed no difference.
Regards,
Sieng Piaw