From: Eric Dumazet <eric.dumazet@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: brakmo <brakmo@fb.com>, netdev <netdev@vger.kernel.org>,
Martin Lau <kafai@fb.com>, Alexei Starovoitov <ast@fb.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH bpf-next 0/7] bpf: Propagate cn to TCP
Date: Tue, 26 Mar 2019 08:43:11 -0700 [thread overview]
Message-ID: <dc646bb8-d55c-affa-252b-1299535a2ea7@gmail.com> (raw)
In-Reply-To: <20190326150712.4zi6idzva3ivaupg@ast-mbp>
On 03/26/2019 08:07 AM, Alexei Starovoitov wrote:
> so after 20+ years linux qdisc design is wrong?
Yes it is how it is, return values can not be propagated back to the TCP stack in all cases.
When a packet is queued to Qdisc 1, there is no way we can return
a value that can represent what the packet becomes when dequeued later and queued into Qdisc 2.
Also some qdisc take their drop decision later (eg : codel and fq_codel), so ->enqueue() will
return a success which might be a lie.
> bpf is about choice. We have to give people tools to experiment even
> when we philosophically disagree on the design.
Maybe, but I feel that for the moment, the choice is only for FB, and rest
of the world has to re-invent private ebpf code in order to benefit from all of this.
I doubt many TCP users will have the skills/money to benefit from this.
Meanwhile, we as a community have to maintain a TCP/IP stack with added hooks and complexity.
It seems TCP stack became a playground for experiments.
next prev parent reply other threads:[~2019-03-26 15:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-23 8:05 [PATCH bpf-next 0/7] bpf: Propagate cn to TCP brakmo
2019-03-23 8:05 ` [PATCH bpf-next 1/7] bpf: Create BPF_PROG_CGROUP_INET_EGRESS_RUN_ARRAY brakmo
2019-03-23 8:05 ` [PATCH bpf-next 2/7] bpf: cgroup inet skb programs can return 0 to 3 brakmo
2019-03-23 8:05 ` [PATCH bpf-next 3/7] bpf: Update __cgroup_bpf_run_filter_skb with cn brakmo
2019-03-23 8:05 ` [PATCH bpf-next 4/7] bpf: Update BPF_CGROUP_RUN_PROG_INET_EGRESS calls brakmo
2019-03-23 8:05 ` [PATCH bpf-next 5/7] bpf: sysctl for probe_on_drop brakmo
2019-03-23 8:05 ` [PATCH bpf-next 6/7] bpf: Add cn support to hbm_out_kern.c brakmo
2019-03-23 8:05 ` [PATCH bpf-next 7/7] bpf: Add more stats to HBM brakmo
2019-03-23 9:12 ` [PATCH bpf-next 0/7] bpf: Propagate cn to TCP Eric Dumazet
2019-03-23 15:41 ` Alexei Starovoitov
2019-03-24 5:36 ` Eric Dumazet
2019-03-24 16:19 ` Alexei Starovoitov
2019-03-25 8:33 ` Eric Dumazet
2019-03-25 8:48 ` Eric Dumazet
2019-03-26 4:27 ` Alexei Starovoitov
2019-03-26 8:06 ` Eric Dumazet
2019-03-26 15:07 ` Alexei Starovoitov
2019-03-26 15:43 ` Eric Dumazet [this message]
2019-03-26 17:01 ` Alexei Starovoitov
2019-03-26 18:07 ` Eric Dumazet
2019-03-26 8:13 ` Eric Dumazet
2019-03-24 5:48 ` Eric Dumazet
2019-03-24 1:14 ` Lawrence Brakmo
2019-03-24 5:58 ` Eric Dumazet
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=dc646bb8-d55c-affa-252b-1299535a2ea7@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=Kernel-team@fb.com \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@fb.com \
--cc=brakmo@fb.com \
--cc=daniel@iogearbox.net \
--cc=kafai@fb.com \
--cc=netdev@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 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.