From: Steve Rutherford <[email protected]> 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 > <[email protected]> wrote: >> >> From: Steve Rutherford <[email protected]> >> Date: Tue, 3 Mar 2026 11:44:19 -0800 >> >>> On Tue, Mar 3, 2026 at 7:34 AM Alexander Lobakin >>> <[email protected]> wrote: >>>> >>>> From: Steve Rutherford <[email protected]> >>>> 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 <[email protected]> Thanks, Olek
