RE: [PATCH net-next v8 3/6] idpf: support pacing offload

Loktionov, Aleksandr wrote:

quoted

-----Original Message-----
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Sent: Wednesday, September 2, 2026 8:17 PM
To: netdev@vger.kernel.org
Cc: davem@davemloft.net; kuba@kernel.org; edumazet@google.com;
pabeni@redhat.com; horms@kernel.org; andrew+netdev@lunn.ch; Willem de
Bruijn [off-list ref]; Nguyen, Anthony L
[off-list ref]; Kitszel, Przemyslaw
[off-list ref]; Hay, Joshua A
[off-list ref]; intel-wired-lan@lists.osuosl.org
Subject: [PATCH net-next v8 3/6] idpf: support pacing offload

From: Willem de Bruijn <willemb@google.com>

If skb->tstamp is in the future, program this future delivery txtime
in the transmit descriptor.

TCP pacing offload is only offloaded if SK_PACING_FQ is negotiated and
the FQ offload_horizon is configured. But device support for pacing
offload must be more robust: it can also be reached through SO_TXTIME.

Bounds check txtime. Only packets with timestamp between now and the
horizon (pacing_offload_horizon) are offloaded.

Negotiate the feature with the device using virtchnl. Support is
conditional on
- splitq mode, where tx and tx completion queues are separate, so
  completions can be returned out of order.
- flow scheduling mode, where completions can arrive out of order.
- PTP to ensure the NIC clock is synced to CLOCK_TAI.

These features are negotiated per adapter, but expect all vports to
uniformly request splitq (req_[rt]x_splitq) and flow scheduling
(flow_sch_en) when available.

Do not explicitly check all preconditions. Trust the firmware to only
advertise EDT when all are met. In general, firmware response is
trusted to be correct. If not, EDT would be the least of the worries.
In particular, granularity is trusted to be a power of two. And
time_horizon_ns is a range expressible given the chosen granularity.

Packets beyond the horizon are sent immediately with the overflow bit
set.

On device reset, dev->pacing_offload_horizon, fq offload_horizon and
granularity are not re-negotiated. It is safe to assume that firmware
does not change these EDT capabilities across resets.

Must not be called from netpoll due to ktime_get. But netpoll does not
generate packets with EDT, so no explicit test is needed.

Do not fail device initialization on EDT init error. Log an error, but
continue without EDT, similar to PTP.

Cc: Tony Nguyen <anthony.l.nguyen@intel.com>
Cc: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Cc: Joshua A Hay <redacted>
Cc: intel-wired-lan@lists.osuosl.org
Signed-off-by: Willem de Bruijn <willemb@google.com>

---

Changes
  v7 -> v8
    - remove unused variable np in idpf_tx_splitq_set_txtime
  v6 -> v7
    - rebase onto libie changes: adjust idpf_send_get_edt_caps_msg
    - only set horizon if splitq with flow scheduling
    - fail on illegal granularity 0, rather than use hardcoded default
    - zero edt_caps on negotation error, in case of call after reset

negotation -> negotiation

Fixed
 

Reviewed-by: Aleksandr Loktionov <redacted>

Thanks for the review Aleksandr!

I did not keep the Reviewed-by as sticky, because the patch saw some
changes in v9. 

https://lore.kernel.org/netdev/20260910171131.2532487-5-willemdebruijn.kernel@gmail.com/T/#u (local)