> On May 8, 2025, at 10:16 AM, Jesper Dangaard Brouer <hawk@xxxxxxxxxx> wrote: > > > > On 08/05/2025 15.29, Willem de Bruijn wrote: >> Jon Kohler wrote: >>> >>> >>>> On May 7, 2025, at 4:56 PM, Willem de Bruijn <willemdebruijn.kernel@xxxxxxxxx> wrote: >>>> >>>> >>>> Jon Kohler wrote: >>>>> Use xdp_get_frame_len helper to ensure xdp frame size is calculated >>>>> correctly in both single buffer and multi buffer configurations. >>>> >>>> Not necessarily opposed, but multi buffer is not actually possible >>>> in this code path, right? >>>> >>>> tun_put_user_xdp only copies xdp_frame->data, for one. >>>> >>>> Else this would also be fix, not net-next material. >>> >>> Correct, this is a prep patch for future multi buffer support, >>> I’m not aware of any path that can currently do that thru >>> this code. >>> > > This is a good example of a performance paper-cut, from my rant. > Adding xdp_get_frame_len() where it is not needed, adds extra code, > in-form of an if-statement and a potential touching of a colder > cache-line in skb_shared_info area. > > >>> The reason for pursuing multi-buffer is to allow vhost/net >>> batching to work again for large payloads. >> I was not aware of that context. I'd add a comment to that in the >> commit message, and send it as part of that series. > > It need to part of that series, as that batching change should bring a > larger performance benefit that outweighs the paper-cut. Gotcha, mission understood. Sorry for the confusion, and thank you for taking the time to walk me through that, I appreciate it. I’ll come back to list when the larger series is ready for eyes. > > AFAICR there is also some dual packet handling code path for XDP in > vhost_net/tun. I'm also willing to take the paper-cut, for cleaning > that up. > > --Jesper When you say dual packet handling, what are you referring to specifically?
