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=-0.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 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 91CC5C43381 for ; Tue, 26 Mar 2019 08:06:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 61BD120857 for ; Tue, 26 Mar 2019 08:06:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dgWQ+8nX" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730133AbfCZIG2 (ORCPT ); Tue, 26 Mar 2019 04:06:28 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:50252 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726111AbfCZIG1 (ORCPT ); Tue, 26 Mar 2019 04:06:27 -0400 Received: by mail-wm1-f68.google.com with SMTP id z11so11618093wmi.0 for ; Tue, 26 Mar 2019 01:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=GNHcTOciyhC2rr5kU0U4SkbhhoDRchPB0QPNAomwTLM=; b=dgWQ+8nXMBR0DLnIVQOR3qBNLjypT5QTjd+L4Q441iP/ivdWOA6gmge4etu/AGKAKU 2+EBsS8hUWcMB6AxRwh6BRZWCOWn8TxwygC20S6Wt7xrBVfDLd08BCSE2CLbnnOxXnW6 8mCPJDEK57yyNoVL06cSZ7A7oMDyu6uJlo1FKhs/a+vZdSQSkwakwmgESFeI/VQKb1CR blel9xdc7c6ANT5xFJBN7zk2427i2HcgBWd8fDsL7BH6YiTaCyFrfBDBkiLkvZCyY28G D+AEzR8r6omam8BGID9HwhHY4pPuHhVQR7T11vakqXTCmdvOA8XzBAxauUpNvfEiwcgw KLBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GNHcTOciyhC2rr5kU0U4SkbhhoDRchPB0QPNAomwTLM=; b=GUfqu/AB12YFKE4rAhwwVTzw6NfmpRZHB99TPlzjmJyhpv2TTO6vZ5DwRzhzI1scvp j0OKhqfdsIb9FGKISStXrYint/u2E/lgptQFcoVeFEOVNDFBPM2zusWsSvL8pNgrWDF3 W0TaLPRIn/V15n2auaN9g4hoVJK4ZZ8J8SQmR4UjzoFTbdFXRGmusfDSXiDuNvyQAsMG VJDbNc2nlpRosgefwcDrxVRaEsYwAUBoSuVpDI3YGc98nlXdsg3i7LZLvZrCvAGvvNry Y77JJQvXo8JNb2IPCJp0rQCNUkw/3pVQDZ6oY1xUtqXPMv6wrbijL9jVYxO0eUOp9yL3 x3Cw== X-Gm-Message-State: APjAAAVWpAUZSj0yEX/xKt2ng/R+BKW8jR/lW3KpnHZg+7uxxmK+gWT2 cAchfAq9ZozN/zL0cod20+w= X-Google-Smtp-Source: APXvYqwu/q2eLss+Cgxx15R2NUIgTncR5kvvJf46ZxSjmk5/qSSbXwjil1bv8Zuj7Mv82KJn6CwvVg== X-Received: by 2002:a1c:2394:: with SMTP id j142mr13932255wmj.111.1553587585578; Tue, 26 Mar 2019 01:06:25 -0700 (PDT) Received: from [192.168.8.147] (26.249.23.93.rev.sfr.net. [93.23.249.26]) by smtp.gmail.com with ESMTPSA id o133sm19318016wmb.18.2019.03.26.01.06.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2019 01:06:24 -0700 (PDT) Subject: Re: [PATCH bpf-next 0/7] bpf: Propagate cn to TCP To: Alexei Starovoitov , Eric Dumazet Cc: brakmo , netdev , Martin Lau , Alexei Starovoitov , Daniel Borkmann , Kernel Team 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> From: Eric Dumazet Message-ID: <000fc167-2653-7d3b-80d7-3feba06767cc@gmail.com> Date: Tue, 26 Mar 2019 01:06:23 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190326042704.7szakyos3ofemowl@ast-mbp> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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'. 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. 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) EDT model allows for extending the skb->tstamp and not breaking TSQ logic : no local drops. 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.