Re: [RFC PATCHv2 1/1] idpf: Fix header clobber in IDPF with SWIOTLB enabled

[Alexander Lobakin <aleksander.lobakin@intel.com>]

From: Steve Rutherford <srutherford@google.com>
Date: Wed, 4 Mar 2026 14:01:46 -0800

> I believe syncing twice isn't inherently wrong - it's more that you
> can't synthesize the header via the workaround and then sync, since it
> will pull the uninitialized header buffer from the SWIOTLB. Outside of
> SWIOTLB, dma syncs are more or less no-ops, while (with SWIOTLB) they
> are copies from/to the bounce buffers.

Ah I see.

What if I add sync_for_device after copying the header? This should
synchronize the bounce buffer with the copied data I guess? A bit of
overhead, but this W/A triggers mostly on stuff like ARP/ICMP, "hotpath"
L4 protos are fortunately not affected.

> 
> On Wed, Mar 4, 2026 at 7:13 AM Alexander Lobakin
> <aleksander.lobakin@intel.com> wrote:
>>
>> From: Steve Rutherford <srutherford@google.com>
>> Date: Tue, 3 Mar 2026 11:44:19 -0800
>>
>>> On Tue, Mar 3, 2026 at 7:34 AM Alexander Lobakin
>>> <aleksander.lobakin@intel.com> wrote:
>>>>
>>>> From: Steve Rutherford <srutherford@google.com>
>>>> Date: Fri, 27 Feb 2026 20:34:57 +0000
>>>>
>>>>> When SWIOTLB and header split are enabled, IDPF sees empty packets in the
>>>>> rx queue.
>>>>>
>>>>> This is caused by libeth_rx_sync_for_cpu clobbering the synthesized header
>>>>> in the workaround (i.e. overflow) path. After the header is synthesized by
>>>>> idpf_rx_hsplit_wa, the sync call pulls from the empty SWIOTLB buffer,
>>>>> effectively zeroing out the buffer.
>>>>>
>>>>> This skips the extra sync in the workaround path in most cases. The one
>>>>> exception is that it calls sync to trigger a recycle the header buffer when
>>>>> it fails to find a header in the payload.
>>>>>
>>>>> Fixes: 90912f9f4f2d1 ("idpf: convert header split mode to libeth + napi_build_skb()")
>>>>> Signed-off-by: Steve Rutherford <srutherford@google.com>
Thanks,
Olek