From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 14 12:46:12 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 982711F1; Thu, 14 Aug 2014 12:46:12 +0000 (UTC) Received: from forward-corp1g.mail.yandex.net (forward-corp1g.mail.yandex.net [IPv6:2a02:6b8:0:1402::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3CD4A2194; Thu, 14 Aug 2014 12:46:11 +0000 (UTC) Received: from smtpcorp4.mail.yandex.net (smtpcorp4.mail.yandex.net [95.108.252.2]) by forward-corp1g.mail.yandex.net (Yandex) with ESMTP id F0FC7366005A; Thu, 14 Aug 2014 16:46:07 +0400 (MSK) Received: from smtpcorp4.mail.yandex.net (localhost [127.0.0.1]) by smtpcorp4.mail.yandex.net (Yandex) with ESMTP id AF7062C05E8; Thu, 14 Aug 2014 16:46:07 +0400 (MSK) Received: from unknown (unknown [2a02:6b8:0:401:222:4dff:fe50:cd2f]) by smtpcorp4.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id iAsmop7sNc-k7IK310a; Thu, 14 Aug 2014 16:46:07 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 91582161-a429-4f64-ac2f-2c09a2800245 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1408020367; bh=gDd+ENkKuIiuie79a1gdzWuvzE7SKND9vNrKHd6ds7g=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Fu+fAS5TS9gkMrIFBGWgDDm0aZrIRDZWvTF5nnQH6fG8+3Ok/vpvwpIt00+wRAjhi KExt79k9Z64clx4h1hCi/W+yUbF8MmUqOIXzv1yuR2kkNPq1P5B+iM5Tl5SphHEtL0 Rw325ARHwOuhDyEGiDNO5BgD37o6+Otfi1m9FRuA= Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Message-ID: <53ECAF8C.2020007@yandex-team.ru> Date: Thu, 14 Aug 2014 16:46:04 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Marko Zec Subject: Re: [CFT] new tables for ipfw References: <53EBC687.9050503@yandex-team.ru> <53EC880B.3020903@yandex-team.ru> <53EC960A.1030603@yandex-team.ru> <53ECA302.8010100@yandex-team.ru> <20140814140818.3539d9c5@x23> In-Reply-To: <20140814140818.3539d9c5@x23> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , freebsd-ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 12:46:12 -0000 On 14.08.2014 16:08, Marko Zec wrote: > On Thu, 14 Aug 2014 15:52:34 +0400 > "Alexander V. Chernikov" wrote: > >> On 14.08.2014 15:15, Luigi Rizzo wrote: >>> >>> >>> On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov >>> > wrote: >>> >>> On 14.08.2014 14:44, Luigi Rizzo wrote: >>>> >>>> >>>> On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov >>>> > >>>> wrote: >>>> >>>> On 14.08.2014 13:23, Luigi Rizzo wrote: >>>>> >>>>> >>>>> On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov >>>>> > >>>>> wrote: >>>>> >>>>> Hello list. >>>>> >>>>> I've been hacking ipfw for a while and It seems there >>>>> is something ready to test/review in projects/ipfw branch. >>>>> >>>>> >>>>> ​this is a fantastic piece of work, thanks for doing it >>>>> and for integrating the feedback. >>>>> ​ >>>>> I have some detailed feedback that will send you >>>>> privately, but just a curiosity: >>>>> >>>>> ​...​ >>>>> >>>>> Some examples (see ipfw(8) manual page for the >>>>> description): >>>>> >>>>> ​... >>>>> >>>>> >>>>> ipfw table mi_test create type cidr algo "cidr:hash >>>>> masks=/30,/64" >>>>> >>>>> >>>>> ​why do we need to specify mask lengths in the above​ ? >>>> Well, since we're hashing IP we have to know mask to cut >>>> host bits in advance. >>>> (And the real reason is that I'm too lazy to implement >>>> hierarchical matching (check /32, then /31, then /30) like >>>> how, for example, >>>> >>>> >>>> ​oh well for that we should use cidr:radix >>>> >>>> Research results have never shown a strong superiority of >>>> hierarchical hash tables over good radix implementations, >>>> and in those cases one usually adopts partial prefix >>>> expansion so you only have, say, masks that are a >>>> multiple of 2..8 bits so you only need a small number of >>>> hash lookups. >>> Definitely, especially for IPv6. So I was actually thinking >>> about covering some special sparse cases (e.g. someone having a >>> bunch of /32 and a bunch of /30 and that's all). >>> >>> Btw, since we're talking about "good radix implementation": what >>> license does DXR have? :) >>> Is it OK to merge it as another cidr implementation? >>> >>> "cidr" is a very ugly name, i'd rather use "addr" >> Ok, no problem with that. "addr" really sounds better. >>> DXR has a ​bsd license and of course it is possible to use it. >>> You should ask Marko Zec for his latest version of the code >>> (and probably make sure we have one copy of the code in the source >>> tree). >> Great!. I'll ask him :) > The so far cleanest DXR implementation is significantly C++ poluted and > wrapped inside Click glue (available here: http://www.nxab.fer.hr/dxr) > > I'll try to backport the fixes to the original C-only / BSD > implementation over the weekend and let you know how it goes... Great! I've got 2012 version half-ported (and radix fix has been merged to the tree), but something definitely has changed since then :) I'd be happy to hear from you :) > > Marko > > >>> Speaking of features, one thing that would be nice is the ability >>> for tables to reference the in-kernel tables (e.g. fibs, socket >>> lists, interface lists...), perhaps in readonly mode. >>> How complex do you think that would be ? >> Implementing algo support for particular provider like >> sockets/iflists shouldn't be hard. Most of the algorithms complexity >> lies in table modifications. Here we have to support >> lookup and dump operations, so it is the question of providing >> necessary bindings to existing mechanisms (via some direct binding or >> utilizing things like kernel_sysctl for dump support). >> >> It looks like the following maps well to current table concept: >> * such tables are not created by default >> * user issues >> `ipfw table kfib create type addr algo "addr:kernel fib=0"` >> or >> `ipfw table ktcp create type flow algo "flow:kernel_tcp fib=0"` >> or >> `ipfw table kiface create type iface algo "iface:kernel"` >> * tables have special "readonly" type, flush_all requests are ignored >> * no state stored internally >> >> So generic table handling code needs to be modified to support >> read-only tables (and making more callbacks optional). >> Additionally, we might need to proxy "info" request info algo >> callback (optional, "real" algorithms won't implement it) to be able >> to show number of items (and some other info) to user. >> >> >> >>> cheers >>> luigi >>> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"