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 94C232BEFFB; Tue, 13 Jan 2026 03:08:58 +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=1768273738; cv=none; b=WfSa9RKQvFAkqIr9uSxHiK850VOMcEHTasya0Xj2GKU7+Lia8jvXKIKT95LLfKV/z7NgK4birtLmevzfHGhIVtsUFFZ1EguNIqzatQ7sQAw/18VgtgWjJwKpebi4LLoicOHI/VXNd55bZTBQRikBcQRTP2PQp8HUSxbBbdIzja8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768273738; c=relaxed/simple; bh=5xE/UzPxx8Afb98pxY1v4ktqur7bu8ogwAB86SInQLY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ArrMDQgb/X0+NYG7iJGlP9X490wQcEs8dKZ5XIoZQjFCb3VpW+723XLoJjNwroSjBbNCIy7sLAMAcH/AVvvAOAcoh5JaPnpaBMvUa6h2Ft9iWhaR3B+AEaDIRt6lvmdSUGOIklnmGlEkCSMCIhvBaz0IkoyjovCY6danmwiaO00= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TxCxXi1Y; 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="TxCxXi1Y" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 40EF2C116D0; Tue, 13 Jan 2026 03:08:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768273738; bh=5xE/UzPxx8Afb98pxY1v4ktqur7bu8ogwAB86SInQLY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=TxCxXi1YYxnJS0sw3EBgIsVaZR29gHP1MwekE7jvJ7HN9K66f3ba7l45ZqRcdA4uf nuDNomQ8sQtAOoCE2XaXl2oNobHXeldazE0BSB7OPo16sSaF6+gh+d+3na5Oaq6oLO +lNZWxelFszTDqaj2FTYJ9qL8I4dN/0VSFpCXMgDETBmJequQVEQA0lO2kXvpvp2fH neG7Lf84hS1pPM0GbkHOpvFjmkCeniqNDr94VipaKGmg5nEwR7Ec1Wp3mH+RsqzP0E 0tUFv8j3TPBbUaoqIZDcO4V0p3YIPFLWreWrRrHIwGWWgfRVN2RrsoBdaRQQUvsz1m azzkhf9CVTgkA== Date: Mon, 12 Jan 2026 19:08:56 -0800 From: Jakub Kicinski To: Jakub Sitnicki Cc: netdev@vger.kernel.org, "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Michael Chan , Pavan Chebbi , Andrew Lunn , Tony Nguyen , Przemek Kitszel , Saeed Mahameed , Leon Romanovsky , Tariq Toukan , Mark Bloch , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Stanislav Fomichev , intel-wired-lan@lists.osuosl.org, bpf@vger.kernel.org, kernel-team@cloudflare.com Subject: Re: [PATCH net-next 00/10] Call skb_metadata_set when skb->data points past metadata Message-ID: <20260112190856.3ff91f8d@kernel.org> In-Reply-To: <20260110-skb-meta-fixup-skb_metadata_set-calls-v1-0-1047878ed1b0@cloudflare.com> References: <20260110-skb-meta-fixup-skb_metadata_set-calls-v1-0-1047878ed1b0@cloudflare.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 Sat, 10 Jan 2026 22:05:14 +0100 Jakub Sitnicki wrote: > This series is split out of [1] following discussion with Jakub. > > To copy XDP metadata into an skb extension when skb_metadata_set() is > called, we need to locate the metadata contents. "When skb_metadata_set() is called"? I think that may cause perf regressions unless we merge major optimizations at the same time? Should we defer touching the drivers until we have a PoC and some idea whether allocating the extension right away is manageable or we are better off doing it via a kfunc in TC (after GRO)? To be clear putting the metadata in an extension right away would indeed be much cleaner, just not sure how much of the perf hit we can optimize away..