From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic312-25.consmr.mail.ir2.yahoo.com (sonic312-25.consmr.mail.ir2.yahoo.com [77.238.178.96]) (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 A067F3CB35 for ; Tue, 26 May 2020 08:04:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s2048; t=1590494676; bh=i2zyLXbAsmEYbb4RV6iG9XVnHxYxNC9oSwTt/9l+dZM=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=SCV/wltS44HpIyEB6keSkHG0TZVFT2BF9AUi12c3d/mdTVQhRnL84bgggaonCRKNgNXm8crdzGOrTwwdC5Z9TQc9uWMOwMv7z4fq42FPEFaCDIYHnfiVXuYb54mMZcmkIG/KMgxHttJrIMlG99THY+CSs4rXlTDCUOEZKTfdtjfVVpgYm2kchN9qg6SrUgxXc5Ad95TQjqJ30J/FKT0CCogcUsob555kjaKau5p662Ksj/6HDRg8eWejS7OnX6h0LFxFhE4kHI8CBCiURFXz4gWe0V0Og5376zl9xC/Pw4s5rfA3jW5h/k8IXitz0imcBSAShaOSDZL/GCSQ6j3OLQ== X-YMail-OSG: rkvh_JkVM1l_brxmSF2O2xOlw0I3MjO9yxaiMLa.U1ob99_UO5KQImG_X6I7i93 YBceAQzxqbSSkZ.0q.8V_wcGWbBFrH8nSQBpWrG5FENDefIdVIXtDX1K4wLhd_wbAQ146ovLBxGT yJDzXk63zsIyXJoeWECR1gi4ephFhvertThjHH1HhIW2530Nd6BWWesv1jeRamc63MnK0wcC97Rf hcgCCkSwOsh.0CckHhggJNggLr82beGrWegLX0Xi3EeREkxNayvtI3DQ722KVfMEWEUhe00gjfOk GTj6YIOnsm6akfzKz0Qnx1JpG5H6aSzc2qE4R_m802npuAmZY4qrLJ3uq4DP4zS60ou1mWF26Y2h 6fzwfAglvsVGUlji13h1w_W5uOBOvhZOErQr7eZ4JQpyJkSCVLMtheU4klTleD0OYCJPsD.YF4il Dy7guNHHDSB_eaY5JkI0Uyz.FeApOTYBQX5217_pqWdYE5HjqiAJa_x5cul67yS4abo0eaxyUax4 qdTF5sA3RlEE8xmxPpyc5qcL2arkCLKP6bne0hxBzFN.eVeZezR7ZNeg8AVxR_jdWl6VFbN6p2ZT FcJp9ZjQabkjNAr0UnZxwBa7iRimDA.6KuAbyScXsBwXfWHs2HMZz1UgIrnZMXZQzXT4C1WXh5MO BJwo_BSw52WaVdHxemz7q4hC6cQrZoJkdce2J49863N64DiG.w3ILZpGjWg27MCMBYAb37TrwFXL Oa1Xu.94KXqcKYC9vYyNVwQPoJu1JlvZA76Q0tPivBWCuPjQvWiV7nexVHC7hvpQA8NZh7Y3WVWY GZWUgDyTr6UIbKZ4LU5x1IjOh5.o.g1ZE_CXy4Hpvkf.isCkoUEB34fJ2Qs3_fVcrwZ6z2zIYrgt A3z8e1j5elh8Miyzp5ysOLIUw4Q8l9UfpWioKkjCdXVOOSa7loAxIBZ16plnn7uxsm1U6EuQTv3L y5SSl_Ng7F19q6ZOStwowIma3OBjfJ.M7bkl_KeOm.fyDYktw3_TnXgDW4RBJHDgPXz.6uxxLbMu 0zio6VkmCpx5HbYShCxulcpdlOVU38LlvM.TOo1VE0IG1u2enHDE7JbNR.PWCLM._JHcBZaCFEA. aMo72NO.XEfE_Ltn3eV9.d17JJKv0lPsjtryRuqNtTS6Ft3YcEQR5VblM1fElbX2IZkg_PnXd_Fv vVAX9SJ3xrGc7tskmv67_SzPE7Bbq_mulMhVUbS7zE7vgWXiiUCFg2yykuz803RW8.WAsbx_3C_Q .TYk3TgaoS3EGGOXNyirz8pYhnJAsiLx1AH6yHIHVQDxbbxlQ8o227VNSp6J6zalqwQOZjyKb3Ro 4oq8k6UgBfkOfK29WNF4GEe2iZyTRgr7KRVyvybTLYXam.G1DzUZ.2_6qRH.UWJhGkYisSjxZm3o O Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ir2.yahoo.com with HTTP; Tue, 26 May 2020 12:04:36 +0000 Received: by smtp429.mail.sg3.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b13eae11f47c99c3166391cbbeda5d48; Tue, 26 May 2020 12:04:31 +0000 (UTC) Subject: Re: [Bloat] CPU consumption using TC-TBF and TC-POLICE to limit rate To: bloat@lists.bufferbloat.net References: From: Y Message-ID: <13baee00-6400-069d-be95-2839611bee04@yahoo.fr> Date: Tue, 26 May 2020 21:04:29 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C830C9F755A05BD69D125138" Content-Language: en-US X-Mailer: WebService/1.1.15960 hermes_yahoo Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) X-List-Received-Date: Tue, 26 May 2020 12:04:37 -0000 This is a multi-part message in MIME format. --------------C830C9F755A05BD69D125138 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello I heard that IBF costs cpu load. How about shaping only egress with TBF? Yutaka. On 2020/05/26 18:47, Jose Blanquicet wrote: > 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 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --------------C830C9F755A05BD69D125138 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hello

I heard that IBF costs cpu load.

How about shaping only egress with TBF?

Yutaka.

On 2020/05/26 18:47, Jose Blanquicet wrote:
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
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
--------------C830C9F755A05BD69D125138--