netdev - Re: Is EDT now expected to work with any qdisc?

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]

Date: Sun, 18 Jun 2023 15:52:35 -0700
From: Cong Wang <xiyou.wangcong@...il.com>
To: Ignacy Gawedzki <ignacy.gawedzki@...en-communications.fr>
Cc: netdev@...r.kernel.org
Subject: Re: Is EDT now expected to work with any qdisc?

On Fri, Jun 16, 2023 at 07:31:38PM +0200, Ignacy Gawedzki wrote:
> Hi,
> 
> I've been lately playing around with setting tstamp in BPF in clsact,
> in order to pace some traffic, both locally generated and forwarded.
> 
> All the code examples I could find suggest that this mangling of tstamp
> will only work if the fq qdisc is set on the network interface.  But
> my experiments seem to indicate that regardless of the actual qdisc,
> be it fq, fq_codel, pfifo_fast, or even noqueue, the delivery time set
> in tstamp is always honored, both in sending (output) and forwarding,
> with any actual network interface driver I tried.

Scheduling packets in an order is the responsibility of Qdisc, it is
generic, does not define any specific order. So whether ordering packets
by tstamp is Qdisc-specific.

> 
> I tried very hard to find a confirmation of my hypothesis in the
> kernel sources, but after three days of continuous searching for
> answers, I'm starting to feel I'm missing something here.
> 
> So is it so that this requested delivery time is honored before the
> packet is handed over to the qdisc or the driver?  Or maybe nowadays
> pretty much every driver (including veth) honors that delivery time
> itself?

It depends. Some NIC (and its driver) can schedule packets based on
tstamp too, otherwise we have to rely on the software layer (Qdisc
layer) to do so.

Different Qdisc's have different logics to schedule packets, not all
of them use tstamp to order and schedule packets. This is why you have
to pick a particular one, like fq, to get the logic you expect.

Thanks.