Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Aug 2014 05:48:03 -0700
From:      Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com>
To:        Marko Zec <zec@fer.hr>
Cc:        "Alexander V. Chernikov" <melifaro@yandex-team.ru>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Luigi Rizzo <rizzo@iet.unipi.it>, freebsd-ipfw <freebsd-ipfw@freebsd.org>
Subject:   Re: [CFT] new tables for ipfw
Message-ID:  <CAOgwaMvg=q8n8ntiTAMjgQMdin0g=aJ4ud7Ss3P0ofF8gWFZRg@mail.gmail.com>
In-Reply-To: <20140814140818.3539d9c5@x23>
References:  <53EBC687.9050503@yandex-team.ru> <CA%2BhQ2%2Bg=A_rLHCVpBqn0AtFLu_gNGtzbmXvc-7JhpLqPSWw44A@mail.gmail.com> <53EC880B.3020903@yandex-team.ru> <CA%2BhQ2%2BiPPhy47eN0=KaSYBaNMdObY20yko7dRY1MMuP_mfnmOQ@mail.gmail.com> <53EC960A.1030603@yandex-team.ru> <CA%2BhQ2%2BgxVYmXb%2BHOw4qUm6tykmEvBRkrV0RhZsnC6B08FLKvdA@mail.gmail.com> <53ECA302.8010100@yandex-team.ru> <20140814140818.3539d9c5@x23>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 14, 2014 at 5:08 AM, Marko Zec <zec@fer.hr> wrote:

> On Thu, 14 Aug 2014 15:52:34 +0400
> "Alexander V. Chernikov" <melifaro@yandex-team.ru> wrote:
>
> > On 14.08.2014 15:15, Luigi Rizzo wrote:
> > >
> > >
> > >
> > > On Thu, Aug 14, 2014 at 12:57 PM, Alexander V. Chernikov
> > > <melifaro@yandex-team.ru <mailto:melifaro@yandex-team.ru>> wrote:
> > >
> > >     On 14.08.2014 14:44, Luigi Rizzo wrote:
> > >>
> > >>
> > >>
> > >>     On Thu, Aug 14, 2014 at 11:57 AM, Alexander V. Chernikov
> > >>     <melifaro@yandex-team.ru <mailto:melifaro@yandex-team.ru>>
> > >> wrote:
> > >>
> > >>         On 14.08.2014 13:23, Luigi Rizzo wrote:
> > >>>
> > >>>
> > >>>
> > >>>         On Wed, Aug 13, 2014 at 10:11 PM, Alexander V. Chernikov
> > >>>         <melifaro@yandex-team.ru <mailto:melifaro@yandex-team.ru>>
> > >>>         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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOgwaMvg=q8n8ntiTAMjgQMdin0g=aJ4ud7Ss3P0ofF8gWFZRg>