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

[Burakov, Anatoly]

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 at 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.

-- 
Thanks,
Anatoly