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
