ipfw table matching algorithm question

[Alexander V. Chernikov]

On 15.06.2014 16:36, Ian Smith wrote:
> On Sun, 15 Jun 2014 16:04:45 +0400, Alexander V. Chernikov wrote:
>   > On 15.06.2014 16:01, Ian Smith wrote:
>   > > On Sun, 15 Jun 2014 18:08:59 +0800, Julian Elischer wrote:
>   > >   > On 6/15/14, 3:00 AM, Alexander V. Chernikov wrote:
>   > >   > > On 14.06.2014 21:35, Michael Sierchio wrote:
>   > >   > > > Luigi -
>   > >   > > >
>   > >   > > > Does table entry matching use a longest prefix match?
>   > >   > > I'm not Luigi, but the answer is "yes" anyway :)
>   > >   >
>   > >   > this may be about to change, because tables are getting  a rewrite,
>   > >   > but IP-based tables use the same code that the routing tables use.
>   > >
>   > > It'd be a bit anti-POLA for the longest prefix match behaviour to
>   > > change, though, especially with some tablearg usage.  Alexander?
>   > Well, "cidr" table are LPM by their nature.
>   > Additional algorithms for matching may be introduced (dxr, hashed tables for
>   > host-only prefixes)
>   > but it won't influence user-visible behavior for given type.
>
> Thanks for the confirmation .. nothing too scary so far, then .. but in
> what manner do you see integrating DXR into firewall table usage?
DXR (or any other similar algorithm) returns next hop index in case of 
match.
The only thing that is needed - is to add another indirection table w 
idx -> u32 values (or even IPv6 nexthop values).

You can take a look at current radix bindings here:
http://svnweb.freebsd.org/base/projects/ipfw/sys/netpfil/ipfw/ip_fw_table_algo.c?revision=267469&view=markup
>
> cheers, Ian
>