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

Message-ID: <20230616173138.dcbdenbpvba7cf3k@zenon.in.qult.net>
Date: Fri, 16 Jun 2023 19:31:38 +0200
From: Ignacy Gawedzki <ignacy.gawedzki@...en-communications.fr>
To: netdev@...r.kernel.org
Subject: Is EDT now expected to work with any qdisc?

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.

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?

I would be very grateful if someone knowledgeable could enlighten me.

Thanks in advance for your help.

Cheers,

Ignacy