From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (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 02DC03B25D; Sun, 1 May 2016 14:26:30 -0400 (EDT) Received: by mail-ob0-x232.google.com with SMTP id x1so53701469obt.0; Sun, 01 May 2016 11:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=WHTNfEJg3gJ8k+r0DpGM6ojl0WHzVFkdlcFBMiLUE3Y=; b=OaacG/taZx7WYb0VNnAenvDLOjE1mm9W7sm1XpIzLqZFF4zCYRCNej+hkzQdOMdEUf dmmRwqn/cOuzOjRHFFjpRV2OTZiE/4q05qwM3HtvlyFKNO7K2+wBUs99XV7xJmuJtxYC Y6gNnX44aGOyl8DvnV3EYG9UTxLm9nRdVzFuCEffxB7LLddNf+Dtd5Gf6vBOTX1yMc0h 2qEFW/nf53XnGiRf1X6l/xrmf4Hvs9xDFVG31Jw+An4mtZT9LqBdj83owgNnLtMhC7WI uL0WXW5YRMfiWKNpcNZWgNg+5cUD46gTpmMxGDzicNmyqIfuKhy5Lisv+uxxD5ZeQwBt 5oFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=WHTNfEJg3gJ8k+r0DpGM6ojl0WHzVFkdlcFBMiLUE3Y=; b=e/+5oC2raBHqvT/Fs6d6qjT58kGpYNQQmnrB7K7J40roGjbDgaA5VmDVfGkKjdoWYJ F+0+WR48ayNsVWUjdmyUqx27xi4JxdsgkWbc3O0vh3LTb1K1GrJ3jQv7VTvkUCjMkuYG vGka/mQzYfy7Opc0w2xRDJHmdCyxxyJZa2lUN8YqTET/Ppug79YbdiYytbPEdR2XT1oH fJfTPvgb+POXodzpiGj7/9NEq1hOOpQVYiWAHkUjGeX2z1u+tiafBXlHau1k8uBo0x+/ 98Qq5DDawdTnvArIJMc4v9i8er0n2QeLyau/9BLxg646KIFQ7Wq3r3YoUXUZ93nH8YKI Dn/Q== X-Gm-Message-State: AOPr4FXgtiviOhKDqV+avxcHSmCDojMPw0YldtK6Ef/SZlXg3p4rHxJGUVOW9PsKdzNOypfQz3zwzsiVinysKQ== MIME-Version: 1.0 X-Received: by 10.182.118.170 with SMTP id kn10mr5885125obb.57.1462127190475; Sun, 01 May 2016 11:26:30 -0700 (PDT) Received: by 10.202.78.23 with HTTP; Sun, 1 May 2016 11:26:30 -0700 (PDT) In-Reply-To: <1462125592.5535.194.camel@edumazet-glaptop3.roam.corp.google.com> References: <1462125592.5535.194.camel@edumazet-glaptop3.roam.corp.google.com> Date: Sun, 1 May 2016 11:26:30 -0700 Message-ID: From: Dave Taht To: Eric Dumazet Cc: ath10k , "codel@lists.bufferbloat.net" , make-wifi-fast@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [Codel] fq_codel_drop vs a udp flood X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 18:26:31 -0000 On Sun, May 1, 2016 at 10:59 AM, Eric Dumazet wrot= e: > On Sat, 2016-04-30 at 20:41 -0700, Dave Taht wrote: >> >>> >> >>> 45.78% [kernel] [k] fq_codel_drop >> >>> 3.05% [kernel] [k] ag71xx_poll >> >>> 2.18% [kernel] [k] skb_release_data >> >>> 2.01% [kernel] [k] r4k_dma_cache_inv >> >> The udp flood behavior is not "weird". The test is wrong. It is so fill= ing >> the local queue as to dramatically exceed the bandwidth on the link. > > Well, just _kill_ the offender, instead of trying to be gentle. I like it. :) Killing off a malfunctioning program flooding the local network interface (intentionally or unintentionally) seems like a useful idea. it will break some test tools that deserve to be broken, too. > fq_codel_drop() could drop _all_ packets of the fat flow, instead of a > single one. > > It is too cpu intensive to be kind to the elephant, since under pressure > fq_codel_drop() needs to be called for every enqueue. A somewhat gentler approach might be drop 3 packets or more per fq_codel_drop round - or "nearly" the entire flow (all but the last packet). But sure, dropping *all* of an unresponsive elephant (as more will be arriving), in the event of the extreme overload that hitting fq_codel_drop represents, sounds pretty good. > Really, we should not try to let inelastic flows hurt us. +10. > > I can provide a patch. Killing the bad program, and dropping all of the fattest flow strike me as two patches.[1] This approach is akin to some of the thoughts in here: https://tools.ietf.org/html/draft-ietf-tsvwg-circuit-breaker-14 [2] ... all that said, is there any way to exert flow control on a udp socket from down in these layers? [1] what sort of error code should a program killed for flooding the networ= k return? [2] I don't actually agree with some of the thinking in the circuit breakers doc, but.... this is something of an outgrowth of the obsolete and wrong source quench idea, which might be useful history for someone: https://tools.ietf.org/html/rfc6633. --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org