[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXJAmxbtj7x78KYNBWoZaCHbOf39ekeHQUX2bMZsipXUCau_Q@mail.gmail.com>
Date: Wed, 7 May 2025 11:55:23 -0700
From: John Ousterhout <ouster@...stanford.edu>
To: Paolo Abeni <pabeni@...hat.com>
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
In Tue, May 6, 2025 at 7:05 AM Paolo Abeni <pabeni@...hat.com> wrote:
>
> On 5/3/25 1:37 AM, John Ousterhout wrote:
> > + /**
> > + * @link_mbps: The raw bandwidth of the network uplink, in
> > + * units of 1e06 bits per second. Set externally via sysctl.
> > + */
> > + int link_mbps;
>
> This is will be extremely problematic. In practice nobody will set this
> correctly and in some cases the info is not even available (VM) or will
> change dynamically due to policing/shaping.
>
> I think you need to build your own estimator of the available B/W. I'm
> unsure/I don't think you can re-use bql info here.
I agree about the issues, but I'd like to defer addressing them. I
have begun working on a new Homa-specific qdisc, which will improve
performance when there is concurrent TCP and Homa traffic. It
retrieves link speed from the net_device, which will eliminate the
need for the link_mbps configuration option. Hopefully this will be
ready by the time Homa upstreaming is complete.
There are additional issues that the qdisc will not address, such as
VMs. VMs raise a bunch of complications for Homa, because Homa
believes that it sees all of the traffic going out on the uplink (so
that it can pace properly) and this isn't the case in VMs. Again, I'd
like to defer dealing with this.
-John-
Powered by blists - more mailing lists