bin/98349 [Re: cvs commit: src/sbin/ipfw ipfw2.c]

[Max Laier]

On Friday 02 June 2006 11:29, Luigi Rizzo wrote:
> On Fri, Jun 02, 2006 at 07:25:47AM +0200, Max Laier wrote:
> > On Friday 02 June 2006 07:17, Max Laier wrote:
> > > mlaier      2006-06-02 05:17:17 UTC
> > >
> > >   FreeBSD src repository
> > >
> > >   Modified files:
> > >     sbin/ipfw            ipfw2.c
> > >   Log:
> > >   Print dynamic rules for IPv6 as well.
> > >
> > >   PR:             bin/98349
> > >   Submitted by:   Mark Andrews
> > >   MFC after:      2 weeks
> > >
> > >   Revision  Changes    Path
> > >   1.90      +15 -5     src/sbin/ipfw/ipfw2.c
> >
> > It's highly confusing that we have {src,dst}_{ip,port} in host byte order
>
> if i remember well, the design motivation behind this choice was that we
> do range comparisons on ports and integer manipulation on the ipv4
> addresses (to apply masks and generate various indexes), so the most
> efficient choice for the internal representation was host order. I'd rather
> keep it this way, as we use these ops very very often, and not only
> performance but even readability of the code would be impaired changing to
> network order. 

IMHO it would improve performance much rather (eventhough the gain would be 
quite little - if measurable at all - given todays CPU speeds).  As we are 
talking about ipfw_flow_id here we have to match packets to a flow in order 
to keep state.  That means that for every packet we have to flip byte order 
for src, dest, src_port and dest_port just to match it to a state.  If we 
were to store those in network byte order we would save 4 flips per packet 
for stateful matching.  Of course it might complicate the normal (first time) 
matching a little, but it will most certainly not slow it down - if done 
correctly.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ipfw/attachments/20060602/395713d2/attachment.pgp