From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: David Ahern <dahern@digitalocean.com>,
Jesper Dangaard Brouer <brouer@redhat.com>,
David Ahern <dsahern@kernel.org>
Cc: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
prashantbhole.linux@gmail.com, jasowang@redhat.com,
mst@redhat.com, toshiaki.makita1@gmail.com, daniel@iogearbox.net,
john.fastabend@gmail.com, ast@kernel.org, kafai@fb.com,
songliubraving@fb.com, yhs@fb.com, andriin@fb.com,
dsahern@gmail.com
Subject: Re: [PATCH RFC v4 bpf-next 03/11] xdp: Add xdp_txq_info to xdp_buff
Date: Fri, 28 Feb 2020 11:10:30 +0100 [thread overview]
Message-ID: <87lfonuind.fsf@toke.dk> (raw)
In-Reply-To: <3b57af56-e1c1-acc7-6392-db95337bf564@digitalocean.com>
David Ahern <dahern@digitalocean.com> writes:
> On 2/27/20 4:58 AM, Toke Høiland-Jørgensen wrote:
>> also, an egress program may want to actually know which
>> ingress iface the packet was first received on. So why not just keep
>> both fields? Since ifindex 0 is invalid anyway, the field could just be
>> 0 when it isn't known (e.g., egress ifindex on RX, or ingress ifindex if
>> it comes from the stack)?
>
> Today, the ingress device is lost in the conversion from xdp_buff to
> xdp_frame. The plumbing needed to keep that information is beyond the
> scope of this set.
>
> I am open to making the UAPI separate entries if there is a real reason
> for it. Do you have a specific use case?
I was thinking it could be a nice shorthand for whether a packet comes
from the local stack or was forwarded (0 == stack). But no, I don't have
a concrete application where this is useful. However, if we define it as
a union we lose the ability to change our mind. Together with the
debugability issue I just replied with to your other email, I think it
would be better to expend the four bytes keep them as separate fields,
but still restrict access to the RX ifindex for now.
-Toke
next prev parent reply other threads:[~2020-02-28 10:10 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-27 3:20 [PATCH RFC v4 bpf-next 00/11] Add support for XDP in egress path David Ahern
2020-02-27 3:20 ` [PATCH RFC v4 bpf-next 01/11] net: Add XDP setup and query commands for Tx programs David Ahern
2020-02-27 3:20 ` [PATCH RFC v4 bpf-next 02/11] net: Add BPF_XDP_EGRESS as a bpf_attach_type David Ahern
2020-02-27 3:20 ` [PATCH RFC v4 bpf-next 03/11] xdp: Add xdp_txq_info to xdp_buff David Ahern
2020-02-27 8:00 ` Jesper Dangaard Brouer
2020-02-27 11:58 ` Toke Høiland-Jørgensen
2020-02-28 3:01 ` David Ahern
2020-02-28 10:10 ` Toke Høiland-Jørgensen [this message]
2020-02-27 20:44 ` David Ahern
2020-02-28 10:07 ` Toke Høiland-Jørgensen
2020-02-28 10:41 ` Jesper Dangaard Brouer
2020-02-27 3:20 ` [PATCH RFC v4 bpf-next 04/11] net: Add IFLA_XDP_EGRESS for XDP programs in the egress path David Ahern
2020-02-27 3:20 ` [PATCH RFC v4 bpf-next 05/11] net: core: rename netif_receive_generic_xdp to do_generic_xdp_core David Ahern
2020-02-27 3:20 ` [PATCH RFC v4 bpf-next 06/11] net: core: Rename do_xdp_generic to do_xdp_generic_rx and export David Ahern
2020-02-27 3:20 ` [PATCH RFC v4 bpf-next 07/11] tun: set egress XDP program David Ahern
2020-03-02 3:32 ` Jason Wang
2020-03-02 3:52 ` David Ahern
2020-03-10 2:18 ` David Ahern
2020-02-27 3:20 ` [PATCH RFC v4 bpf-next 08/11] tun: Support xdp in the Tx path for skb David Ahern
2020-03-02 3:28 ` Jason Wang
2020-03-02 3:41 ` David Ahern
2020-03-03 10:46 ` Jesper Dangaard Brouer
2020-03-03 15:36 ` David Ahern
2020-02-27 3:20 ` [PATCH RFC v4 bpf-next 09/11] tun: Support xdp in the Tx path for xdp_frames David Ahern
2020-03-02 18:30 ` Alexei Starovoitov
2020-03-03 4:27 ` David Ahern
2020-03-03 9:08 ` Jesper Dangaard Brouer
2020-03-03 18:16 ` Alexei Starovoitov
2020-03-03 10:40 ` Jesper Dangaard Brouer
2020-03-10 3:06 ` David Ahern
2020-03-10 3:44 ` David Ahern
2020-03-10 9:03 ` Jesper Dangaard Brouer
2020-02-27 3:20 ` [PATCH RFC v4 bpf-next 10/11] libbpf: Add egress XDP support David Ahern
2020-02-27 3:20 ` [PATCH RFC v4 bpf-next 11/11] samples/bpf: xdp1, add " David Ahern
2020-02-27 11:55 ` [PATCH RFC v4 bpf-next 00/11] Add support for XDP in egress path Toke Høiland-Jørgensen
2020-02-27 16:22 ` Alexei Starovoitov
2020-02-27 17:06 ` Toke Høiland-Jørgensen
2020-02-27 18:37 ` Alexei Starovoitov
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=87lfonuind.fsf@toke.dk \
--to=toke@redhat.com \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=brouer@redhat.com \
--cc=dahern@digitalocean.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=dsahern@kernel.org \
--cc=jasowang@redhat.com \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=kuba@kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=prashantbhole.linux@gmail.com \
--cc=songliubraving@fb.com \
--cc=toshiaki.makita1@gmail.com \
--cc=yhs@fb.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.