From owner-freebsd-hackers@freebsd.org Thu Apr 28 17:35:12 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 4CEF9B1FCAF for ; Thu, 28 Apr 2016 17:35:12 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 101EE1AD7 for ; Thu, 28 Apr 2016 17:35:12 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi0-x229.google.com with SMTP id v145so58265542oie.0 for ; Thu, 28 Apr 2016 10:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=1yhJfbyN1NTccCmq12hWNbNu3oqrMqry6eCEGx9KNvE=; b=GK6hAhlRj8TLuAaoMCjYLsLcSlx8MTr+EuLfrmuxSe6PmWzLaeColzDnO39/HnU6hj tj440SmyOeFNPmLPQFpqX+If4CTWLbqo33ENgWZ0w75vsYai+oYS42oP3zlJMm6eF9aQ U3ZDB38So9k5ck0TypuKBIK44187pJHHlf2nTdqKzrmHROzbMF9lBXcl1gXktlBE4X8X pD6YuVGZCdVFzlhe2K1+Y/6MBmG533hAwiXC/xOgdzGn4GgfLANN4mJU+QFJNBVgVnqW q7GBhJKxNTXkxfQ/HxZk9O1lsavjG+D0v4UyyxDbM1eTJm46tv3ybRbS4hUEZp//pgtM 0ASQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1yhJfbyN1NTccCmq12hWNbNu3oqrMqry6eCEGx9KNvE=; b=kS+Ton0IreOHTdhUhCyLK42jsZz8vbXO4VXYku76tkCkS211qUn2HtzHKk5waRpRsj tcSp4IIHm0YgMOrXIp0a9qIx+VpkQ9hLz10wPV5bHUuGT0ZPuQLam+ZDrqq+YInKcU9G w7ZdWkbG8eEXg239Qn5fG6xEJEUyN2UyINntjW5Z9fcGkUyDOwL+R8+TgF8iK1i8TghK kvrZjSG8ETefmMH01x9lPcmlvq7pWqXOgklf+oeDn8Hi7T4pYS/pKMdxJiRezYAry1Lh Ed5b3wydYOKCuRkhIsryO6+pMqepNWKFRwEHmmbYOTz0ghKGhdgQ2M0tojC8M9ggnEr5 4o9Q== X-Gm-Message-State: AOPr4FWU99ys5fhVf0pbftDVq8/Czm5dR1VL4r2DpgnKYzGw9z//yqb8bvEAc1kjht/DD5f+PkaUQmUes6qVPw== MIME-Version: 1.0 X-Received: by 10.157.12.210 with SMTP id o18mr7518883otd.192.1461864911192; Thu, 28 Apr 2016 10:35:11 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.202.64.138 with HTTP; Thu, 28 Apr 2016 10:35:11 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Apr 2016 11:35:11 -0600 X-Google-Sender-Auth: IhdkwZykjZEZoE0TQ7J6s1V4O_o Message-ID: Subject: Re: Best option to process packet ACL From: Alan Somers To: Ze Claudio Pastore Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 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:35:12 -0000 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. 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. Good luck, you've got a lot of work ahead of you. On Thu, Apr 28, 2016 at 11:20 AM, Ze Claudio Pastore wrote: > Because actually, this is ot a packet firewall. > > When I mentioned pf/ipfw is only to reffer to ideas on how to best match > each acl criteria. > > But my userland application is a proxy, ACL will handle L7 requests withi= n > 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. > > > > 2016-04-28 11:50 GMT-03:00 Alan Somers : > >> On Wed, Apr 27, 2016 at 1:21 PM, Z=C3=A9 Claudio Pastore >> wrote: >> >>> Hello everyone, >>> >>> 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 rat= e. >>> >>> 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. >>> >>> I need to implement a simple set of stateless filtering, I will process >>> only: >>> >>> - src-ip >>> - dst-ip >>> - src-port >>> - dst-port >>> - iplen >>> - proto (tcp/udp/other) >>> >>> 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. >>> >>> 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. >>> >>> My current plans are to test: >>> >>> 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. >>> >>> 2) Create one thread to process a batch of rules, say, 8 rules per thre= ad >>> per request. Don't know if I would limit total number of threads and lo= ck >>> requests while threads ar e busy. >>> >>> 3) Someone suggested "do as pf/ipfw do" but I have no idea how it's don= e, >>> how multithreaded it is and what is done on each thread. >>> >>> 4) Other suggestion? >>> >>> This is going to run FreeBSD 11, I use libevent2 on the current >>> application >>> so far. >>> >>> Thanks. >>> _______________________________________________ >>> >>> >> 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 helpe= r. >> 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 tempor= ary >> rule based on the userland helper's decision. Applying the temporary ru= le >> in the future is far faster than invoking the userland helper. After a >> certain amount of time, the temporary rule will expire again. >> >> >> Here's an example in action: >> http://daemonforums.org/showthread.php?t=3D8846 >> >> -Alan >> > >