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.
--
Thanks,
Anatoly
