On Thu, Dec 04, 2025 at 10:09:47AM +0800, Song Yoong Siang wrote:
> Improve the launch time calculation logic to handle different scenarios:
> - Set launch time to 0 if txtime has expired.
> - Set launch time to 0 if txtime exceeds the horizon (beyond the end of
> the next Qbv cycle).
> - Mark the first flag in the context descriptor when the packet is the
> first one scheduled in the next Qbv cycle.
> - Create a dummy packet to dirty the current cycle before sending
> packets intended for the next Qbv cycle.
>
> Testing was performed on two Intel ADL-S platforms with i226 NICs
> connected back-to-back. A DPDK sample application is created to send 10
> UDP packets with 20,000 nanosecond intervals and their txtime is set to
> the time of the next Qbv cycle. Meanwhile, the tcpdump command below is
> used on the link partner to capture the delta of Rx hardware timestamp
> of the 10 packets:
>
> tcpdump -ttt -ni enp1s0 --time-stamp-precision=nano -j adapter_unsynced
>
> Without this patch, packets are transmitted immediately as the hardware
> interprets their launch time as expired, resulting in 8,384 nanosecond
> intervals (wire speed for 1024-byte packets at 1Gbps), as shown in
> tcpdump log below:
>
> 00:00:00.000000000 IP 192.168.1.100.2 > 224.1.1.1.5: UDP, length 982
> 00:00:00.000008384 IP 192.168.1.100.2 > 224.1.1.1.5: UDP, length 982
> 00:00:00.000008384 IP 192.168.1.100.2 > 224.1.1.1.5: UDP, length 982
> 00:00:00.000008384 IP 192.168.1.100.2 > 224.1.1.1.5: UDP, length 982
> 00:00:00.000008384 IP 192.168.1.100.2 > 224.1.1.1.5: UDP, length 982
> 00:00:00.000008384 IP 192.168.1.100.2 > 224.1.1.1.5: UDP, length 982
> 00:00:00.000008384 IP 192.168.1.100.2 > 224.1.1.1.5: UDP, length 982
> 00:00:00.000008384 IP 192.168.1.100.2 > 224.1.1.1.5: UDP, length 982
> 00:00:00.000008384 IP 192.168.1.100.2 > 224.1.1.1.5: UDP, length 982
> 00:00:00.000008384 IP 192.168.1.100.2 > 224.1.1.1.5: UDP, length 982
>
> With this patch, packets are properly held until the next Qbv cycle and
> transmitted at the intended 20,000 nanosecond intervals, demonstrating
> correct launch time behavior, as shown in tcpdump log below:
>
> 00:00:00.000000000 [|llc]
> 00:00:00.000862592 IP 192.168.1.100.2 > 224.1.1.1.5: UDP, length 982
> 00:00:00.000019993 IP 192.168.1.100.2 > 224.1.1.1.5: UDP, length 982
> 00:00:00.000020000 IP 192.168.1.100.2 > 224.1.1.1.5: UDP, length 982
> 00:00:00.000020010 IP 192.168.1.100.2 > 224.1.1.1.5: UDP, length 982
> 00:00:00.000019997 IP 192.168.1.100.2 > 224.1.1.1.5: UDP, length 982
> 00:00:00.000020000 IP 192.168.1.100.2 > 224.1.1.1.5: UDP, length 982
> 00:00:00.000020003 IP 192.168.1.100.2 > 224.1.1.1.5: UDP, length 982
> 00:00:00.000019990 IP 192.168.1.100.2 > 224.1.1.1.5: UDP, length 982
> 00:00:00.000020000 IP 192.168.1.100.2 > 224.1.1.1.5: UDP, length 982
> 00:00:00.000020000 IP 192.168.1.100.2 > 224.1.1.1.5: UDP, length 982
>
> Fixes: 9630f7c71ecd ("net/igc: enable launch time offloading")
> Cc: [email protected]
>
> Signed-off-by: David Zage <[email protected]>
> Signed-off-by: Song Yoong Siang <[email protected]>
> ---
Acked-by: Bruce Richardson <[email protected]>
Applied to dpdk-next-net-intel.
Thanks,
/Bruce
