From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id BF3213BA8E for ; Tue, 1 May 2018 12:06:56 -0400 (EDT) Received: by mail-pf0-x22c.google.com with SMTP id p12so9390225pff.13 for ; Tue, 01 May 2018 09:06:56 -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=faKco7Ai9AkczB/wV9BoI0xxcr3Bah1Lr1R+E2meV0U=; b=HbiWWsNjQ7v3ic2dBZg9ky4zJ5GeW46y6amwtOyWfbZlvUkCzrZwEsA/li5ub4bwdi 0IaqVV0vWb4Weq3zat2LiUqCTXiX95BbmXnQ+1CZ1GHI9bV5rKreSoh8dbxQJR7+DEMI C8Ye7qS7ftDraq5LDTlbwyFHzrOVAJ1bsm4wNU2bCsVhKh2j7g9IWek5IwfsVlAaTVS9 Ygn7f6mnfymfdATWqwH+7FhAFR/uj5m2sx3QGMUHSeUwkmEvqKYLddW+KEI7OTWL/H4F //2bJhXaKY5YCy7uXUCuBqCVMkNVd595TIzCcpRZRGkj2LGJ2ABYglPd/T00uqu+kNnC 7eCg== 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=faKco7Ai9AkczB/wV9BoI0xxcr3Bah1Lr1R+E2meV0U=; b=UoCNUIzM/cJgLzDHjmVAJitnVnW4lgbWwnJ5qJ+VVDoOjBqy4sPHCeiWIt9nSGVaI0 JfK/vMcIxCQ7KMMKs5x/zzKehcNHPMPmRFN7Ktgyi/x/uNZoMVz3dZRoHMcEM4f+GdNS anYVvpSuSU2g8Mktq/6BagmS46GnojbR0/aXtRSxcqZo3rEIMQIfZjpOGdTZ2pQQdCIY drJTFp/wC5/4tJ27qvIxcXw0/D1Vjrturwk4s4SdQ+XY75MfFQbihwKIguG6TkcJKVmX r8V/oxMjs3k3ml91QZBpZZwez+1L77n4ApUcNvFYZUPZQzrZnfhMcI/9VWPFeQkQwI+s vMcQ== X-Gm-Message-State: ALQs6tD0IjorXCUYA0fv7mbSdbNOXVo19Te6yt5zbbyMr+937Wed3Ktc n+huAFvI2aGGASv8/Gk3e56IHBwT X-Google-Smtp-Source: AB8JxZpAit01zl/eA+ZC+41uKiOmesWoA9KogOW89a7FV8xdemaSYsHpzCfWdlmqdII2dzsz6Aik4g== X-Received: by 10.98.67.83 with SMTP id q80mr16246861pfa.228.1525190815699; Tue, 01 May 2018 09:06:55 -0700 (PDT) Received: from ?IPv6:2620:15c:2c1:200:55c7:81e6:c7d8:94b? ([2620:15c:2c1:200:55c7:81e6:c7d8:94b]) by smtp.gmail.com with ESMTPSA id v8sm18018308pff.89.2018.05.01.09.06.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 May 2018 09:06:54 -0700 (PDT) To: Dave Taht , Cong Wang Cc: =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= , Linux Kernel Network Developers , Cake List References: <20180429213439.7389-1-toke@toke.dk> From: Eric Dumazet Message-ID: Date: Tue, 1 May 2018 09:06:53 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Cake] [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 16:06:57 -0000 On 04/30/2018 02:27 PM, Dave Taht wrote: > I actually have a tc - bpf based ack filter, during the development of > cake's ack-thinner, that I should submit one of these days. It > proved to be of limited use. > > Probably the biggest mistake we made is by calling this cake feature a > filter. It isn't. > > Maybe we should have called it a "thinner" or something like that? In > order to properly "thin" or "reduce" an ack stream > you have to have a queue to look at and some related state. TC filters > do not operate on queues, qdiscs do. Thus the "ack-filter" here is > deeply embedded into cake's flow isolation and queue structures. A feature eating packets _is_ a filter. Given that a qdisc only sees one direction, I really do not get why ack-filter is so desirable in a packet scheduler. You have not provided any numbers to show how useful it is to maintain this code (probably still broken btw, considering it is changing some skb attributes). On wifi (or any half duplex medium), you might gain something by carefully sending ACK not too often, but ultimately this should be done by TCP stack, in well controlled environment [1], instead of middle-boxes happily playing/breaking some Internet standards. [1] TCP stack has the estimations of RTT, RWIN, throughput, and might be able to avoid flooding the network with acks under some conditions. Say RTT is 100ms, and we receive 1 packet every 100 usec (no GRO aggregation) Maybe we do not really _need_ to send 5000 ack per second (or even 10,000 ack per second if a hole needs a repair) Also on wifi, the queue builds in the driver queues anyway, not in the qdisc. So ACK filtering, if _really_ successful, would need to be modularized. Please split Cake into a patch series. Presumably putting the ack-filter on a patch of its own.