From owner-freebsd-hackers@freebsd.org Thu Apr 28 21:21:07 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 9100FB201FE for ; Thu, 28 Apr 2016 21:21:07 +0000 (UTC) (envelope-from zclaudio@bsd.com.br) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 4864F19E1 for ; Thu, 28 Apr 2016 21:21:07 +0000 (UTC) (envelope-from zclaudio@bsd.com.br) Received: by mail-wm0-x232.google.com with SMTP id e201so4939919wme.0 for ; Thu, 28 Apr 2016 14:21:07 -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=fSCDUzKPw5QfabQlAciNdoUdloFC6Auqx2f4fT9u478=; b=M0zIgCogFTDa4hdVPBiVgBTDnVzTtWNU+OyAcKXQCVfCIf+fFlpz+oZ+i2+31g8VNG lx8FCACYLKnD7wFn+gV8dojctK5wfx/JYwWgH4+dVkBR8MQC5D0AcnsZVg2WC74PORdc 47WHERS3KN7MYAcDfu+ZTFhvtULRX+uzD5rCQ= 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=fSCDUzKPw5QfabQlAciNdoUdloFC6Auqx2f4fT9u478=; b=kZg6nnTA3aLlRxeA/HTuxcD3DSsqavHEKAgy6RPB9sMh0JcgDzFwY+qn+Gc3V4MckK a1OjkbiQEQHlCRYzkXyKXLl8H3/WlEzoWj9AAPlItzDRMHQQMrcyl+EUj3VqRlkzOs4/ Po2r7X79Ftx4auDZ3E85lHuV5PCEOZ/fC7UrZ+PNbzT69UoBU9ZPoPSfkayatS3j0rLU 7oOSsRFJ1/G2AO0gdSct5Yq+CRo5uSUdelbPyqUU0wjTi8zXMk6XuvBXZ497Q32HYOTA U5oG/xBH4GaPify7UvHYETYMkkv3bILMzJGOS+b6C1mkMg8EgetNYuGzUZHCY8RLVT70 Np4A== X-Gm-Message-State: AOPr4FXSdrZmsSFDxz14+IdmSbpE+q/pm8esImVRsfYH/1fxXQji+b2n+SuTds4O3YyIhNuAF6KXr0quw01jFg== MIME-Version: 1.0 X-Received: by 10.194.2.130 with SMTP id 2mr17710379wju.77.1461878465150; Thu, 28 Apr 2016 14:21:05 -0700 (PDT) Received: by 10.28.183.131 with HTTP; Thu, 28 Apr 2016 14:21:05 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Apr 2016 18:21:05 -0300 Message-ID: Subject: Re: Best option to process packet ACL From: Ze Claudio Pastore To: Alan Somers 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 21:21:07 -0000 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 hardwa= re. > > > On Apr 28, 2016, at 12:35 PM, Alan Somers wrote: > > > > Even if your application is not a traditional firewall, using pf or ipf= w > > 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 you= r > > 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. back on focus, I need to understand how to better split this load among IDLE CPUs