From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 34CBC253951; Tue, 9 Sep 2025 21:12:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757452344; cv=none; b=bgL+LyruDP1mIxRlg5KKiKXWR58HoH6/arVRYcIcgA76R6rqGIlpFH+FWNbVb9F+dM8J+Jt877EBnLamF4d5dSiSwPTUC1F7x/+U8wMp6efvO4nK3rAKJrMslTVYXbcJV2gLoCfG9lo2I43FGKR2dFC4P2s3z7zPOXVwROKimbk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757452344; c=relaxed/simple; bh=c3SyJQ57FSqB3XnVUxPYlihJ10MSLpFeLzzdFD6BwHY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=r6it4Te/ioN1S/AlF2cQ/0ModkWQeAZ6H8HJlsHDLWpSR0H+Dvx7kIGkSrvWaCJROtERCgLvkkWvDmb6dUtn24aJJCBkJ9S7txb4yTxI/Glw8NS5qgTpliXQY03MIsy+i3IbVn/ExgL9frZ+UHXN5hVWKmLMyKHNYpLW2uI/EEc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cywXSafV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cywXSafV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D1B48C4CEF4; Tue, 9 Sep 2025 21:12:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1757452343; bh=c3SyJQ57FSqB3XnVUxPYlihJ10MSLpFeLzzdFD6BwHY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=cywXSafVp9YvJ6T7ky6frjfZ2//mKk/FKatrTOn2PAfJZdOVf8ZoYIlsFzRDu8EeB 2KPXlF3n2H5wi9gL7RTADWCl3l+Y5vXuu+cEFu5CrP9CmtOhHZWmlQfLNk0Y0UYt/M VZssDnBLX4AFwtFtINZqms5bQet5efAxPGmNxmbUvjtnp31XJ/lteY0pC82kgbWh/2 8x2UgllauKBlfgimppmKGLms6UVq9zLJyynJThNBZqztwm71Db4CpgRTQtAtkihmee bL1dEDObCUKzXNNcW9JuHJIKCwt5VX3KTAs2AqUW5cyuwyrzvoBKo5DghfegsTTiNL chdSjRm/sCm6Q== Date: Tue, 9 Sep 2025 14:12:21 -0700 From: Jakub Kicinski To: Nimrod Oren Cc: "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Shuah Khan , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , "John Fastabend" , Stanislav Fomichev , Mohsin Bashir , Dragos Tatulea , Tariq Toukan , Carolina Jubran , , , , Subject: Re: [PATCH RFC net-next 0/5] selftests: drv-net: Convert XDP program to bpf_dynptr Message-ID: <20250909141221.4a10bfa5@kernel.org> In-Reply-To: <20250909085236.2234306-1-noren@nvidia.com> References: <20250909085236.2234306-1-noren@nvidia.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 9 Sep 2025 11:52:31 +0300 Nimrod Oren wrote: > In cases where the program does not return XDP_PASS, I believe dynptr has > an advantage since it avoids an extra copy. Conversely, when the program > returns XDP_PASS, bpf_xdp_pull_data may be preferable, as the copy will > be performed in any case during skb creation. > > It may make sense to split the work into two separate programs, allowing us > to test both solutions independently. Alternatively, we can consider a > combined approach, where the more fitting solution is applied for each use > case. I welcome feedback on which direction would be most useful. Ideally we'd make the BPF code work in either mode. But not sure it's achievable given the verification complexity. Failing that we can have two BPF objects and parameterize the test cases. It'd be neat if we could capture if the pull actually pulled anything for a given case, so that we only bother re-running with the dynptr when we'd end up with different packet geometry. But only if it doesn't make the test code too complex.