From owner-freebsd-net@FreeBSD.ORG Mon Dec 15 12:26:23 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E11CB02 for ; Mon, 15 Dec 2014 12:26:23 +0000 (UTC) Received: from leviatan.freebsdbrasil.com.br (leviatan.freebsdbrasil.com.br [177.10.156.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D8FAB60F for ; Mon, 15 Dec 2014 12:26:22 +0000 (UTC) Received: (qmail 6647 invoked from network); 15 Dec 2014 10:26:01 -0200 Received: from darwin.bh.freebsdbrasil.com.br (eksffa@freebsdbrasil.com.br@[10.69.69.7]) (envelope-sender ) by capeta.freebsdbrasil.com.br (qmail-ldap-1.03) with SMTP for ; 15 Dec 2014 10:26:01 -0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: Can DUMMYNET handle weighting of traffic according to firewall rules? From: Patrick Tracanelli In-Reply-To: <201412141635.JAA27068@mail.lariat.net> Date: Mon, 15 Dec 2014 10:26:01 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <59E7D981-B28B-4995-B8F4-6A2687CEF265@freebsdbrasil.com.br> References: <028d142b3a17cd5ffd5f21c6f9b9d6daaa8e2780@webmail.freebsdbrasil.com.br> <201412141635.JAA27068@mail.lariat.net> To: Brett Glass X-Mailer: Apple Mail (2.1993) Cc: John Nielsen , Luigi Rizzo , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 12:26:23 -0000 > On 14/12/2014, at 14:25, Brett Glass 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