netdev - Re: [PATCH net-next 09/12] net: homa: create 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGXJAmypjTj1udx4x5i1Y0mxrTeWQJKUuGmR=4qiE-ky3Tc-ow@mail.gmail.com>
Date: Tue, 29 Oct 2024 21:30:33 -0700
From: John Ousterhout <ouster@...stanford.edu>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH net-next 09/12] net: homa: create homa_outgoing.c

On Tue, Oct 29, 2024 at 5:42 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> > +/**
> > + * homa_check_nic_queue() - This function is invoked before passing a packet
> > + * to the NIC for transmission. It serves two purposes. First, it maintains
> > + * an estimate of the NIC queue length. Second, it indicates to the caller
> > + * whether the NIC queue is so full that no new packets should be queued
> > + * (Homa's SRPT depends on keeping the NIC queue short).
> > + * @homa:     Overall data about the Homa protocol implementation.
> > + * @skb:      Packet that is about to be transmitted.
> > + * @force:    True means this packet is going to be transmitted
> > + *            regardless of the queue length.
> > + * Return:    Nonzero is returned if either the NIC queue length is
> > + *            acceptably short or @force was specified. 0 means that the
> > + *            NIC queue is at capacity or beyond, so the caller should delay
> > + *            the transmission of @skb. If nonzero is returned, then the
> > + *            queue estimate is updated to reflect the transmission of @skb.
>
> You might want to look into BQL. What you have here i assume only
> takes into account homa traffic. BQL, being in the NIC itself, will
> tell you about all other traffic as well.

Thanks for the pointer; I hadn't heard of BQL before, but I found this
page on it:

https://lwn.net/Articles/469652/

It sounds like this is the same mechanism that includes dynamic queue
limits and the NETDEV_TX_BUSY return value from drivers? If so, I am
familiar with that mechanism, though I hadn't heard the name "BQL".
Unfortunately, it isn't very accurate: it treats data as queued until
skbs are returned from the NIC back to Linux, which can take 100 us or
more. In contrast, homa_check_nic_queue has a time granularity of a
few microseconds (delays of 100 us for short Homa messages would be
cause for concern).

But you are right that this doesn't consider non-Homa traffic, and
that is a problem when Homa runs concurrently with TCP. I am just
starting work on a new qdisc that will replace this mechanism and
incorporate traffic from non-Homa sources as well as Homa.

-John-