Re: [PATCH v4 06/35] net/ice: refactor context descriptor handling

Bruce Richardson
2026-02-11T10:38:30Z

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 <bruce.richardson@intel.com>
> > > > ---
> > >
> > > <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