From owner-freebsd-net@FreeBSD.ORG Tue Jan 27 23:27:25 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16985295 for ; Tue, 27 Jan 2015 23:27:25 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id CBACCC50 for ; Tue, 27 Jan 2015 23:27:24 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id D321F7300A; Wed, 28 Jan 2015 00:32:40 +0100 (CET) Date: Wed, 28 Jan 2015 00:32:40 +0100 From: Luigi Rizzo To: Antoine Beaupr? Subject: Re: is polling still a thing? Message-ID: <20150127233240.GA22364@onelab2.iet.unipi.it> References: <871tmgceup.fsf@marcos.anarc.at> <1422384769.867067950.y2iiuu53@frv34.fwdcdn.com> <87pp9zc1wk.fsf@marcos.anarc.at> <20150127223917.GA21883@onelab2.iet.unipi.it> <87h9vbbze1.fsf@marcos.anarc.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87h9vbbze1.fsf@marcos.anarc.at> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org, wishmaster X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 23:27:25 -0000 On Tue, Jan 27, 2015 at 06:02:46PM -0500, Antoine Beaupr? wrote: > On 2015-01-27 17:39:17, Luigi Rizzo wrote: > > On Tue, Jan 27, 2015 at 05:08:27PM -0500, Antoine Beaupr? wrote: > >> On 2015-01-27 13:57:20, wishmaster wrote: > >> > Have you consider to use netmap-based ipfw instead pf in DDoS mitigation? I think you should. And without any network ''haks'' like polling. > >> > >> My understanding of netmap was that it wasn't useful for packet > >> forwarding, because its design is for transmitting packets directly to > >> userland faster, whereas routers dataflow stay mostly in the router... > > > > i think the suggestion was to have let netmap-ipfw > > drop the traffic you don't want to deal with, and then > > inject the remaining ones into the kernel where > > the processing occurs -- possibly even using pf or > > a different firewall > > > > There are people using netmap-ipfw on external physical > > boxes exactly in this way -- as a "bump in the wire", > > but it is trivial to run it on the same machine. > > hmmm... i *was* using pf to drop a significant amount of the traffic, I > am not sure I understand how using netmap/ipfw would help here. > > my understanding of the problem, at this stage, is not so much pf > processing the packets as the kernel having trouble extracting the > packets from the NIC fast enough. The arrangement is as in the picture below (use a fixed size font). +------------------+ | netmap-ipfw | +-[HHH-------[HHH]-+ HHH H HHH H +-----[HHH]------[HHH]-----------------------+ | HHH H +-----------+ | | HHH H | host | | | HHH o=======| network | | | +--[HHH]--+ | stack | | | | netmap | +-----------+ | | | enabled | | | | NIC | | +--+---------+-------------------------------+ A netmap-aware NIC has no problem dealing with high PPS rates, deliver them through the fat pipe HHH to netmap-ipfw in userspace, which does the filtering and drops the junk. The remaining part is reinjected through another netmap port into the host stack, which is the actual bottleneck. Presumably at this point the amount of residual traffic is sustainable by the kernel. netmap-ipfw is simmetric so it supports traffic in the other direction too. another host netmap port. Presumably at thi cheers luigi