[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <704cb63c-13cd-f0ed-d546-18e3596bb63d@gmail.com>
Date: Sat, 23 Mar 2019 02:12:39 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: brakmo <brakmo@...com>, netdev <netdev@...r.kernel.org>
Cc: Martin Lau <kafai@...com>, Alexei Starovoitov <ast@...com>,
Daniel Borkmann <daniel@...earbox.net>,
Eric Dumazet <eric.dumazet@...il.com>,
Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH bpf-next 0/7] bpf: Propagate cn to TCP
On 03/23/2019 01:05 AM, brakmo wrote:
> This patchset adds support for propagating congestion notifications (cn)
> to TCP from cgroup inet skb egress BPF programs.
>
> Current cgroup skb BPF programs cannot trigger TCP congestion window
> reductions, even when they drop a packet. This patch-set adds support
> for cgroup skb BPF programs to send congestion notifications in the
> return value when the packets are TCP packets. Rather than the
> current 1 for keeping the packet and 0 for dropping it, they can
> now return:
> NET_XMIT_SUCCESS (0) - continue with packet output
> NET_XMIT_DROP (1) - drop packet and do cn
> NET_XMIT_CN (2) - continue with packet output and do cn
> -EPERM - drop packet
>
I believe I already mentioned this model is broken, if you have any virtual
device before the cgroup BPF program.
Please think about offloading the pacing/throttling in the NIC,
there is no way we will report back to tcp stack instant notifications.
This patch series is going way too far for my taste.
This idea is not new, you were at Google when it was experimented by Nandita and
others, and we know it is not worth the pain.
Powered by blists - more mailing lists