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 1112AC43381 for ; Tue, 26 Mar 2019 15:07:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C02B92070D for ; Tue, 26 Mar 2019 15:07:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="j0tTJ9DV" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731774AbfCZPHS (ORCPT ); Tue, 26 Mar 2019 11:07:18 -0400 Received: from mail-pf1-f193.google.com ([209.85.210.193]:37296 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726111AbfCZPHS (ORCPT ); Tue, 26 Mar 2019 11:07:18 -0400 Received: by mail-pf1-f193.google.com with SMTP id 8so8203986pfr.4 for ; Tue, 26 Mar 2019 08:07: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=guzf6rQWlZMiMiZGfbtmWPov/hw6xB4XwUsCOzjCgw0=; b=j0tTJ9DVQuudteBauwdLH8pDlV8QGwldwPr2eVNztDO9jFWEEvgWEupyoK0Yq7B3JW yhfBrz81tgAz8j5GDwYtPKIghJBACdhl/SjQIeTjCEwl9SlVckdnB6Fh1HA2+JwyUn1H Armj0y1H1ovm81ZcCrXizbJITx+deDMiNFWK55TOJ6cjZ7Xy16MoKpq/OwYBRcwHueoM bnOGfRhxHWG5FadrLLPEqSWJqQkkftq2HJag7xDg+Ra6O17AAkhDP2OhYnwdWYghwsAr bdxH1hXsBACTCupZ3pjyTJ1qYra0AQKbcr7ENno9ABNv9W1au5YjX94QZ3lGbD5FLtyY vy4w== 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=guzf6rQWlZMiMiZGfbtmWPov/hw6xB4XwUsCOzjCgw0=; b=hBS3d9/1WzeQHUbz8vYKahmYMIXdQITZXGFlZfqxD0Gv+drqtJrnhYeTvRIWLk//Dm T82Ec97loa8L1lV4V7bGjDUWGu7/5jd/Yw5EY6vmTEgJKFQxNUWmeNqYKasjvOrsqc9Y JohlCFpewEKy7DIp4FbUyGTLTVmpzvMkWs0FWtFQQMKqmLn1W5QQ87uEm1MOc8zgxbyu mfs9qw5CVvqAdqzkZ0MO6YMqVGzHG+iR2PcLR/AZOPKC8RM6fgDUyXqTTAcF3sr1rnCv 92HXcv0uyQx1zYtwh9Rbsp8lJAkCJ+3HQxD6eNu8eWgKrOHqgDigW/73H25Fgad6G484 NfhA== X-Gm-Message-State: APjAAAWcrqFCYNcb2zxV27dsWgU6j29B9zrFbfz6Klp0FMaD+f2citHx nqKYaadPfpbJripambqLqNyAlSQW X-Google-Smtp-Source: APXvYqyQtYO97MAGS/qaGVq2xMTuSjW8CHvVz+cAHvlznHMsYU6m3X8vv+PnjSwGCAZDPqABCz5l3w== X-Received: by 2002:a62:4d45:: with SMTP id a66mr4173019pfb.250.1553612837724; Tue, 26 Mar 2019 08:07:17 -0700 (PDT) Received: from ast-mbp ([2620:10d:c090:180::f2b9]) by smtp.gmail.com with ESMTPSA id q86sm57265220pfi.171.2019.03.26.08.07.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2019 08:07:16 -0700 (PDT) Date: Tue, 26 Mar 2019 08:07:14 -0700 From: Alexei Starovoitov To: Eric Dumazet Cc: Eric Dumazet , brakmo , netdev , Martin Lau , Alexei Starovoitov , Daniel Borkmann , Kernel Team Subject: Re: [PATCH bpf-next 0/7] bpf: Propagate cn to TCP Message-ID: <20190326150712.4zi6idzva3ivaupg@ast-mbp> References: <20190323080542.173569-1-brakmo@fb.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000fc167-2653-7d3b-80d7-3feba06767cc@gmail.com> 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 01:06:23AM -0700, Eric Dumazet wrote: > > > On 03/25/2019 09:27 PM, Alexei Starovoitov wrote: > > On Mon, Mar 25, 2019 at 01:48:27AM -0700, Eric Dumazet wrote: > >> > >> > >> On 03/25/2019 01:33 AM, Eric Dumazet wrote: > >>> > >>> > >>> On 03/24/2019 09:19 AM, Alexei Starovoitov wrote: > >> > >>>> Cover letter also explains why bpf_skb_ecn_set_ce is not enough. > >>>> Please realize that existing qdiscs already doing this. > >>>> The patchset allows bpf-cgroup to do the same. > >>> > >>> Not the same thing I am afraid. > >> > >> To be clear Alexei : > >> > >> Existing qdisc set CE mark on a packet, exactly like a router would do. > >> Simple and universal. > >> This can be stacked, and done far away from the sender. > >> > >> We do not _call_ back local TCP to propagate cn. > > > > How do you classify NET_XMIT_CN ? > > > > It's exactly local call back to indicate CN into tcp from layers below tcp. > > tc-bpf prog returning 'drop' code means drop+cn > > whereas cgroup-bpf prog returning 'drop' means drop only. > > This patch set is fixing this discrepancy. > > > Except this does not work universally. > team or bonding or any tunnel wont propagate this signal. > (This is not something that can be fixed either, since qdisc can be installed there) > > This is a wrong design, and we want to get rid of it, and not 'fix it'. so after 20+ years linux qdisc design is wrong? bpf is about choice. We have to give people tools to experiment even when we philosophically disagree on the design. We need to make sure that new changes don't hurt existing use cases though. Performance bar has to remain high. > Back to my original concerns : > > 1) Larry just upstreamed the bpf_skb_ecn_set_ce(). > This part was fine, we did the same in fq_codel an fq already. ecn doesn't work with all congestion controls. > 2) > This ability to inject directly to TCP stack local drops is exactly confirming > why I complained earlier about why policers are often wrong. Trying to cope with them > is a nightmare. > > I feel you need this because your ebpf code was only able to accept or drop a packet (aka a policer) I've tried to explain several times that it's not about policer. That's why we called it NRM. Network Resource Manager. The goal is to control neworking resources in containerized environment where container scope is a cgroup. we could have done some of this logic from tc-bpf layer, but overhead is prohibitive there, since tc sees all packets while we need to control only certain cgroups and work properly within cgroup hierarchy. > EDT model allows for extending the skb->tstamp and not breaking TSQ logic : no local drops. we already discussed this. EDT is not applicable in all cases. > One of the ECN goal is to avoid drops in the first place, so adding something to favor > local drops sounds a step in the wrong direction. according to this statement BBR is wrong design then, since it ignores ecn? Anyway, to move forward... We're going to explore few ways to reduce tailcall pessimization in patch 4 and will proceed with the rest as-is.