[PATCH v4 05/35] net/intel: add common fn to calculate needed descriptors

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


On 2/10/2026 6:25 PM, Bruce Richardson wrote:
> On Tue, Feb 10, 2026 at 03:17:32PM +0100, Burakov, Anatoly wrote:
>> On 2/10/2026 3:08 PM, Bruce Richardson wrote:
>>> On Tue, Feb 10, 2026 at 01:29:48PM +0100, Burakov, Anatoly wrote:
>>>> On 2/9/2026 5:45 PM, Bruce Richardson wrote:
>>>>> Multiple drivers used the same logic to calculate how many Tx data
>>>>> descriptors were needed. Move that calculation to common code. In the
>>>>> process of updating drivers, fix idpf driver calculation for the TSO
>>>>> case.
>>>>>
>>>>
>>>> "Fix TSO for idpf" sounds like a bugfix? Can it be backported to stable?
>>>>
>>> Yes, it is a bug fix for a particular edge case. However, as done here, the
>>> fix is implied by the code changes in the consolidation, and depends upon
>>> them. Any fix for backport would need to be a different, standalone patch,
>>> based on this.
>>>
>>> /Bruce
>>
>> So the original code didn't have TSO at all? I.e. this can't be fixed as a
>> prerequisite patch to this patchset?
>>
> Original code did have TSO, it just didn't support the case where a single
> mbuf segment had more data than the max allowed to be described by a single
> descriptor, i.e. where we had multiple descriptors for one mbuf segment, so
> that "nb_descs != mbuf->nb_segs + ctx_descs". The other drivers all solve
> this by having a separate function that iterated through the descriptors,
> and to fix this in older releases would be to add such a function to this
> driver. There is little point adding that function in this series just to
> delete it later here, so I think for 26.03 the fix here is best and for
> earlier releases the best fix is to just put the necessary code directly
> into idpf driver. I've noted this down to do a backported patch after this
> series goes in.
> 
> /Bruce

Got it, thanks!

-- 
Thanks,
Anatoly


More information about the dev mailing list