Date: Mon, 15 Dec 2014 10:26:01 -0200 From: Patrick Tracanelli <eksffa@freebsdbrasil.com.br> To: Brett Glass <brett@lariat.net> Cc: John Nielsen <lists@jnielsen.net>, Luigi Rizzo <rizzo@iet.unipi.it>, "freebsd-net@freebsd.org" <net@freebsd.org> Subject: Re: Can DUMMYNET handle weighting of traffic according to firewall rules? Message-ID: <59E7D981-B28B-4995-B8F4-6A2687CEF265@freebsdbrasil.com.br> In-Reply-To: <201412141635.JAA27068@mail.lariat.net> References: <CA%2BhQ2%2BgNZmMbo0-2fgS49mCNV7nTFDkBpHAzUDg8JoiUfsY5tg@mail.gmail.com> <028d142b3a17cd5ffd5f21c6f9b9d6daaa8e2780@webmail.freebsdbrasil.com.br> <201412141635.JAA27068@mail.lariat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 14/12/2014, at 14:25, Brett Glass <brett@lariat.net> wrote: >=20 > At 11:02 AM 12/13/2014, eksffa@freebsdbrasil.com.br wrote: > =20 >> As I understand the problem, there are many ways to do this without = actually using any special feature on dummynet. =46rom 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. >=20 > 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. Yes, it would. But should only be a big deal if you have too much pps = and low CPU to deal with the volume. > This would affect not only latency but also jitter, because DUMMYNET = pipes are driven by timer interrupts. I don=E2=80=99t quite agree, if you have enough CPU to pipe it together. = I run a number of setups where a WF2Qp or QFQ setup does the weighting = and later an extra pipe imposes other individual limits. Proper queue and HZ tuning tend to do the job while you have enough CPU = to deal with 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. This is just theory. And I don=E2=80=99t mean it=E2=80=99s wrong. There = could certainly be a better way to add an extra cost factor to a flow, = but the pure fact is you don=E2=80=99t have it today. Let=E2=80=99s be = practical, how much bw are we talking about and how much CPU?=20 Even if we are talking about a lot of bandwidth, you have many tuning = possibilities and you have netmap-aware dummynet to deal with high pps = rate. > X could only be a whole number unless you fed the pipe multiple times = in EACH direction. As I understand your problem you would need to feed a flow in the = opposite direction to the same pipe anyway. So it=E2=80=99s just a matter of 3 flows instead of 2. I insist, not the = beautiful approach, but not a big deal, unless we are talking about = 10G/40G connections or a server with 10yo computing power. > And turning off the "one_pass" feature would add to the overhead of = EVERY pipe used in the system. That=E2=80=99s not true. Having one_pass disable is a mostly a needed = feature if you have complex environments with a mix of filtering and = queueing, otherwise a single match in a pipe will result in a pass = behavior. If you don=E2=80=99t match a traffic twice to a pipe one_pass = will make not difference to dummynet at all, adding no overhead. = Remember that one_pass is an ipfw feature, not dummynet specific, and if = overhead will be added anywhere, it=E2=80=99s on ipfw that will just = keep the packet injected and keep processing until a filtering match is = found, which can be the next rule.=20 > 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. Sure it would be more desirable not just for your needs, but for = dummynet feature set as a whole. But that=E2=80=99s just not something = you have today. > 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. That would be great for sure. But as Luigi mentioned this is not that simple for the UI which seems = many times to be more complex to extend than the kernel features itself, = without breaking other stuff or requiring .h handling somehow that would = make a -STABLE merge not simple. But anyway, after adding a cost factor and handling UI extending, how = would you solve the need to inject both RX and TX traffic to the same = pipe? You will need to match it twice against the same pipe anyway. No 3 = times but twice at least, no matter with or without one_pass. >=20 > --Brett Glass -- Patrick Tracanelli
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?59E7D981-B28B-4995-B8F4-6A2687CEF265>