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

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

Loktionov, Aleksandr wrote:
> 
> 
> > -----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 <willemb@google.com>; Nguyen, Anthony L
> > <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> > <przemyslaw.kitszel@intel.com>; Hay, Joshua A
> > <joshua.a.hay@intel.com>; 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 <joshua.a.hay@intel.com>
> > 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 <aleksandr.loktionov@intel.com>

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