From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Sun, 03 Aug 2014 22:06:09 +0000 Subject: Re: The "tc filter .. police" command does not have parameter "limit" Message-Id: <53DEB251.5040805@gmail.com> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org Fengyu Gao wrote: > Hi, > > I have a question about the "tc filter ... police" command. This > command is similar to the token bucket filter. Under Linux, ingress > traffic can be redirected to an imq or ifb, then you can apply a tbf > there. > > However, tbf has an important parameter "limit", which is the size > of the buffer for waiting packets, and it is different from the > "burst" parameter. In the "tc filter ... police" command, there does > not seem to be a "limit" parameter, and there seems to be no document > or discussions about it. Digging into the Linux kernel might be a > bit difficult for me. So my question is what is the buffer size in > this case? Policers do not buffer and as a result can be a bit aggressive. IIRC the burst parameter is like a virtual buffer but policers never hold the packets - just pass or drop. Personally I would rather shape but then you have to consider latency added by buffering. To avoid this you may need to classify traffic to give latency sensitive priority. fq_codel could be worth investigating as a single qdisc alternative to a policer.