From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 E0E343B25E; Fri, 6 May 2016 11:58:36 -0400 (EDT) Received: by mail-pf0-x22b.google.com with SMTP id 206so51452777pfu.0; Fri, 06 May 2016 08:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=JNJ+jWPfnuwc1YUzA7TMsHhzxwb/n8m55QSBJpYOt/o=; b=UVu3FkKPet6n1VjXUTKH3BUWgQqj1TaRmo6ZhATZlrE6bn1V5Di6OIEkHoYW6SeLCq xMnZQx7xRbQ2tbX+G3T2ADJ3R8A+Izwm3oSRhm1aRQkoWBIVkPlfC252kFSQXizQjilM forXaGaNnNxneN0qVnUkuSW6pSEF5AH51lshEmV8lktC0NPTmafgBBDchdgMLpsebvEc vu6qLk2AenfBSDmiz/h1BXqU1fFNPjwjqf+f0FADMedVCbaS2txWAHtDS6hAkRodTOUb 5y6c5kwfkgGPs5KFOHJGZ96A6iqwvb4tXs4uRCxVB73YI+aSsiNQ3ih85ta7rX9SiJSh 5+fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=JNJ+jWPfnuwc1YUzA7TMsHhzxwb/n8m55QSBJpYOt/o=; b=Dc6OmzLXkj//me9YyYnOVaAByXWjLKmB0cXRjP6gU18BUQlnTtPjIZUSmt3vsd9YtJ 2uipWLJGBB2aVMQbhVnIFtCGM6R3nV62sDYkK+xbQ7U/z3hR3fW1wuWtwg44s4A+pGvG ZrhMuceW0Fi8dBhOnhIeX/Zwn1b4T179WjDsW4Gr4DtSGwj1Pzoyg39dFj4gQclHQKk1 GNqU4XkBAqS8ST4ElSA3YaGB6NWRlHt+cj3Mx4EKNYBK9+OeMI03A/eEL9PMqKKcF0F0 qZZIG8kOeQlmm5q6JJejA8u0Gvweziup1MMtUOSgq9uIJYxz6nDSIsfkl8oeBtvgI9V2 a6Xw== X-Gm-Message-State: AOPr4FUqC/yuuD11rBAa2m8aeCpFljH9vkMi+SDLEYqu+N5QzbuWwSYNy70/81sex+BMSw== X-Received: by 10.98.42.216 with SMTP id q207mr18896819pfq.6.1462550316193; Fri, 06 May 2016 08:58:36 -0700 (PDT) Received: from ?IPv6:2620:0:1000:1704:89c0:6282:1159:133e? ([2620:0:1000:1704:89c0:6282:1159:133e]) by smtp.googlemail.com with ESMTPSA id ve11sm22130661pab.21.2016.05.06.08.58.35 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 May 2016 08:58:35 -0700 (PDT) Message-ID: <1462550314.13075.51.camel@edumazet-glaptop3.roam.corp.google.com> From: Eric Dumazet To: moeller0 Cc: Jesper Dangaard Brouer , Dave =?ISO-8859-1?Q?T=E4ht?= , make-wifi-fast@lists.bufferbloat.net, ath10k , "codel@lists.bufferbloat.net" , Jonathan Morton , Roman Yeryomin Date: Fri, 06 May 2016 08:58:34 -0700 In-Reply-To: <2BFC725A-F007-4D63-89BD-E1845F7E89BE@gmx.de> References: <865DA393-262D-40B6-A9D3-1B978CD5F6C6@gmail.com> <1462128385.5535.200.camel@edumazet-glaptop3.roam.corp.google.com> <1462136140.5535.219.camel@edumazet-glaptop3.roam.corp.google.com> <1462201620.5535.250.camel@edumazet-glaptop3.roam.corp.google.com> <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <1462464776.13075.18.camel@edumazet-glaptop3.roam.corp.google.com> <1462476207.13075.20.camel@edumazet-glaptop3.roam.corp.google.com> <542135C7-D7CC-4E33-B35B-C2AD259FA5AB@gmx.de> <20160506133323.0b190f47@redhat.com> <1462541156.13075.34.camel@edumazet-glaptop3.roam.corp.google.com> <2BFC725A-F007-4D63-89BD-E1845F7E89BE@gmx.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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: Fri, 06 May 2016 15:58:37 -0000 On Fri, 2016-05-06 at 17:25 +0200, moeller0 wrote: > Hi Eric, > > > On May 6, 2016, at 15:25 , Eric Dumazet wrote: > > Angles of attack : > > > > 1) I will provide a per device /sys/class/net/eth0/gro_max_frags so that > > we can more easily control amount of segs per GRO packets. It makes > > sense to have GRO, but not so much allowing it to cook big packets that > > might hurt FQ. > > This sounds great, so we can teach, say sqm to set this to a > reasonable value given the (shaped) bandwidth of a given interface. > Would something like this also make sense/is possible on the send side > for GSO/TSO? Problem of doing this on the send side, is that too big GRO packets would need to be segmented _before_ reaching qdisc, and we do not have such support. (The segmentation happens after qdisc before hitting device) In any case, that would be more cpu cycles. It is probably better to control GRO sizes to optimal values. I posted the fq_codel patch to netdev : https://patchwork.ozlabs.org/patch/619344/