Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 14 Dec 2014 09:25:00 -0700
From:      Brett Glass <brett@lariat.net>
To:        eksffa@freebsdbrasil.com.br, "Luigi Rizzo" <rizzo@iet.unipi.it>
Cc:        John Nielsen <lists@jnielsen.net>, "freebsd-net@freebsd.org" <net@freebsd.org>
Subject:   Re: Can DUMMYNET handle weighting of traffic according to firewall rules?
Message-ID:  <201412141635.JAA27068@mail.lariat.net>
In-Reply-To: <028d142b3a17cd5ffd5f21c6f9b9d6daaa8e2780@webmail.freebsdbr asil.com.br>
References:  <CA%2BhQ2%2BgNZmMbo0-2fgS49mCNV7nTFDkBpHAzUDg8JoiUfsY5tg@mail.gmail.com> <028d142b3a17cd5ffd5f21c6f9b9d6daaa8e2780@webmail.freebsdbrasil.com.br>

next in thread | previous in thread | raw e-mail | index | archive | help
At 11:02 AM 12/13/2014, eksffa@freebsdbrasil.com.br wrote:

>As I understand the problem, there are many ways to do this 
>without actually using any special feature on dummynet. From 
>tagging a traffic twice and feeding both tagged flows to the same 
>pipe, to the easiest and possibily lighter approach of disabling 
>one pass and feeding the traffic twice to the same pipe.

Unfortunately, feeding the traffic to the same pipe more than once 
would have some undesirable side effects. It would mean incurring X 
times the delay and computational overhead introduced by the pipe. 
This would affect not only latency but also jitter, because 
DUMMYNET pipes are driven by timer interrupts. Even if you set the 
kernel's HZ setting to a high number, you could have milliseconds 
of difference in the latency depending upon a packet's precise 
arrival time and the amount of traffic. If DUMMYNET was in "fast" 
mode, there would also be a very big jump in latency when the pipe 
neared capacity. X could only be a whole number unless you fed the 
pipe multiple times in EACH direction. And turning off the 
"one_pass" feature would add to the overhead of EVERY pipe used in the system.

It would be much more desirable to be able to specify a cost factor 
for a packet entering the pipe, as Luigi mentioned, so that the 
pipe could simply adjust its "score" to reflect the higher overhead 
of upstream vs. downstream traffic. If it's really a one-line patch 
to the kernel, I'd like to try doing this and then submit a patch 
to add the feature if it works.

--Brett Glass



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201412141635.JAA27068>