From owner-freebsd-hackers@freebsd.org Thu May 5 06:27:33 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 86FC2B2E85C for ; Thu, 5 May 2016 06:27:33 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FAE2110B; Thu, 5 May 2016 06:27:32 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-225-151.lns20.per1.internode.on.net [121.45.225.151]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u456RQr1098933 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 4 May 2016 23:27:30 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: Best option to process packet ACL To: Ze Claudio Pastore , Alan Somers References: Cc: "freebsd-hackers@freebsd.org" From: Julian Elischer Message-ID: Date: Thu, 5 May 2016 14:27:21 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: Thu, 05 May 2016 06:27:33 -0000 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’s not “mostly bypassing the kernel”, 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 ‘pf’ on slow hardware. >> >>> On Apr 28, 2016, at 12:35 PM, Alan Somers wrote: >>> >>> 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. > ok, again, it's not a L3/L4 ACL, I am looking into L3/L4 information but 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 better > process it, I have previous information from L7 affinity, headers, request > 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 firewall > 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. > > back on focus, I need to understand how to better split this load among > IDLE CPUs > _______________________________________________ > 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" > >