From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 760C43E92BD for ; Tue, 30 Jun 2026 10:00:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782813650; cv=none; b=VJectvBJlPOKO66fXRyf0EXyjOvAbVGLvk/932lr3cjgR+IayRY9ncyTgW3w0C3Ly5kU2kOhOe/cmd03GUGnjGGgIvvaACUvs7PkMr6Lzg0q1yYMqjWqBRCqHbUPC0OFN0Way3aOEjmScJxhzWdAuV3w3yDhIES1h3n6rg1l3iw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782813650; c=relaxed/simple; bh=ekEo5LipZXYEpZ0QMIrZZq+nxmDsIJiQlfi8Av3DFSk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=R5yDFQCXdc/U4QvtA45m+BD8/fi2+4OH+FN4aC+9Zi04+FoZJyk/s0sXo2MdDm0NrkcQYGTOMhVhhq/u1mGf2Zk1rsGfxrr8M7W29Ueles4DCIk3GuJ6sOfnQrBP8R5tEEZ2BfJTWr7IvknLQ3Gim/5xc/UwgD+M0g/pHyfbQac= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=eC/cqAsc; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=kE1Rvch5; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="eC/cqAsc"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="kE1Rvch5" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782813647; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tefDvr2JHzbWEvM4BvoT6FRVVef0ZkWyx7gPNMbvFYo=; b=eC/cqAscQePQlMf/xlYzTn7uTRg7EetoGDKMCSP8ZBom3HyPY2UMDp1iqk66kvCXAO/v1V k3atPUSmTz08OAatfQ1klM7hBJy4LE4R0pHFdTNm9tcVJ3G3YJjxZmeNDZgOE5E2LMkSgy /Ue8hxIvvga3Bo8OO/OCWu/NPbO8ztA= Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-633-jFAoF_xrN46V03RnXXIJaw-1; Tue, 30 Jun 2026 06:00:45 -0400 X-MC-Unique: jFAoF_xrN46V03RnXXIJaw-1 X-Mimecast-MFC-AGG-ID: jFAoF_xrN46V03RnXXIJaw_1782813645 Received: by mail-ej1-f70.google.com with SMTP id a640c23a62f3a-c125bdd01cbso242410266b.0 for ; Tue, 30 Jun 2026 03:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1782813644; x=1783418444; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=tefDvr2JHzbWEvM4BvoT6FRVVef0ZkWyx7gPNMbvFYo=; b=kE1Rvch52EVBY4dbjZYMY+EUPzYq50u6lmbYdMynrToqkH2Jl2L5a/hLeHOBX/3gzl sPqMrD8TL6eZi6E7RukGDqygTnUnUTTaj0Va1lD2r0c+s2bbwZAD/VS22m5YLDQaBrTs Fzgi23oChv/Lz54Aw/oTLf4bvvJyqQl5Hj3hqrHsWgDJqflGJkNq+CCMT7yN/jITsYGK 4nAJVDvjzM3IEG/AS8Lm+K2bSspklj/b0xWJ/+yYHvh2pbnBY6gFWsbkg8OflmUZD0K1 FTpVUhdCBlau4EnpXYY+dmcM0BPGRFITOK1V4uD+R8YceJZBjG8ds4N3RtrS2GPOrSWr zAsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782813644; x=1783418444; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=tefDvr2JHzbWEvM4BvoT6FRVVef0ZkWyx7gPNMbvFYo=; b=cP2sKiP/yBZdTM2Cv/raR6R4y6fV8R0I/PFFgjlaGskbkXV9UtTtMhv/6TKwVPV2LX Hx69HnPYt1Esgk9MLI1Shdhf/ZAztjwWmucGOH6upir20Fi3f4rfh8R3g3hmG8Eo4QPZ jD6tCIQsQv8lGQJwHDjvCPllE157IAUmgrHUK6XoppgMxtQ9dgMgfvOHFQSUGt/mRs/7 37ra34lhxf9IXIBhC2xHychpbQO2WY3SnrfZioIioJ3znLf9FHqN9x/ss0F9f8W1CdNC wBQaTdGEitcipyvzhwptZa3fXk7r0EXtGjmPmRr+uVeIAez0LLxpBKOoWjv2623+dq/E RwDg== X-Forwarded-Encrypted: i=1; AHgh+RoEYqzL74NQ6kNJYyIK6E9f+xHpFErRpZVxSQYwwrjd2m5OVTtHZZGhNkvO8mOvAUEAF+xbKD1z14vsJ3k=@vger.kernel.org X-Gm-Message-State: AOJu0YyNsdB0AyjtdNX7RQ68yTtHsd7RyeYX/xY1tJfLQgrG+4pUbmZ+ KWTq7izqSZRDvSr+De2+12Q711DqCIywX0x0GTG+hkxDKRwmLeQfWP9cnM1JIdG0ghw/uzf9PkZ 4F2rpdMQCrQa+TcERmiIkZZARzicRCzPg0K3tBHQMsgq0yv1H2lbYqpQ6sTjRRhovDg== X-Gm-Gg: AfdE7cnq4wE3ZYsJDW1WF22E2x5spHUT+8f2tm+/pTnEpfESR1C/ql+W4WoWK61U57o YKadp2aGe1vK/vlq0G+Kv/9xxLQVXk5rovkVO85DRNZclr9ATjlSsAScQgKkc+wHmHd96REko6q Y33Qq7vcl2QtoNBk5SoO5MUaEZSAmKZKBMuGifufQqX0VNC2LT+SFX9hChGp68ctdTI82oY3NE4 h+GdNjI6+3s02+3m0WiebSHDytg5I3R0UHNBb7r3WMMATfrgv6NxwQT1gnQU+2VocDmRSzb9yJL a0v7F1pUIDDcHlBofbJy9QoOC/a692aWHNWv/sPjEePSJOfa0FRE4IcAGPptpW9PIk6t0zs4a5w jrJI5Cxlxx0J8Nnp8J2ByRF6FRYJfws5AC0Y= X-Received: by 2002:a17:907:97d2:b0:c07:fcdd:7043 with SMTP id a640c23a62f3a-c1287168408mr137277866b.16.1782813644554; Tue, 30 Jun 2026 03:00:44 -0700 (PDT) X-Received: by 2002:a17:907:97d2:b0:c07:fcdd:7043 with SMTP id a640c23a62f3a-c1287168408mr137275166b.16.1782813644021; Tue, 30 Jun 2026 03:00:44 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([45.145.92.2]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c1288d1abbdsm98502166b.9.2026.06.30.03.00.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jun 2026 03:00:43 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id A672D80A53A; Tue, 30 Jun 2026 12:00:42 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: David Ahern , Avinash Duduskar , ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org Cc: eddyz87@gmail.com, memxor@gmail.com, martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev, jolsa@kernel.org, emil@etsalapatis.com, john.fastabend@gmail.com, sdf@fomichev.me, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, shuah@kernel.org, hawk@kernel.org, yatsenko@meta.com, leon.hwang@linux.dev, kpsingh@kernel.org, a.s.protopopov@gmail.com, ameryhung@gmail.com, rongtao@cestc.cn, eyal.birger@gmail.com, bpf@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH bpf-next v5 1/3] bpf: Add BPF_FIB_LOOKUP_VLAN flag to bpf_fib_lookup() helper In-Reply-To: <2ffa32dd-5c88-488a-aa23-deef13465eb9@kernel.org> References: <20260624030530.3342884-1-avinash.duduskar@gmail.com> <20260624030530.3342884-2-avinash.duduskar@gmail.com> <87se65bd04.fsf@toke.dk> <2ffa32dd-5c88-488a-aa23-deef13465eb9@kernel.org> X-Clacks-Overhead: GNU Terry Pratchett Date: Tue, 30 Jun 2026 12:00:42 +0200 Message-ID: <87echobb5h.fsf@toke.dk> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable David Ahern writes: > On 6/29/26 9:08 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> David Ahern writes: >>=20 >>> On 6/23/26 9:05 PM, Avinash Duduskar wrote: >>>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h >>>> index 89b36de5fdbb..e00f0392e728 100644 >>>> --- a/include/uapi/linux/bpf.h >>>> +++ b/include/uapi/linux/bpf.h >>>> @@ -3532,6 +3532,29 @@ union bpf_attr { >>>> * Use the mark present in *params*->mark for the fib lookup. >>>> * This option should not be used with BPF_FIB_LOOKUP_DIRECT, >>>> * as it only has meaning for full lookups. >>>> + * **BPF_FIB_LOOKUP_VLAN** >>> >>> This flag should not be needed. Patches for vlan support were never >>> submitted (I have them in some old branch). Since the vlan params are >>> initialized to 0, no new flag should be needed. Besides, these are >>> output parameters. >>=20 >> There's no enforcement from the kernel side of the parameters being >> zero, though? So we do need the flag for feature detection; unless we >> expect applications to do that out of band? But then we'd need a >> mechanism to do that which could be... the presence of the flag in the >> ENUM (and thus in BTF)? :) >>=20 > > This is output direction - return from the fib lookup. Ah, right, silly me. > It does not make sense to require a flag to get lookup output. vlan > proto of 0 is not valid, so it is a clear indication that the vlan > output parameters were not set during the lookup. Okay, so we could just unconditionally set the VLAN fields, but if we start rewriting the ifindex that would be a change of the existing behaviour that could break existing applications, no? Specifically, if an XDP application has a table of the interfaces it forwards between, today they'd get a VLAN interface ifindex, which would not be in that table, and the application would return XDP_PASS. Whereas if we change the ifindex and populate the VLAN tag, suddenly the interface would be in the table, but because the application doesn't read the returned VLAN tag, it will end up sending packets out without tagging them, leading to broken forwarding. So if we don't want the flag, we'd need some other mechanism to resolve the parent ifindex, AFAICT? Maybe a xdp_get_parent_ifindex() kfunc, say? That could also be made generic for other stacked interface types, I suppose. WDYT? -Toke