netdev - Re: [PATCH net-next v8 08/15] net: homa: create homa_pacer.h and homa

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] [day] [month] [year] [list]

Message-ID: <9e4b56fd-425b-424a-b89a-57d7efc05a30@redhat.com>
Date: Thu, 22 May 2025 09:49:22 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: John Ousterhout <ouster@...stanford.edu>, Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, edumazet@...gle.com, horms@...nel.org,
 kuba@...nel.org
Subject: Re: [PATCH net-next v8 08/15] net: homa: create homa_pacer.h and
 homa_pacer.c

On 5/7/25 10:46 PM, John Ousterhout wrote:
> get_link_ksettings is what I was thinking of. 

Note that dst->dev and the actual egress link could be different. The
first could be a virtual/stacked device or many kind of redirections
could be in place.

> Some of the issues you
> mentioned, such as switch egress contention, are explicitly handled by
> Homa, so those needn't (and shouldn't) be factored into the link
> "speed". And don't pretty much all modern datacenter switches allow
> all of their links to operate at full speed?

If you mean negotiating the link speed, likely yes.

If you mean actually allowing the connected peer to send data at link
speed and forwarding it without packet loss across the switch, no. i.e.
if 2 or more ports are sending traffic at full speed towards a 3rd one :)

Side note: please avoid top posting.

Thanks,

Paolo