From owner-freebsd-net@FreeBSD.ORG Thu Aug 14 12:48:04 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C9F03E6; Thu, 14 Aug 2014 12:48:04 +0000 (UTC) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EFCFE21BF; Thu, 14 Aug 2014 12:48:03 +0000 (UTC) Received: by mail-yk0-f173.google.com with SMTP id 131so898577ykp.32 for ; Thu, 14 Aug 2014 05:48:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ePQ9LG1QGGFI/AblEX+zFI8vzPgtWO4QCmJkHqbG+JE=; b=0waehPueWCO1MsNUqXE+mWKSMi/SZwett4cvJi7bnnz2BR59w5MMtvWE7bD3wvT3vp eM5sg0FEkX0d02FvJujb/qmO85wrCbGImCrqy/g/AQz79xvVN74oNSprPjL4IVXG2bXY R2340mUnpBU2+HAD+m6fYXgAVXffiJW4J72OO/Mw2/z8YT/h4720fhinT8bfeb7BfBnk 3ZVqHsWZmrl/y3mef5SMi5NqPOd6DhCvu9iWN97sms3Z/UfkAiX3RUlFMMhI/G0dUaND WCHlJoz4PElNkzKBN6JVt9isNSzzkHsi9eMne13jdFzOoKxmE7nrVgj5Ljw/0ITtDrZp JTlg== MIME-Version: 1.0 X-Received: by 10.236.104.133 with SMTP id i5mr17370383yhg.137.1408020483112; Thu, 14 Aug 2014 05:48:03 -0700 (PDT) Received: by 10.170.218.197 with HTTP; Thu, 14 Aug 2014 05:48:03 -0700 (PDT) In-Reply-To: <20140814140818.3539d9c5@x23> References: <53EBC687.9050503@yandex-team.ru> <53EC880B.3020903@yandex-team.ru> <53EC960A.1030603@yandex-team.ru> <53ECA302.8010100@yandex-team.ru> <20140814140818.3539d9c5@x23> Date: Thu, 14 Aug 2014 05:48:03 -0700 Message-ID: Subject: Re: [CFT] new tables for ipfw From: Mehmet Erol Sanliturk To: Marko Zec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "Alexander V. Chernikov" , "freebsd-net@freebsd.org" , Luigi Rizzo , freebsd-ipfw 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: Thu, 14 Aug 2014 12:48:04 -0000 On Thu, Aug 14, 2014 at 5:08 AM, 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. > > >>> > > >>> > > >>> =E2=80=8Bthis is a fantastic piece of work, thanks for doin= g it > > >>> and for integrating the feedback. > > >>> =E2=80=8B > > >>> I have some detailed feedback that will send you > > >>> privately, but just a curiosity: > > >>> > > >>> =E2=80=8B...=E2=80=8B > > >>> > > >>> Some examples (see ipfw(8) manual page for the > > >>> description): > > >>> > > >>> =E2=80=8B... > > >>> > > >>> > > >>> ipfw table mi_test create type cidr algo "cidr:hash > > >>> masks=3D/30,/64" > > >>> > > >>> > > >>> =E2=80=8Bwhy do we need to specify mask lengths in the abov= e=E2=80=8B ? > > >> 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, > > >> > > >> > > >> =E2=80=8Boh 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 =E2=80=8Bbsd 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... > > 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=3D0"` > > or > > `ipfw table ktcp create type flow algo "flow:kernel_tcp fib=3D0"` > > 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" > _______________________________________________ > 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" The link is http://www.nxlab.fer.hr/dxr/ Thank you very much . Mehmet Erol Sanliturk