[PATCH v4 07/35] net/i40e: refactor context descriptor handling

Burakov, Anatoly anatoly.burakov at intel.com
Wed Feb 11 10:20:40 CET 2026


On 2/10/2026 6:54 PM, Bruce Richardson wrote:
> On Tue, Feb 10, 2026 at 03:19:27PM +0100, Burakov, Anatoly wrote:
>> On 2/10/2026 3:10 PM, Bruce Richardson wrote:
>>> On Tue, Feb 10, 2026 at 01:48:20PM +0100, Burakov, Anatoly wrote:
>>>> On 2/9/2026 5:45 PM, Bruce Richardson wrote:
>>>>> Move all context descriptor handling to a single function, as with
>>>>> the ice driver, and use the same function signature as that driver.
>>>>>
>>>>> 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 __rte_unused, +		 uint64_t *qw0,
>>>>> uint64_t *qw1) +{ +	uint16_t cd_l2tag2 = 0; +	uint64_t
>>>>> cd_type_cmd_tso_mss = I40E_TX_DESC_DTYPE_CONTEXT; +	uint32_t
>>>>> cd_tunneling_params = 0; + +	if
>>>>> (i40e_calc_context_desc(ol_flags) == 0) +		return 0; +
>>>>> +	if (ol_flags & RTE_MBUF_F_TX_TUNNEL_MASK) +
>>>>> i40e_parse_tunneling_params(ol_flags, *tx_offload,
>>>>> &cd_tunneling_params); + +	if (ol_flags &
>>>>> RTE_MBUF_F_TX_TCP_SEG) { +		cd_type_cmd_tso_mss |=
>>>>> i40e_set_tso_ctx(ol_flags, tx_pkt, *tx_offload); +	} else {
>>>>> +#ifdef RTE_LIBRTE_IEEE1588 +		if (ol_flags &
>>>>> RTE_MBUF_F_TX_IEEE1588_TMST) +			cd_type_cmd_tso_mss
>>>>> |= +				((uint64_t)I40E_TX_CTX_DESC_TSYN <<
>>>>> I40E_TXD_CTX_QW1_CMD_SHIFT); +#endif
>>>>
>>>> I couldn't find any places where we define this, it appears to be
>>>> some sort of legacy define, making this basically dead code?
>>>>
>>>
>>> It is legacy, and does need to be fixed, but across all of DPDK I
>>> think.  Testpmd, for example, has IEEE1588 ifdefs also.
>>>
>>> However, for this patch, it's probably harmless enough to remove the
>>> ifdef here and always allow this code path to execute.
>>>
>>> /Bruce
>>
>> Sure, but I would've preferred this to be a separate patch as it's
>> semantically different from what you're doing here. Perhaps it can be
>> fixed as one of the early patches in the series as "preparatory work" for
>> this one.
>>
> 
> I don't think it belongs in this series at all, actually. The IEEE1588
> define appears in multiple drivers, not just Intel ones, as well as testpmd
> (as I previously said). However, if you think it's worth patching it out
> just for i40e I can add the patch to do so to this set.
> 
> /Bruce

I don't have strong feelings about *when* to remove it, but if we are to 
remove it, IMO we should do it as a separate patch, not as a rolled-in 
change into this one. However, I don't think it's a big issue so if you 
think it's not worth the rework then that's fine.

-- 
Thanks,
Anatoly


More information about the dev mailing list