From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (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 BA51B3B2A4 for ; Tue, 26 May 2020 05:48:05 -0400 (EDT) Received: by mail-lj1-x243.google.com with SMTP id v16so23721932ljc.8 for ; Tue, 26 May 2020 02:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=5IaU541hNIP4omLKpxtI2jYVZTNxcAeuadNiizP1amg=; b=T5gBORGtXftOx0uatG8myBi1+Cg3R1nD9JCJWaKiX7IlIMNKCGDmfUqqIz+zsvA1fs G/Wse/urdCphqZ60xCaTiKY/yY4CTWtuDLColcewWUN6QmTX4J2Ee7/ciffrgcDj31v0 F08c+woeAowj8WeBcJhkhz8kOZ9ik2l4+TI4P4fVt51ZUaUN8fJE5OJwLQ/My2yvQwhd Xxmi5YCpoQGUO3SCbDxlGH7p3i424ktdFxGDUqF4Jeo30/5H73wDx10eFaHBY7h4St87 HYnqbqUzKHZdx3RJr6baaL4UkJvyAqO5U/i6skmm/kZ7vJemx/gwl32xEyZW4CiB7OmZ tSkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=5IaU541hNIP4omLKpxtI2jYVZTNxcAeuadNiizP1amg=; b=BV1IfOjKJys2x9Y++UwGpQpAV/jD0dPyzhJEGEIvAlgVtiMBLBFnkaPphItn0ZFSXZ LIlHswMEX0tP/w04+J6ZbGZcJXw2yJAdODNgDkHxd8FgaLG4nZX349PB8FBRaCSAoOVb j+f+7lkMwbyHJmzS0L5WZWi5S7HDaDS13Gz29E1JMh1mSzyeJg/NWdNrCZosWh2QmSSe JCXe+2gbRRuJKVwDX3y6rOJu9axO4NtK1I6HSvCgFQHSiLAnLSrI8mWb2G/hEoc+bgKg l+9l/InGSmcjvnT/NWR3fqDl7jx9EqOEwyX8IGKe7atGX81dOWX9lcvIaz7OLiZVV7R0 T+ow== X-Gm-Message-State: AOAM5325n/+VmkapIVkCb4nZbt7yHw+hzpmHv6iZSYImUCEh05iQV/r7 2eYx6bKwlMQMtUWFvcxUo0XKLOYu6NCqTgTfXmk/+3pL X-Google-Smtp-Source: ABdhPJw08J1dvQNyTdM6fEIQ5ljtr92rHWkGILEF3tJdLvLtNkxQWsuJdoP+YXcCsGUeF3Sy/s2Pp7u63DbKdnZNPPs= X-Received: by 2002:a2e:9792:: with SMTP id y18mr183727lji.389.1590486484118; Tue, 26 May 2020 02:48:04 -0700 (PDT) MIME-Version: 1.0 From: Jose Blanquicet Date: Tue, 26 May 2020 11:47:27 +0200 Message-ID: To: bloat@lists.bufferbloat.net Cc: marco maniezzo Content-Type: text/plain; charset="UTF-8" Subject: [Bloat] CPU consumption using TC-TBF and TC-POLICE to limit rate X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 09:48:06 -0000 Hi everyone, We have an embedded system with limited CPU resources that acts as gateway to provide Internet access from LTE to a private Wi-Fi network. Our problem is that the bandwidth on LTE and Wi-Fi links is higher than what the system is able to handle thus it reaches 100% of CPU load when we perform a simple speed test from a device connected to our Wi-Fi Hotspot. Therefore, we want to limit the bandwidth to avoid system gets saturated is such use-case. To do so, we thought to use the QDISC-TBF on the Wi-Fi interface. For instance, to have 10Mbps: tc qdisc add dev wlan0 root tbf rate 10mbit burst 12500b latency 50ms It worked correctly and maximum rate was limited to 10Mbps. However, we noticed that the CPU load added by the TBF was not negligible for our system. In fact, we compared the CPU load when limitation was done by TBF and by the device on the private network, e.g. wget tool with parameter "--limit-rate". As result, we found that the CPU load when using TBF was 10-15% higher. Then, we thought that using traffic shaping in egress, packets need to be un-natted (which takes CPU) and pass through the system to then get dropped. Therefore, we tried to use an incoming policer instead of egress traffic shaping as following: tc qdisc add dev eth0 ingress handle ffff: tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0 police rate 10mbit burst 1m drop Unfortunately, as per egress traffic shaping, we still obtained a high CPU cost because of rate limiting. However, also in this case, we are not sure we chose the most efficient option in terms of CPU cost to police in ingress. Given that, we were wondering if we are doing wrong by choosing TBF? Or maybe we are using wrong parameters? We found everywhere that TBF is the simplest way to limit the rate thus we suppose it is also the most efficient QDISC. Is our supposition correct? Or there is another way to limit rate well-known by its low CPU consumption? Any suggestion is welcome, just taking into account we are using libnl-3.2.28 and linux-kernel 3.18. In case, we could change libnl but not kernel version, at most some specific patches. Thanks in advance for the support! Jose Blanquicet