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