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

Date: Wed, 14 Feb 2024 15:10: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: Re: igc: AF_PACKET and SO_TXTIME question

Small correction

On Wed, 2024-02-14 at 15:00 +0100, Ferenc Fejes wrote:
> 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

this was meant to be "when we NOT bypassed"

> 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