From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1443C433ED for ; Sun, 18 Apr 2021 17:11:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 56A9560FEA for ; Sun, 18 Apr 2021 17:11:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229986AbhDRRLw (ORCPT ); Sun, 18 Apr 2021 13:11:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51036 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229783AbhDRRLw (ORCPT ); Sun, 18 Apr 2021 13:11:52 -0400 Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E0D5FC06174A for ; Sun, 18 Apr 2021 10:11:20 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id k14-20020a9d7dce0000b02901b866632f29so30415571otn.1 for ; Sun, 18 Apr 2021 10:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=HsLypbmJ8YPsXVMghy76oHPm04ovXAPi/ZO52NtPVWw=; b=aYA+3nQNYIvC0gQrSgrdSL0/ORhPqp5Jq0cZ77MxVyoIrtjTzfbkNDn54ZiW57+dMt rdCVbEQvD4Ocd6+ZjEbGdhJcdZG6KfiIO0gFoLOpN09NIpVXpZ2xxccncartf2KL9O8Y DoKPYBBklXKoQuySFkABhTSnhFE+JYoqJra9NO2K6Z2lzIQuw0UNqgoVn9ElmSAjC7Bh 5gJuSoE4KJV2YVZxQyRWCdk2QeEP1YDVjTwm45F7dEX+ZnZms3Pbp7g7pz5txKpDSCkb +mpwZBth7g8inRAyYUwkk3ECBVcg7xzmOc1meifjZgltlAHn6+GXGZ90Op2Wt3uFeyF9 7GWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HsLypbmJ8YPsXVMghy76oHPm04ovXAPi/ZO52NtPVWw=; b=s4aRJZ3qmoHSVFSbAKsfuWf37g5NdHO08TRuOILWz1KHqoPxZAif8pm93luWBL7xAW L9QUa/92tXpvtmePQBC3A6R9wPvlNkK8xhR4QpW81d+JT0vwPhTmGUt4mjbr2JEgFYf4 L8DV6SbcvFywxNLGkLsVMMkl7jMO4VQHbscOKYCij6qsJyrTuWMM79GEED6bnEofS6Y+ L33hItifK0bUt57ZbRvBHmFSioA5Z3OQSLKzcZRA7TJfM1SD1uJyCcjiGWCm5kl5vzdi OcTmw6SDIjy+nXobKEp054iz2l+uj7k5Ujd15U/Rvw5VKreq/jeFC4iyphEh00+ZtMq6 nCJQ== X-Gm-Message-State: AOAM531SVl1+ejwPppXCbX3ZFlXqDe0w8TKKNDFoBsbXNw8/70AicJX0 Ht+DdhtCIdB4epkIVBhPSm1NwwCIJeI= X-Google-Smtp-Source: ABdhPJziilEWxWYOzJRcZO2CKR7RWVozlfY+qTstUg75Cf22qUvSiHwBmXjyWnbcXyReI9Cl0RjuNQ== X-Received: by 2002:a9d:648c:: with SMTP id g12mr11826967otl.299.1618765880072; Sun, 18 Apr 2021 10:11:20 -0700 (PDT) Received: from Davids-MacBook-Pro.local ([8.45.41.12]) by smtp.googlemail.com with ESMTPSA id r18sm884481otp.74.2021.04.18.10.11.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 18 Apr 2021 10:11:19 -0700 (PDT) Subject: Re: bpf_fib_lookup VLAN To: Konrad Zemek Cc: "xdp-newbies@vger.kernel.org" References: <007301d732b8$8b0f5c90$a12e15b0$@zemek.io> <9e19881a-1f62-410f-8dec-0eff0c7ea03b@gmail.com> From: David Ahern Message-ID: Date: Sun, 18 Apr 2021 10:11:18 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: xdp-newbies@vger.kernel.org On 4/16/21 9:12 AM, Konrad Zemek wrote: > (Sorry for the double mail David, I missed the "reply all" button). > > On Friday, April 16, 2021 5:35 PM, David Ahern wrote: >> On 4/16/21 5:03 AM, Konrad Zemek wrote: >> >>> So both vlan fields in the output struct bpf_fib_lookup are always zero. I >>> haven't seen this commented on anywhere, including the discussion around >>> introducing bpf_fib_lookup, so I assume it's an accidental oversight. >> >> The uapi was setup to cover the use case, but VLANs are not supported at >> the moment. > > I'm surprised it's not marked as such in the bpf.h, the comments (or rather > lack of) made me convinced that it works just as well as the MAC address > fields. > >> On 4/16/21 5:03 AM, Konrad Zemek wrote: >>> Do you have any proposals for a workaround? Right now I'm thinking of >>> creating a BPF map that would map ifindex->vlan, populated in the userspace >>> >>> - but that assumes the output (struct bpf_fib_lookup*)->ifindex will be an >>> index of the vlan device and not the physical device the vlan is attached >>> on, which I'm not sure is the case yet. >>> >> >> vlan netdevices do not support XDP redirect. >> >> It's not a trivial problem to handle VLANs or stacked devices in >> general. I have working code here: >> >> https://github.com/dsahern/linux/commits/bpf/mpls-vlan-fwd >> >> but it is not ready for submitting upstream yet. The use case and >> related ones need more work. > > They don't, but it's not that important for my use case. I have just > one interface and all the VLANs are on that, so if I learn that a > VLAN is needed it's just another thing I push in front of the tunnel > frames that I already push. If I had multiple interfaces, I'd just > need one more piece of info which is "what's the physical interface > number this VLAN is attached on". Your use case is fairly trivial to support, but generically the vlan can be on a bridge, bond, or port. To properly support VLAN redirects, the fib lookup needs to resolve the stack to the egress port. > > XDP programs are already pretty specific to the infrastructure one's > running, and already very manual with packet manipulation (which is > actually a boon to a lot of things I'm doing), so I don't mind this > not being a generic solution. > As I recall (it has been a few years), the fib lookup device index is the vlan device. You could have a map that converts that return to the real port and vlan. It should work, just more maintenance.