public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Kurt Kanzenbach <kurt@linutronix.de>
To: Ferenc Fejes <fejes@inf.elte.hu>, netdev <netdev@vger.kernel.org>
Cc: Vinicius Costa Gomes <vinicius.gomes@intel.com>, hawk <hawk@kernel.org>
Subject: Re: igc: AF_PACKET and SO_TXTIME question
Date: Wed, 14 Feb 2024 15:51:45 +0100	[thread overview]
Message-ID: <87y1bn3xq6.fsf@kurt.kurt.home> (raw)
In-Reply-To: <bc2f28999c815b4562f7ce1ba477e7a9dc3af87d.camel@inf.elte.hu>

[-- Attachment #1: Type: text/plain, Size: 2322 bytes --]

Hi Ferenc,

On Wed Feb 14 2024, 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.

For what use cases does it not work? Are you running PREEMPT_RT? Just
asking out of curiosity :-).

> 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.

Well, yeah the code path looks good indeed. packet_snd() copies the
transmit time which is provided by the CMSG and calls into
packet_xmit(), dev_direct_xmit()...

>
> 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.

Maybe add some trace_printk()s to track what timestamps are actually
calculated in igc_tx_launchtime() and if it makes sense?

Second point to make sure is that the Tx queue your packet is being
transmitted to has Launch Time enabled.

>
> 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?

Not that I'm aware of.

>
> 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.

Is that already possible with AF_XDP? There were some patches on
xdp-hints, but i don't think it has been merged yet.

Thanks,
Kurt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

  parent reply	other threads:[~2024-02-14 14:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-14 14:00 igc: AF_PACKET and SO_TXTIME question Ferenc Fejes
2024-02-14 14:10 ` Ferenc Fejes
2024-02-14 14:51 ` Kurt Kanzenbach [this message]
2024-02-15  8:38   ` Ferenc Fejes
2024-02-16  7:16     ` Ferenc Fejes
2024-02-19  8:38       ` Kurt Kanzenbach

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y1bn3xq6.fsf@kurt.kurt.home \
    --to=kurt@linutronix.de \
    --cc=fejes@inf.elte.hu \
    --cc=hawk@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vinicius.gomes@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox