From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 EC11B3B2A4 for ; Wed, 2 May 2018 11:25:39 -0400 (EDT) Received: from [172.16.11.125] ([134.76.241.253]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MLNpK-1fERrc0rkA-000Za7; Wed, 02 May 2018 17:25:30 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sebastian Moeller In-Reply-To: <152527388834.14936.16168261814447709834.stgit@alrua-kau> Date: Wed, 2 May 2018 17:25:28 +0200 Cc: Cake List Content-Transfer-Encoding: quoted-printable Message-Id: <7A6AB93A-565B-4251-B0A8-90631A9A152B@gmx.de> References: <152527385803.14936.8396262019181995139.stgit@alrua-kau> <152527388834.14936.16168261814447709834.stgit@alrua-kau> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3445.6.18) X-Provags-ID: V03:K1:PZ+87JL4yDsS5s+VrtB4zMSm8h9PIrDTbPSfWy0X3sxyuYGffQJ lbHNLeZi84PV3CNZ+6htxlzrapViPeJAqvRAnFKZOhcVU/cljs1PDM16As6sJ/6TpCLVXfQ 4U86VE279bM146XLI1VHSCx3/HUStrRjZkYdwYTIGIzuv/bPCuX+XY8QlBz2ZcJ54xAKpRW aMgK6jIUPnekc0LIYN7Mw== X-UI-Out-Filterresults: notjunk:1;V01:K0:jYJAPxj7WEc=:xERYfPqriDwVyB61wZ5A1c 0lxcIMTeLrIbnFOTIyebY3c9BdH939L9S9wx6ENPEdo5AYys5BvfxR/5VIdDNNBjA5x6/i9yi uluOWPesJOxCI1DCFTDeA2xYqWUAK7aQoIfcm/5je8gaYanT63EuTx6KqM+mG6nFQdi5RuHMG Wf4a6GTudKnajEVY6s2RspMmLLYbOSF6XCGFEh0I+M/tMBZZEw/cEuiaN0a4+Yy4t9aYuN3JG LpjaL4rQ88CTaK/E20S6935lQMStpZmWt3KGFYRhHCX31fj2aLeYwMm4jrwB3hgAAH5QQU3Of weub0ry9zwYpa790coI+PIRDguS31gZFBwUKHRPzAjFhdmwneE0yJFkgqyUOVrwUmU9taPfek ZBfo9CMh4GLxphn/NZ0F4eG2vDOKxsLCva72X4v2P9KYKiR+4GYUW3HWttRG6uBITYl9zjho4 Dg0pb97rgF106+SlJN592KVqrlXekKsMP2NRIxCxt6JroRfXbL2kmB7a3XzVEl3kYn1ehtEnV v892WeXv3NZ+nVPkoznK8HIn+xyf7d//a5he2WhkQkzYm7MlE8ABehw0EuFNLVCWfu5NcwQbj lm8Po4GsSoPE7sRExi8QSr5np5mt2M6t619SPHEhhfQo++9WwIo6jHtsZAshDUb0HyRxp7zUV TM/hZqoGIH0fYC2uz7GwVXQStZElz1i3zjzF6/uz1Z/pqE6GcxnZIzzZT4264/bcQ/dSs5jzO jzP7PdrG7dv37AGvJKTLSZBaQD2GrCZI13OM7PkKrnQAiPeu+n3SjKFlw9ZoG9WmM2fsCSHMI omknviN Subject: Re: [Cake] [PATCH net-next v7 6/7] sch_cake: Add overhead compensation support to the rate shaper 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: Wed, 02 May 2018 15:25:40 -0000 > On May 2, 2018, at 17:11, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > + /* The last segment may be shorter; we ignore this, = which means > + * that we will over-estimate the size of the whole GSO = segment > + * by the difference in size. This is conservative, so = we live > + * with that to avoid the complexity of dealing with it. > + */ > + len =3D shinfo->gso_size + hdr_len; > + } Hi Toke, so I am on the fence with this one, as the extreme case is having a = super packet consisting out of 1 full-MTU packet plus a tiny leftover in = that case we pay a 50% bandwidth sacrifice which seems a bit high. Nowm = I have no real feling how likely this full MTU plus 64 byte packet issue = is in real life, but in the past I often saw maximum packetsizes of = around 3K bytes on my router indicating that having a sup packet = consisting just out of two segments might not be that rare. So is there = an easy way for me to measure the probability of seeing that issue? I am all for sacrificing some bandwidth for better latency under load, = but few users will be happy with a 50% loss of bandwidth... Best Regards Sebastian=