From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Eric Dumazet <eric.dumazet@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 10:01:14 -0700 [thread overview]
Message-ID: <20190326170112.h5jxmd7ji2jwqi5u@ast-mbp> (raw)
In-Reply-To: <dc646bb8-d55c-affa-252b-1299535a2ea7@gmail.com>
On Tue, Mar 26, 2019 at 08:43:11AM -0700, Eric Dumazet wrote:
>
>
> 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.
root and children qdiscs propagate the return value already.
different unrelated qdiscs are just like different physical switches.
they can communicate only via on the wire protocol.
nothing wrong with that.
But not everything can and should communicate over the wire.
> > 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.
Clearly a misunderstanding. Please see samples/bpf/hbm_out_kern.c
The source code of bpf program is not only public, but algorithm is well documented.
> I doubt many TCP users will have the skills/money to benefit from this.
majority of bpf features are actively used and often not by authors
who introduced them.
> Meanwhile, we as a community have to maintain a TCP/IP stack with added hooks and complexity.
your herculean effort to keep tcp stack in excellent shape
is greatly appreciated. No doubt about that.
> It seems TCP stack became a playground for experiments.
exactly.
The next tcp congestion control algorithm should be implementable in bpf.
If kernel was extensible to that degree likely there would have been
no need to bypass it and invent quic.
next prev parent reply other threads:[~2019-03-26 17:01 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
2019-03-26 17:01 ` Alexei Starovoitov [this message]
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=20190326170112.h5jxmd7ji2jwqi5u@ast-mbp \
--to=alexei.starovoitov@gmail.com \
--cc=Kernel-team@fb.com \
--cc=ast@fb.com \
--cc=brakmo@fb.com \
--cc=daniel@iogearbox.net \
--cc=eric.dumazet@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox