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, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News
pgpHLispSyvGR.pgp
Description: PGP signature
