netdev - igc: AF_PACKET and SO

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]

Date: Wed, 14 Feb 2024 15:00:04 +0100
From: Ferenc Fejes <fejes@....elte.hu>
To: netdev <netdev@...r.kernel.org>
Cc: Vinicius Costa Gomes <vinicius.gomes@...el.com>, Kurt Kanzenbach
	 <kurt@...utronix.de>, hawk <hawk@...nel.org>
Subject: igc: AF_PACKET and SO_TXTIME question

Hi,

We are experimenting with scheduled packet transfers using the
AF_PACKET socket. There is the ETF disk, which is great for most cases.
When we bypassed ETF, everything seemed ok regarding the timing: our
packet received about +/-15ns offset at the receiver (now its the same
machine just to make sure with the timesync) compared to the timestamp
set with SO_TXTIME CMSG.

What we tried now is to bypass the ETF qdisc. We enabled the ETF qdisc
with hardware offload and sent the exact same packets, but this time
with PACKET_QDISC_BAYPASS enabled on the AF_PACKET socket. The codepath
looks good, the qdisc part is not called, the packet_snd calls the
dev_direct_xmit which calls the igc_xmit_frame. However, in this case
the packet was sent more or less immediately.

I wonder why we do not see the delayed sending in this case? We tried
with different offsets (e.g. 0.1, 0.01, 0.001 sec in the future) but we
received the packet after 20-30usec every time. I cant see any code
that touches the skb timestamp after the packet_snd, so I suspect that
the igc_xmit_frame sees the same timestamp that it would see in the
non-baypass case.

I happen to have the i225 user manual, but after some grep I cannot
find any debug registers or counters to monitor the behavior of the
scheduled transmission (scheduling errors or bad timestamps, etc.). Are
there any?

I am afraid this issue might also be relevant for the AF_XDP case,
which also hooks after the qdisc layer, so the launchtime (or whatever
it is called) is handled directly by the igc driver.

Best,
Ferenc