From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2FD9FC43381 for ; Tue, 26 Mar 2019 17:01:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E30D22070D for ; Tue, 26 Mar 2019 17:01:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fQPkw1oC" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731738AbfCZRBS (ORCPT ); Tue, 26 Mar 2019 13:01:18 -0400 Received: from mail-pf1-f194.google.com ([209.85.210.194]:39651 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730449AbfCZRBS (ORCPT ); Tue, 26 Mar 2019 13:01:18 -0400 Received: by mail-pf1-f194.google.com with SMTP id i17so8359094pfo.6 for ; Tue, 26 Mar 2019 10:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=c9tgjlYyDk4w/bskOeoE6J6Az3HtkMD6VjEQ2S2SneA=; b=fQPkw1oCxeQgCPOYfKwNAq2Lmme44wg36CmslVRccceopzH84eSbEJ8bExjW1DrEMe i95xW/hZJmyNbGRRUvssl1uG+9EUTK/UA0T55esViEjK3AiLHOBdpk+xVlIIazIAXHBb JNl9cbvypt/+SQXpGCsr2bQQDoziLS8xH+i4zL376oij45URsepiRq5sWy2hDU7U3tTD RD6y8EX7ycsL4jdhP30qdL9azrwxB+O1TPx8jN5Fbf3DAeY7vhFCSETlP4KRh1CxIlga ctblNl3lloQ1WAtxNlyTySKi89NAgP1ypfPj4pfpyI7aMcmHmBupN5MyBTsATqtksLuJ vcuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=c9tgjlYyDk4w/bskOeoE6J6Az3HtkMD6VjEQ2S2SneA=; b=l0fSo3MZe3XyosCNGFCuNZdmAbsYyxm2tHKn59Xkin6TJqUQyB48E8y18MRt0e2EAF alPcXX1VO+lZ1bsUArNJMW5KPlNHFhBIDfEKG3l5Uqa4g2VuingDRRLWO8ygmYKg0Mm/ qEJsgABdS97CjUC0h5nmihhIm1YMycxuB8JWzsLzvhL3WdbW7Pgw8td1UPBvKO6/C6r4 mu8cyZZ0+L4AzN1id3L8JlSEvTP6/PS5LcaxyGFDZSUwPZ9vUPa5N8+0wPNdbPIYa8Dj j9bZnEp3OPVSP0YPvgMPlFr4bmz9Kz1QjQ36gZDuGwGdhziN9c7g76Vm25ukqGlrTzsG X8iQ== X-Gm-Message-State: APjAAAU0oDB0jj1+vVlzTgoY9R/EUuhfCs/YTU1n+ygHd+2o7Sw2B3BJ zguUnnelu42I6/qPiXQcvUI= X-Google-Smtp-Source: APXvYqz9FkvgeiLWM84/uJOUCXiXmj4OYBxNduKaQiIXVRFkvDxjZez+zzd+HFcmd4vd5jPwX4+bjw== X-Received: by 2002:aa7:9286:: with SMTP id j6mr30154166pfa.47.1553619677616; Tue, 26 Mar 2019 10:01:17 -0700 (PDT) Received: from ast-mbp ([2620:10d:c090:180::cdb9]) by smtp.gmail.com with ESMTPSA id u62sm51419187pfa.124.2019.03.26.10.01.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2019 10:01:16 -0700 (PDT) Date: Tue, 26 Mar 2019 10:01:14 -0700 From: Alexei Starovoitov To: Eric Dumazet Cc: brakmo , netdev , Martin Lau , Alexei Starovoitov , Daniel Borkmann , Kernel Team Subject: Re: [PATCH bpf-next 0/7] bpf: Propagate cn to TCP Message-ID: <20190326170112.h5jxmd7ji2jwqi5u@ast-mbp> References: <704cb63c-13cd-f0ed-d546-18e3596bb63d@gmail.com> <20190323154124.gorqpaqex7ihfs6d@ast-mbp> <0841fe0d-7fcd-bb59-3694-af9969cec5af@gmail.com> <20190324161911.h5eotv2j7f5avcpm@ast-mbp> <5aec97f1-545a-f898-fdd9-c5821d5c6e39@gmail.com> <27e91d11-b454-924d-58ab-a68a0aade906@gmail.com> <20190326042704.7szakyos3ofemowl@ast-mbp> <000fc167-2653-7d3b-80d7-3feba06767cc@gmail.com> <20190326150712.4zi6idzva3ivaupg@ast-mbp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180223 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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.