From owner-freebsd-hackers@freebsd.org Thu Apr 28 17:46:50 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32D60B1FED4 for ; Thu, 28 Apr 2016 17:46:50 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A5131F71 for ; Thu, 28 Apr 2016 17:46:49 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-oi0-x22c.google.com with SMTP id x201so91872754oif.3 for ; Thu, 28 Apr 2016 10:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FwsFXDWdAZt/axwBTNnReuEteJVSK+p4uq71JnmFnrs=; b=at4YvZspzVpWB0/Q10SW7fR0EJLzu+ctsG4rFah9nXPiz98A5e/54IMg6APPEDE9wq RPjw/LnYg6OtiabgGq6wCIcHwY6OE2PenjYfLbcx+77m8/6exrHnbI5OLARavdSbhz0i i94DXuk7PcvU4wBmkgFv++Zcq9+EnZMcEeqXk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FwsFXDWdAZt/axwBTNnReuEteJVSK+p4uq71JnmFnrs=; b=XJBuQstVpJwp1eqzz221fXhNVT+z7DaGaQrAcfHc9/DnlthleFM7LQycy49RG7QFyr lkQEwvG24JrB2bRzzATZec0b72sIIpg77lnHwBl19KLXnMjBLDmhKu5ozTO94W3/NaS+ EE70QwNNmBWZV0RQYxM/hcEOhs0DI61Mk6JIuD3LVUT6udUXS4S9ccyNsDE7/cSf4B7X 2TOzbglJGXPmlkrOMhDwmMCZwMu6waN2UPr3qUjEliBPQTUb4j/tTcg6cKDsFFHuKXYF NeoHJwSyXKUqTUHXhpvoBLs2NAbZGUrzxYCoCwqT20+EX1qO6JJ8bQzwOcJES7IH8wPj Wj4A== X-Gm-Message-State: AOPr4FUHXxqIOmxr04qAxMGLgwV2XEc1zgb9I94hK04wIXkEf9l5bpKVodoaVzZgX0NJxnpV X-Received: by 10.157.46.196 with SMTP id w62mr7898089ota.7.1461865609186; Thu, 28 Apr 2016 10:46:49 -0700 (PDT) Received: from jims-mbp.netgate.com ([208.123.73.28]) by smtp.gmail.com with ESMTPSA id p203sm3166325oif.16.2016.04.28.10.46.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Apr 2016 10:46:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Best option to process packet ACL From: Jim Thompson In-Reply-To: Date: Thu, 28 Apr 2016 12:46:46 -0500 Cc: Ze Claudio Pastore , "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alan Somers X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 17:46:50 -0000 If your application is already using DPDK then: 1) it=E2=80=99s not =E2=80=9Cmostly bypassing the kernel=E2=80=9D, it = *is* bypassing the kernel. 2) ACLs are already a thing in DPDK: = http://dpdk.org/doc/guides/prog_guide/packet_classif_access_ctrl.html 200Kpps is not a lot of load for even =E2=80=98pf=E2=80=99 on slow = hardware. > On Apr 28, 2016, at 12:35 PM, Alan Somers wrote: >=20 > Even if your application is not a traditional firewall, using pf or = ipfw > would save much development time compared to writing your own packet > filter. They can be configured to do things like redirect packets to > different ports. You can use that to offload packet filtering from = your > application to the firewall, and open multiple sockets in your = application > to receive prefiltered packets. >=20 > Of course, pf/ipfw can't be used in combination with DPDK, as you > discovered. Doesn't DPDK provide access to each queue of a multiqueue > NIC? If so, you can create multiple filtering threads, and associate = each > thread to a single queue of your NIC. >=20 > Good luck, you've got a lot of work ahead of you. >=20 > On Thu, Apr 28, 2016 at 11:20 AM, Ze Claudio Pastore = > wrote: >=20 >> Because actually, this is ot a packet firewall. >>=20 >> When I mentioned pf/ipfw is only to reffer to ideas on how to best = match >> each acl criteria. >>=20 >> But my userland application is a proxy, ACL will handle L7 requests = within >> the packets. I will filter based on the mentioned criteria but it = will be >> processed at a different moment unrelated to packet in kernel. It's = also >> DPDK enabled so it's mostly skipping the whole kernel. >>=20 >>=20 >>=20 >> 2016-04-28 11:50 GMT-03:00 Alan Somers : >>=20 >>> On Wed, Apr 27, 2016 at 1:21 PM, Z=C3=A9 Claudio Pastore = >>> wrote: >>>=20 >>>> Hello everyone, >>>>=20 >>>> I would like to hear your suggestion regarding the best approach to >>>> process >>>> IP packets for filtering, in such a way I can avoid lowering my pps = rate. >>>>=20 >>>> Today a have a simple application proxies http application. It's = dual >>>> threaded on a 4 core system with low CPU power. The current = application >>>> uses two threads, one for control and one for data flow processing. >>>>=20 >>>> I need to implement a simple set of stateless filtering, I will = process >>>> only: >>>>=20 >>>> - src-ip >>>> - dst-ip >>>> - src-port >>>> - dst-port >>>> - iplen >>>> - proto (tcp/udp/other) >>>>=20 >>>> My current rate of requests per second is high, around 200K. I have = no >>>> idea >>>> how I can leverage the IDLE CPUs the best way to implement this ACL >>>> filtering trying not to impact on the pps rate I have today. >>>>=20 >>>> I have implemented it serial today (not threaded) and I get 40% >>>> performance >>>> loss. I will handle max 128 filter rules, this is a decision which = is >>>> made. >>>> This is going to be first match wins. >>>>=20 >>>> My current plans are to test: >>>>=20 >>>> 1) Create 6 threads, one to test each aspect of the ACL (src-ip, = dst-ip, >>>> etc) the first thread that returns false to parent thread I stop >>>> processing >>>> that rule and go to the next, and tell all other threads to = die/exit >>>> since >>>> they don't matter anymore. >>>>=20 >>>> 2) Create one thread to process a batch of rules, say, 8 rules per = thread >>>> per request. Don't know if I would limit total number of threads = and lock >>>> requests while threads ar e busy. >>>>=20 >>>> 3) Someone suggested "do as pf/ipfw do" but I have no idea how it's = done, >>>> how multithreaded it is and what is done on each thread. >>>>=20 >>>> 4) Other suggestion? >>>>=20 >>>> This is going to run FreeBSD 11, I use libevent2 on the current >>>> application >>>> so far. >>>>=20 >>>> Thanks. >>>> _______________________________________________ >>>>=20 >>>>=20 >>> Is there some reason why you can't simply use pf or ipfw? ipfw can = do >>> everything you described. pf can do most of it, but I'm not sure if = pf can >>> filter on iplen. If I were you, I wouldn't attempt to write my own >>> userland firewall until I was absolutely sure that neither pf nor = ipfw >>> would work. If that's the case, then I would try using diverter = sockets. >>> With a diverter socket, pf or ipfw does most of the work, but when = it >>> encounters a packet it can't process it pushes it up to a userland = helper. >>> The userland helper processes the packet and then tells pf or ipfw = what to >>> do with it. In realistic applications, pf or ipfw also creates a = temporary >>> rule based on the userland helper's decision. Applying the = temporary rule >>> in the future is far faster than invoking the userland helper. = After a >>> certain amount of time, the temporary rule will expire again. >>>=20 >>>=20 >>> Here's an example in action: >>> http://daemonforums.org/showthread.php?t=3D8846 >>>=20 >>> -Alan >>>=20 >>=20 >>=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org"