Loktionov, Aleksandr wrote: > > > > -----Original Message----- > > From: Willem de Bruijn <[email protected]> > > Sent: Wednesday, September 2, 2026 8:17 PM > > To: [email protected] > > Cc: [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected]; Willem de > > Bruijn <[email protected]>; Nguyen, Anthony L > > <[email protected]>; Kitszel, Przemyslaw > > <[email protected]>; Hay, Joshua A > > <[email protected]>; [email protected] > > Subject: [PATCH net-next v8 3/6] idpf: support pacing offload > > > > From: Willem de Bruijn <[email protected]> > > > > 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 <[email protected]> > > Cc: Przemek Kitszel <[email protected]> > > Cc: Joshua A Hay <[email protected]> > > Cc: [email protected] > > Signed-off-by: Willem de Bruijn <[email protected]> > > > > --- > > > > 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 <[email protected]> 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/[email protected]/T/#u
