[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <73d3a185-2ac2-6f40-1708-f9dd6f0be4e8@gmail.com>
Date: Wed, 2 May 2018 09:40:08 -0600
From: David Ahern <dsahern@...il.com>
To: Jesper Dangaard Brouer <brouer@...hat.com>
Cc: netdev@...r.kernel.org, borkmann@...earbox.net, ast@...nel.org,
davem@...emloft.net, shm@...ulusnetworks.com,
roopa@...ulusnetworks.com, toke@...e.dk, john.fastabend@...il.com,
Tariq Toukan <tariqt@...lanox.com>
Subject: Re: [RFC v2 bpf-next 9/9] samples/bpf: Add examples of ipv4 and ipv6
forwarding in XDP
On 5/2/18 5:13 AM, Jesper Dangaard Brouer wrote:
>
> On Sun, 29 Apr 2018 11:07:52 -0700 David Ahern <dsahern@...il.com> wrote:
>
>> + /* verify egress index has xdp support */
>> + // TO-DO bpf_map_lookup_elem(&tx_port, &key) fails with
>> + // cannot pass map_type 14 into func bpf_map_lookup_elem#1:
>
> I just want to point out that I/we are aware of this "usability"
> problem with the sample program, but I don't want to block the FIB
> helper going upstream, we can fix this problem later.
>
> The problem is that if you load this bpf/xdp prog, then all incoming
> traffic (on that interface), will be forward using XDP, regardless
> whether the egress ifindex support XDP or not. And if not supported,
> then packets are dropped hard (only detectable via tracepoints).
>
> If the bpf prog could tell/know that the egress ifindex doesn't
> support XDP xmit, then it could simply return XDP_PASS to fallback to
> the normal network stack.
>
That's what the above lookup is intending but DEVMAP type does not
handle lookups from xdp programs. Any chance of fixing that?
Powered by blists - more mailing lists