From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 6F7443B260; Mon, 2 May 2016 11:01:45 -0400 (EDT) Received: by mail-pa0-x22f.google.com with SMTP id iv1so75067010pac.2; Mon, 02 May 2016 08:01:45 -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=uEiJf/jus2/9SiDYsPNJUri5KNw4WVX8f8GZ9ppkgrA=; b=laRWooRTCEcVCd/TbzcBEBbdt86R44/BO4gLxTpI27M+a/BiXpw5I+IFqB2YiTJBxT AbXBeLBXUgCFqvNnnJIJSHaOIB9gy5DdkiVIoI8UNeMk14optHjjOlL1r3TSjO6mnCR2 eW/H5XTa3AlqlY9H3avWcJDV3FH7g3M9D/xcMYIeh8n9BFO8YzUqq+ek1eaK99He5dVb qylMVEHVB1m5xAj3qzpbHvSQKMWb4NaoloXiDC3KQf6AAOJIZUoDr/afm0kICD3ZVNfY EN4uiZ++fXjpMJmKX1wX7/E0SGwPLpJgD71EKuO9EdRIsFygLMr3g+vxx04eyG5gar/i QyLg== 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=uEiJf/jus2/9SiDYsPNJUri5KNw4WVX8f8GZ9ppkgrA=; b=At01lAklGE28IXG2hJjo8i6Tzm/dgtzKGZnvuJTc3VGUHGauwn0fBAjuX/n26Y+LVE Kn5Kdv49JVpD5xgTDSrUDSA9EnlS3+NTaU7HWFzh6jEEGW1Iu6vaCNTffNu48RFbyutt 25um9qFkA7GwelJG4afJRZRYdlpi8je+0PTAQHxDDdT243lE21j2xwK0wSD/Hkza25LK gO7AaPnVzV2Tr4ocTKVtLJGQwjmb2RaYZNYwvL8VWrNjqeQpFbHRmNXUzVx35CRMX2Fw I+KWshN0jmifmdfMUOtQk1RFhPOVxy2/26zpMgFQpCqx8uB/rHZc82ZBLXEBt8ZqngIU +LMg== X-Gm-Message-State: AOPr4FU0ucDAYxa/7dAjxMb1JtE6hy3OGqYBJkLkw6QV/mHLGFjfiwvLe14jw596RqaGWA== X-Received: by 10.66.2.165 with SMTP id 5mr10697014pav.18.1462201304711; Mon, 02 May 2016 08:01:44 -0700 (PDT) Received: from ?IPv6:2620:0:1000:1704:b5a3:bf52:77a3:bc9a? ([2620:0:1000:1704:b5a3:bf52:77a3:bc9a]) by smtp.googlemail.com with ESMTPSA id n10sm46103249pfj.14.2016.05.02.08.01.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 May 2016 08:01:43 -0700 (PDT) Message-ID: <1462201302.5535.245.camel@edumazet-glaptop3.roam.corp.google.com> From: Eric Dumazet To: Roman Yeryomin Cc: Dave Taht , make-wifi-fast@lists.bufferbloat.net, "codel@lists.bufferbloat.net" , ath10k Date: Mon, 02 May 2016 08:01:42 -0700 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Codel] [Make-wifi-fast] fq_codel_drop vs a udp flood X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 15:01:45 -0000 On Mon, 2016-05-02 at 16:47 +0300, Roman Yeryomin wrote: > So it looks to me that fq_codel is just broken if it needs half of my resources. Agreed. When I wrote fq_codel, I was not expecting that one UDP socket could fill fq_codel with packets, since we have standard backpressure. SO_SNDBUF default on UDP does not allow to send more than 256 packets in a qdisc. So when sk_sndbuf limit is hit, sendmsg() either blocks or returns an error (if in non blocking mode) So it looks like someone really tries hard ;) To reproduce the issue I had to change (as root user) echo 1000000 >/proc/sys/net/core/wmem_default _and_ setup fq_codel with a much lower limit than the default 10240 limit tc qdisc replace dev eth0 root fq_codel limit 300 So please try this fix : https://patchwork.ozlabs.org/patch/617307/