On Wed, Feb 11, 2026 at 10:17:34AM +0100, Burakov, Anatoly wrote: > On 2/10/2026 6:40 PM, Bruce Richardson wrote: > > On Tue, Feb 10, 2026 at 01:42:17PM +0100, Burakov, Anatoly wrote: > > > On 2/9/2026 5:45 PM, Bruce Richardson wrote: > > > > Create a single function to manage all context descriptor handling, > > > > which returns either 0 or 1 depending on whether a descriptor is needed > > > > or not, as well as returning directly the descriptor contents if > > > > relevant. > > > > > > > > Signed-off-by: Bruce Richardson <[email protected]> > > > > --- > > > > > > <snip> > > > > > > > +static __rte_always_inline uint16_t > > > > +get_context_desc(uint64_t ol_flags, const struct rte_mbuf *tx_pkt, > > > > + const union ci_tx_offload *tx_offload, const struct ci_tx_queue > > > > *txq, > > > > + uint64_t *qw0, uint64_t *qw1) > > > > +{ > > > > + uint16_t cd_l2tag2 = 0; > > > > + uint64_t cd_type_cmd_tso_mss = ICE_TX_DESC_DTYPE_CTX; > > > > + uint32_t cd_tunneling_params = 0; > > > > + uint64_t ptp_tx_index = txq->ice_vsi->adapter->ptp_tx_index; > > > > + > > > > + if (ice_calc_context_desc(ol_flags) == 0) > > > > + return 0; > > > > + > > > > + if (ol_flags & RTE_MBUF_F_TX_TUNNEL_MASK) > > > > + ice_parse_tunneling_params(ol_flags, *tx_offload, > > > > &cd_tunneling_params); > > > > + > > > > + if (ol_flags & (RTE_MBUF_F_TX_TCP_SEG | RTE_MBUF_F_TX_UDP_SEG)) > > > > + cd_type_cmd_tso_mss |= ice_set_tso_ctx(ol_flags, > > > > tx_pkt, *tx_offload); > > > > + else if (ol_flags & RTE_MBUF_F_TX_IEEE1588_TMST) > > > > + cd_type_cmd_tso_mss |= > > > > + ((uint64_t)CI_TX_CTX_DESC_TSYN << > > > > CI_TXD_QW1_CMD_S) | > > > > + ((ptp_tx_index << ICE_TXD_CTX_QW1_TSYN_S) & > > > > ICE_TXD_CTX_QW1_TSYN_M); > > > > > > It's tangentially related to this commit but it caught my attention that > > > TSO > > > and timestamping are mutually exclusive here. They *are* mutually > > > exclusive > > > as far as the driver is concerned so that part is fine, but I couldn't > > > find > > > any signs of us enforcing this limitation anywhere in our configuration > > > path, so a well behaved application could theoretically arrive at this > > > combination of mbuf flags without breaking anything. > > > > > > (if I understand things correctly, this applies to both ice and i40e) > > > > > Yes, you are correct here. However, I'm not sure if we can or should > > enforce this, as it is completely possible to have a queue where some > > packets are sent with TSO and others are sent with the timesync flag on > > them. There is no way for the actual Tx function to flag a bad packet. > > Best we can possibly do is add a check to the pre-Tx packet prepare > > function. WDYT? > > > > /Bruce > > Now that I think of it, I believe these features do not make logical sense > together anyway (TSO means segmented packets while timestamping means you > have one packet you timestamp) so perhaps this can be considered user error? > I mean we could add a check if it doesn't hurt performance, but maybe this > isn't a problem we need to solve. > I wouldn't put a datapath check for this. Maybe one in tx_prepare just, but even then I'm not sure of the cost/benefit.
/Bruce
