Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 2 Jun 2006 11:51:40 +0200
From:      Max Laier <max@love2party.net>
To:        Luigi Rizzo <rizzo@icir.org>
Cc:        freebsd-ipfw@freebsd.org
Subject:   Re: bin/98349 [Re: cvs commit: src/sbin/ipfw ipfw2.c]
Message-ID:  <200606021151.46167.max@love2party.net>
In-Reply-To: <20060602022916.B74593@xorpc.icir.org>
References:  <200606020517.k525HHLU037819@repoman.freebsd.org> <200606020725.54959.max@love2party.net> <20060602022916.B74593@xorpc.icir.org>

next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart60503660.9YHLaINcKg
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 ord=
er
>
> 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 rath=
er
> 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.=20

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

=2D-=20
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News

--nextPart60503660.9YHLaINcKg
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (FreeBSD)

iD8DBQBEgAoyXyyEoT62BG0RAlHxAJ915t2qBCpDSFpaf7IBu1ir7SavCACfWlJ+
VcE2QqdJ94kVwyrOpHbD6WU=
=ffZC
-----END PGP SIGNATURE-----

--nextPart60503660.9YHLaINcKg--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200606021151.46167.max>