netdev - Re: [RFC PATCH 00/17] xdp: Add packet queueing and scheduling capabilities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YtRLC5ILXZOre8D7@pop-os.localdomain>
Date:   Sun, 17 Jul 2022 10:46:51 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau <martin.lau@...ux.dev>,
        Song Liu <song@...nel.org>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>,
        Stanislav Fomichev <sdf@...gle.com>,
        Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        Björn Töpel <bjorn@...nel.org>,
        Magnus Karlsson <magnus.karlsson@...el.com>,
        Maciej Fijalkowski <maciej.fijalkowski@...el.com>,
        Jonathan Lemon <jonathan.lemon@...il.com>,
        Mykola Lysenko <mykolal@...com>,
        Kumar Kartikeya Dwivedi <memxor@...il.com>,
        netdev@...r.kernel.org, bpf@...r.kernel.org,
        Freysteinn Alfredsson <freysteinn.alfredsson@....se>
Subject: Re: [RFC PATCH 00/17] xdp: Add packet queueing and scheduling
 capabilities

On Wed, Jul 13, 2022 at 01:14:08PM +0200, Toke Høiland-Jørgensen wrote:
> Packet forwarding is an important use case for XDP, which offers
> significant performance improvements compared to forwarding using the
> regular networking stack. However, XDP currently offers no mechanism to
> delay, queue or schedule packets, which limits the practical uses for
> XDP-based forwarding to those where the capacity of input and output links
> always match each other (i.e., no rate transitions or many-to-one
> forwarding). It also prevents an XDP-based router from doing any kind of
> traffic shaping or reordering to enforce policy.
> 

Sorry for forgetting to respond to your email to my patchset.

The most important question from you is actually why I give up on PIFO.
Actually its limitation is already in its name, its name Push In First
Out already says clearly that it only allows to dequeue the first one.
Still confusing?

You can take a look at your pifo_map_pop_elem(), which is the
implementation for bpf_map_pop_elem(), which is:

       long bpf_map_pop_elem(struct bpf_map *map, void *value)

Clearly, there is no even 'key' in its parameter list. If you just
compare it to mine:

	BPF_CALL_2(bpf_skb_map_pop, struct bpf_map *, map, u64, key)

Is their difference now 100% clear? :)

The next question is why this is important (actually it is the most
important)? Because we (I mean for eBPF Qdisc users, not sure about you)
want the programmability, which I have been emphasizing since V1...

Clearly it is already too late to fix bpf_map_pop_elem(), we don't want
to repeat that mistake again.

More importantly, the latter can easily implement the former, as shown below:

bpf_stack_for_min; // Just BPF_MAP_TYPE_STACK

push(map, key, value)
{
  bpf_stack_for_min.push(min(key, bpf_stack_for_min.top()));
  // Insert key value pair here
}

pop_the_first(map, value)
{
   val = pop_any(map, bpf_stack_for_min.top());
   *value = val;
   bpf_stack_for_min.pop();
}

BTW, what is _your_ use case for skb map and user-space PIFO map? I am
sure you have uses case for XDP, it is unclear what you have for other
cases. Please don't piggy back use cases you don't have, we all have to
justify all use cases. :)

Thanks.