From: David Ahern <dsahern@gmail.com>
To: Konrad Zemek <konrad@zemek.io>
Cc: "xdp-newbies@vger.kernel.org" <xdp-newbies@vger.kernel.org>
Subject: Re: bpf_fib_lookup VLAN
Date: Sun, 18 Apr 2021 10:11:18 -0700 [thread overview]
Message-ID: <eeb4f9da-d896-0806-80a6-c8ca3f7a285b@gmail.com> (raw)
In-Reply-To: <wp7cnO1IP6giAEl4UWGVelu8OW0KZBpz0HlppNPYs4GhRWtivZWXv4OyyzN1-wPmAlwk5UXVLCDdLmABA8HdEAp5sCE-yj2fyu4Qlzwtmpo=@zemek.io>
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 <dsahern@gmail.com> 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.
prev parent reply other threads:[~2021-04-18 17:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-16 12:03 bpf_fib_lookup VLAN Konrad Zemek
2021-04-16 15:15 ` Konrad Zemek
2021-04-16 15:35 ` David Ahern
2021-04-16 16:12 ` Konrad Zemek
2021-04-18 17:11 ` David Ahern [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eeb4f9da-d896-0806-80a6-c8ca3f7a285b@gmail.com \
--to=dsahern@gmail.com \
--cc=konrad@zemek.io \
--cc=xdp-newbies@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).