From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.221.182 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794327791; b=oWc3HoxmK1K7EPNOO6YZWmJrjfsOmDmBzYM551S60+9CFzKuH1sP7TbbBAWWT0mGEK4j mha5PvRSelYbDrs/cr8hhadDxu2+r7MhYe7VNhM2MvtwTCKeYwXJ9IojK87BMssb8P3sl qCgftmyLk/v+eHQZQesxGloj11SUJ5DCtQ+bBVUV3vq92S3hCUFwuXoLX0CpUVxqVfdts ZlpzXzzVBhynL6A80X2ycDt82yyA0IM1QKStzWj00S5U/Ova4MOw8YfiR/rdq+nGCijDE lb7f93a/hnT7qITk0+CFio+mJFggZzqgZt/YS12weqP4onPFueVhlP9YQIoExRj98jQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794327791; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received:Received: Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type:Content-Transfer-Encoding; bh=42cpwdtrc4HrP4DqyvReN7gjWda0yb9ngByLx/bSiMU=; b=JjIHbTtL9rMKods+eWkFIFrRX2Krb9dTpvq3349hXT2zZ3RJ/N2HeHlsoIDzuhjoQ56n Vgg+054epWGg4DFSaymOSkyEjzu7tSd+DUrpf5GBVOFHO05Qls6edG3C1jEh6jJShA611 V6YvaPgfuq9PzJPKMVkHFvBU+dPh/amuaorPirAqGRHleTgAWqNcpMNw/xgtl8SLCb3CO DbpjEgp1YJWgQW9yYhqkJwyIU0O7xCegj6QvxRthwVP63IlOGRkIKYhAsoAjxMF9Pra6s j/nBRgG+hGcJec3qojCMfFR2bsRqvnqew8WFP8VZ5msvbPkWf81DdOcPNqVDdHU4F5g== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=k9jynX5W; arc=none smtp.remote-ip=209.85.221.182 Received: from mail-vk1-f182.google.com (mail-vk1-f182.google.com [209.85.221.182]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 937A9606A320 for ; Tue, 10 Nov 2026 16:23:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 937A9606A320 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=k9jynX5W Received: by mail-vk1-f182.google.com with SMTP id 71dfb90a1353d-5eadef147ffso759387e0c.3 for ; Tue, 10 Nov 2026 08:23:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1794327790; x=1794932590; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=42cpwdtrc4HrP4DqyvReN7gjWda0yb9ngByLx/bSiMU=; b=k9jynX5WUmAeD9j2NE6/ggs5zDZLdvScu7YwYXbqBbHL22S8jy8N7eEfyWdUvgcBpF 8TAHUcgd9VnzhBUjoptLnC2COcPn9xKFLvBh2LvJTPkk9frz8XfKNrLC4YMk3T7aRsTc y5BqzughtJdwuo03qMeGDlzdpIWW9LTkAJVgO/wunOYTcgDRD8NE6D+4pTVaCLr7nUiA uo2X6xEjzPkrR8zphv7oYSD9b8iVKcnZpqlk+Xe11f1uXZIuVS3fF1qUgiJethGSaUS6 wlcxLJaReAQCdUgdwFNR3hHlOpTVBIM7HJhltfl/pnlWIeN8VeVhcBWXaAwF/v0hnspp gNzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1794327790; x=1794932590; h=content-transfer-encoding:content-type:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=42cpwdtrc4HrP4DqyvReN7gjWda0yb9ngByLx/bSiMU=; b=ppyghqgCBT9igfVRIUdLhDzvWZffEqgWhH2Moe09C4/6AotDRaw36Phfc4DrbzooTz GAXG0tq7raM0nxv4SWdssTSqLJ7p6lvr3FF8uUcPHCpMrW72f3wRVyX6s4VTjoWKAN8T QY4WFQ7HWepfOTt5GjbA+jQ2FEof9QU696RKuBsa7sAmRBaV6YY5oU9qOf/QgZdy5SUg Vp0hIgV/ot6Kn9xNHSiSv7Nsv1FgAximlteMe8XC7ic9mt3GhdQBgp4wZNucNIhjMkdE rB8M/FVtCiCphx3eSYY51gz3iRczbvg7H6X3oyfnp5vpGoU16ynuraXg/mYXFuxyQCdM rIfA== X-Forwarded-Encrypted: i=1; AL+hErE3CLElARpIUCNZKeKdgD8VF+2JK+9Istnw05yzNg3s9CGr4EGmE2RzFx5W5h1H9LgOxAvpF/R4IjA=@vger.kernel.org X-Gm-Message-State: APuU4Z8MLZOoO8jWdC6E74cuRxJWj4s2etJL0/P0mrOOrDP2cZNYqNQ1 0JrwCu+wmQgc4xhjfc+7gYO+pfab68uzCpbskKlMQVFbnBjA9G7V5sda X-Gm-Gg: AYBFou1FmjCsHvs6mOgB3zZ0g299PLvSuHjTbhSL9BANGHcUGeB2oJKf/+s3C9gbUKG qXbnoqcqswCcT981WMneO1ncV1yMFKMiVDJd8bOuS2+DSauA3WJZIFD4mJvuXYxczHC4QMCovVP 6b0qXBOVePXJj2b29QVworvCjIuR2RB+/ZDHOGCULG+KTvYuANZdE66XcazlJdrD0v02DyCD72p 6MZD+DbJZ32FbthjxnoAFEqHwu25vdFTWWahDK1hPfbCEscuw5lf1q+pb7wsW3zmtkIIRV2Bpul RGDk0g1p0bQ/vUzyZv114yTGq5GcXRn6HPXEsrBDqRmlpc1VzdaoJGSP4bV7BHJsG9aN7H6by87 SemMoR+wLKtUPpdkFsN7E4tnxu7r1VvqYuLBK1TyGaUr+zyqSkaMG3TELJp1WMgrYgESlATaFtk i2fN3tcC17nwrOvH3mQooa+U+CiEp7XkU9AkQyaTKvFT4IYR+eECicGnwmi5Dh0vEcHgIJ0dNMC MaFKZ+fVJeRnxLBKOeLKf900oitr7ysQLjeHK874OhjrkB91R0lW+g4MGc6cLlaDvfh1N6UFMjl 2TbTGP7zE9l76LYFntIPKaVOw9fDpFdpAO+jjUEszDZgzX1xxc4unXI2dBW2iPx0F7dsYS1qM+v MAXKdH6Hsi1Yd3o+uKBQGqg02E6E5RNvaw4viETL2MdFduS5O/Il4TMgPnThsW4NAlphzB6A= X-Received: by 2002:a05:6122:62e9:b0:5c9:c60e:3a4a with SMTP id 71dfb90a1353d-5ee0d19e59amr1124633e0c.22.1794327790334; Tue, 10 Nov 2026 08:23:10 -0800 (PST) Received: from gmail.com (223.230.150.34.bc.googleusercontent.com. [34.150.230.223]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-99c200838f0sm2123832241.9.2026.11.10.08.23.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Nov 2026 08:23:09 -0800 (PST) Date: Tue, 10 Nov 2026 11:23:09 -0500 From: Willem de Bruijn To: Tianyi Gao , Stephen Hemminger Cc: Willem de Bruijn , netdev@vger.kernel.org, Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , Simon Horman , David Keogh , Jesper Dangaard Brouer , Daniel Borkmann , David Woodhouse , Dragos Tatulea , Nimrod Oren , Alasdair McWilliam , Maciej Fijalkowski , Stanislav Fomichev , Magnus Karlsson , David Ahern , Ido Schimmel , Alexei Starovoitov , John Fastabend , Donald Hunter , Andrew Lunn , Jonathan Corbet , Shuah Khan , Shuah Khan , Randy Dunlap , Breno Leitao , =?UTF-8?B?QXNiasO4cm4gU2xvdGggVMO4bm5lc2Vu?= , Danielle Ratson , Kuniyuki Iwashima , bpf@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, kernel-team@cloudflare.com, nh-open-source@amazon.com Message-ID: In-Reply-To: <20261109154909.32748-1-tianyi@cloudflare.com> References: <20261107182526.69543-1-tianyi@cloudflare.com> <20261108190831.3f991a13@phoenix.local> <20261109154909.32748-1-tianyi@cloudflare.com> Subject: Re: [PATCH net-next 1/8] net: add tx_extra_headroom and LL_ALLOC_SPACE() X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Tianyi Gao wrote: > Hi Stephen, > > Thanks for the invaluable and detailed review. > > On Sun, 8 Nov 2026 19:08:31 -0800, Stephen Hemminger wrote: > > Since the motivating case is XDP, the mechanism should let the XDP program > > ask for the padding it needs, rather than making the operator translate > > the program's requirement into a device setting by hand. > > The series started from David Keogh's TC egress case, as described in > the RFC [1] and in the first paragraph of the v1 cover letter. The veth > XDP case came later, when I found that the same field also avoids the > copy for generic XDP on veth. > > > Your own reply already works this out: > > > > > - XDP on a veth peer: veth_xdp_set() and generic_xdp_install() can > > > increase the headroom of the peer to XDP_PACKET_HEADROOM on attach > > > and reset it on detach. > > > > That is the mechanism, and it needs no uapi, no operator arithmetic, and > > no stale state. I would rather see it implemented for the cases it covers > > than add a permanent uapi that removes the incentive to do so. > > Agreed. For this case, I plan to move to this in v2. When an XDP program > is attached to a veth device, tx_extra_headroom of the peer is set to > XDP_PACKET_HEADROOM. > > > On the argument that program-side declaration is itself new uapi, and that > > the labeled device is often not the device the skb was allocated on: > > granted for the general TC egress case. > > For TC egress, the kernel does not know at attach time how many bytes > the program pushes. Only the program, or the software that loads it, > knows. Attach-time propagation works for XDP because XDP_PACKET_HEADROOM > is a fixed value. > > Since we both agree that auto-tuning has real problems, a narrow UAPI, > such as a BPF-side declaration, seems unavoidable for TC egress. The > program declares the headroom that it needs through this UAPI. The > initial plan is a BTF decl_tag, as Dragos Tatulea suggested on the RFC > [2]. On attach, the kernel increases tx_extra_headroom of the device > that the program is attached to. > > > Which leaves the genuinely hard case, the one you describe at Cloudflare: a > > service in a netns sends through a veth pair, the host forwards to the > > uplink, and a TC egress program there encapsulates, after ip_rcv_core() > > has orphaned the skb so the allocating device cannot be identified. If > > that is the real residue, make it the problem being solved and argue for > > the narrowest mechanism that solves it. > > This case only came up after I started to look at in-kernel approaches, > because the general IFLA_TX_EXTRA_HEADROOM UAPI already solves it. It is > not a new case, and it is not uncommon. Cilium, Flannel and Calico use a > tunnel by default [3][4][5], so the device that encapsulates is not the > device that allocated the skb. I have some hope that if there is sufficient reason, this backlinking to the originating netdev (or socket?) can eventually be addressed as well. Rather than work around it. The skb_orphan and iif issues are well know. But not set in stone.