Re: This is the fourth time I’ve tried to find what led to the regression of outgoing network speed and each time I find the merge commit 8c94ccc7cd691472461448f98e2372c75849406c

From: Jakub Kicinski
Date: Fri Feb 02 2024 - 21:33:08 EST

Next message: Wesley Cheng: "[PATCH v13 01/53] xhci: fix possible null pointer dereference at secondary interrupter removal"
Previous message: David Rientjes: "Re: [PATCH v2] iommu/iova: use named kmem_cache for iova magazines"
In reply to: Randy Dunlap: "Re: This is the fourth time I’ve tried to find what led to the regression of outgoing network speed and each time I find the merge commit 8c94ccc7cd691472461448f98e2372c75849406c"
Next in thread: Christian A. Ehrhardt: "Re: This is the fourth time I’ve tried to find what led to the regression of outgoing network speed and each time I find the merge commit 8c94ccc7cd691472461448f98e2372c75849406c"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Thanks for the forward!

On Fri, 2 Feb 2024 17:16:41 -0800 Randy Dunlap wrote:
> >> When I copy files from one computer to another and kernel snapshot
> >> builded from commit 296455ade1fd I have 97-110MB/sec which is almost
> >> max speed of 1Gbps link.
> >> When I move to commit 9d1694dc91ce I have only 66-70MB/sec which is
> >> significantly slower.

There isn't that much networking in between the two.
Is any of the CPU cores at 100% when you are transferring the data on
the bad commit?
Do you have any iptables / nftables rules?
Are you using TLS in the transfer?
Did you try reverting f1172f3ee3a98754?