From: Adam Niescierowicz <adam.niescierowicz@justnet.pl>
To: lartc@vger.kernel.org
Subject: Re: behaviour of tc for bridged ports
Date: Wed, 12 Jul 2023 10:44:50 +0000 [thread overview]
Message-ID: <75f8bfbc-6ba3-b204-294a-90ada60c5e1d@justnet.pl> (raw)
In-Reply-To: <CABTgHBvsF-N0H1rMd7M2d5nekaLitGGLyrL_mSYak1qHesY57Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2541 bytes --]
It can be stupid answer but try limiting traffic on br0.
Also try using htb with tc filter.
W dniu 9.07.2023 o 14:24, Nayan Gadre pisze:
> Hi Experts,
>
> I have a wireless router having the client facing interface wlan0 and
> the wired gateway facing interface eth0 under a bridge br0.
>
> / # brctl show
> bridge name bridge id STP enabled interfaces
> br0 8000.bce67c4d8fb0 no eth0
> wlan0
>
> client get IP 192.168.0.105, and server (connected via eth0) has IP
> 192.168.0.10.
> On server I run "iperf3 -s -p 5678 -V"
> On client I run "iperf3 -c 192.168.0.10 -p5678 -i1 -tinf"
> All works fine.
>
> Now I want to rate limit the traffic going from wlan0 to eth0 to 5000kbits/sec.
>
> I tried to apply a classless qdisc to eth0 port as well as wlan0 port.
> # tc qdisc add dev eth0 root tbf rate 5000kbit latency 50ms burst 15k
> # tc qdisc add dev wlan0 root tbf rate 5000kbit latency 50ms burst 15k
>
> However, the qdisc does not take effect.
>
> iperf3 -c 192.168.0.10 -p5678 -i1 -tinf
> Connecting to host 192.168.0.10, port 5678
> [ 5] local 192.168.0.105 port 43384 connected to 192.168.0.10 port 5678
> [ ID] Interval Transfer Bitrate Retr Cwnd
> [ 5] 0.00-1.00 sec 10.7 MBytes 89.6 Mbits/sec 0 526 KBytes
> [ 5] 1.00-2.00 sec 8.95 MBytes 75.1 Mbits/sec 0 560 KBytes
> [ 5] 2.00-3.00 sec 9.13 MBytes 76.6 Mbits/sec 0 619 KBytes
>
> / # tc -s qdisc
> qdisc tbf 8005: dev eth0 root refcnt 5 rate 5Mbit burst 15Kb lat 50ms
> Sent 221305 bytes 469 pkt (dropped 157, overlimits 288 requeues 0)
> backlog 0b 0p requeues 0
> qdisc tbf 8006: dev wlan16 root refcnt 5 rate 5Mbit burst 15Kb lat 50ms
> Sent 7095 bytes 109 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
>
> My kernel is 4.4.60, and I checked that qdisc gets activated in the
> egress path after dev_queue_xmit() is called. And for a bridged port,
> the path taken by the packet coming to wlan0 is
> __br_deliver -> br_forward_finish -> br_dev_queue_push_xmit -> dev_queue_xmit.
>
> So the qdisc should have taken effect even in the bridged case. I see
> statistics for eth0 qdisc.
> What am I missing in the tc rule ?
>
> If I apply the same rule on the server and client interfaces then I
> can see rate limiting taking effect. But on the wireless router linux
> bridge it's not working.
>
> Thanks
> N Gadre
--
---
Pozdrawiam
Adam Nieścierowicz
[-- Attachment #2: adam_niescierowicz.vcf --]
[-- Type: text/vcard, Size: 195 bytes --]
begin:vcard
fn;quoted-printable:Adam Nie=C5=9Bcierowicz
n;quoted-printable:Nie=C5=9Bcierowicz;Adam
email;internet:adam.niescierowicz@justnet.pl
x-mozilla-html:TRUE
version:2.1
end:vcard
prev parent reply other threads:[~2023-07-12 10:44 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-09 12:36 behaviour of tc for bridged ports Nayan Gadre
2023-07-12 10:44 ` Adam Niescierowicz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=75f8bfbc-6ba3-b204-294a-90ada60c5e1d@justnet.pl \
--to=adam.niescierowicz@justnet.pl \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).