From owner-freebsd-hackers@freebsd.org Fri May 6 23:49:23 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 14AC0B31140 for ; Fri, 6 May 2016 23:49:23 +0000 (UTC) (envelope-from zclaudio@bsd.com.br) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 DA581109F for ; Fri, 6 May 2016 23:49:22 +0000 (UTC) (envelope-from zclaudio@bsd.com.br) Received: by mail-ig0-x233.google.com with SMTP id m9so53418097ige.1 for ; Fri, 06 May 2016 16:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=FySnS+iQ0aOQZvk/6yuvQywQ3Os/BKIVQ5wXZff23Dw=; b=aBiLW2ofs+RdOjUjhNduwxuWvUuGgI6WHE3Q5ws00THdwm5VQedNq+wqAEigBfcDbO GIao27sIxE2y5sVnnb3Ds4PvyRmrgGW9ftlyqV/TbikIoQw0MGfrrQQT+jUAiH4Lg7k6 ZHE8klorqItq6JxAR08VsqTdtBY6ofPT7VFI8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=FySnS+iQ0aOQZvk/6yuvQywQ3Os/BKIVQ5wXZff23Dw=; b=Lx3NuyQU71EheBy73nScdaQUUNc8ZsH2lUBb1TZd3ssmNP+3btQbPvTJd9qAU9y3ZP WrQw5VSIZKq1M3f/OiRQeWdZZ32/5eqEsXUVazEe7Z/8jgwIIKOooOdvNpkL44hDTKXh kKuNUw9oEBYflSxzmQyRwXHVU2axUz4gNUTpDRnQ2LjFTbNhtgD/uQlTdDSxN9hGZTxe OWp80gVcwJsu5zVAdoktYnaJyPQdV4kEIt41SUzKtWTG4uJbQ56zMGaBT/9SMNW46XQO 80tPt/ZXT4ICQJK6UF+bpyc4XAmNJRFGcVsupXlodS3VJIsF2WLhAH7QnhfBJbuVjpsy RJ9w== X-Gm-Message-State: AOPr4FWtzbSz0cSQ2vPw5ipewFK7+El729AhfKUAoCL6AkeLb1/d7KuwMidOyjOPvRnOlHTAzgWafcDaEisryA== MIME-Version: 1.0 X-Received: by 10.50.143.1 with SMTP id sa1mr280218igb.20.1462578561812; Fri, 06 May 2016 16:49:21 -0700 (PDT) Received: by 10.107.29.16 with HTTP; Fri, 6 May 2016 16:49:21 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 May 2016 20:49:21 -0300 Message-ID: Subject: Re: Best option to process packet ACL From: Ze Claudio Pastore To: Julian Elischer Cc: Alan Somers , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 23:49:23 -0000 2016-05-05 3:27 GMT-03:00 Julian Elischer : > On 29/04/2016 5:21 AM, Ze Claudio Pastore wrote: > >> 2016-04-28 14:46 GMT-03:00 Jim Thompson : >> >> 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 hard= ware. >>> >>> On Apr 28, 2016, at 12:35 PM, Alan Somers wrote: >>>> >>>> Even if your application is not a traditional firewall, using pf or ip= fw >>>> 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 yo= ur >>>> 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. >>>> >>> ok, again, it's not a L3/L4 ACL, I am looking into L3/L4 information bu= t >> on >> a request basis not per packet, depending on other previous criteria I >> will >> them split the processing, I am running a proxy so I am not looking to >> replace my ACL needs by something else, only want to discuss how to bett= er >> process it, I have previous information from L7 affinity, headers, reque= st >> which helps me split some load, now I happen to need to filter it, it's >> not >> a firewall, it's much like a squid based ACL need where you look for L3 >> info on a different moment, ipfw/pf won't do it for me, ordinary firewal= l >> fits somethwere else in the topology not in this application. >> > ok so you have a bunch of options. > If DPDK works for you, have you looked at netmap? > > If you are only interested in examining the first packet and then passing > everything to a proxy, then use ipfw fwd, with a stateful rule. > use a table with that rule if you have a number of filtering criteria. > use multiple table and multiple fwd destinations. > since we don't know what criteria, for how many rules it's hard to say.. > > > you could feed everything into a netgraph module attached to your > interface and write special purpose code. hello mr elischer I was generally looking to discuss the best generic approach to test the acl match criterias taking best benefit on more CPUs as I mentioned I am looking for tipical L3 information but on a L7 payload, per request before I apply other application based criterias like headers, x-forwarded-for, etc, I know it looks like I need a firewall but it's in a different moment, a different application, that's why I'm interested on a discussion on how to best match ACL criterias and how to share the load among cpus denis suggested some stuff I am trying and measuring the performance benefits vs workload added, i'm still working on some numbers i'll share later i already have a typical networking firewall with ipfw in front of the environment, in a different box, but know i really need to match acls based on application needs not simple/plain network needs anymore, pretty much like a squid L3 based acl, but squid does not bring multithreaded suggestions for acl, I found several discussions on how people use external acl hooks to benefit performance so no good code examples there too i think if we keep the conversation in the usual firewall subject, my question would be what if I wanted ipfw to be multithreaded, how to do this? is the current approach the best one? does ipfw/pf/iptables works like mr denis mentioned it looks like, based on interrupt on multithreaded network drivers? say, like, if I run a monothreaded network NIC like rl(4) or vr(4) no matter if I have 1 or 36 CPUs, kernel based firewall will only benefit from 1, that's correct? what if I wanted to make it multithreaded, would I thread batches of rules? thread per packet? thread per match criteria? thread somehow else? not to thread? thread by other criteria? that is the discussion i tried to promote :)