From owner-freebsd-net Sun Apr 28 11:40:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 5E63937B41B for ; Sun, 28 Apr 2002 11:40:23 -0700 (PDT) Received: from pool0493.cvx21-bradley.dialup.earthlink.net ([209.179.193.238] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 171taw-0004XU-00 for net@freebsd.org; Sun, 28 Apr 2002 11:40:22 -0700 Message-ID: <3CCC41FA.D2BA610E@mindspring.com> Date: Sun, 28 Apr 2002 11:39:54 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: net@freebsd.org Subject: ip_flow and ipf_tos Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org It seems to me that it would be useful to break out the ip_tos field in the ipflow_lookup() function, just like in the ipflow_hash() function, and make it an unsigned long (the packing of the structure makes it a 32 bit value (or 64 bit, on Alpha) anyway. This also means calling the mtod() (which is a macro) before the call to ipflow_create() and adding a u_long parameter there (or u_int32_t, if you prefer). The net upshot of this is that it would be possible to use any unsigned (32 bit, in most cases) value to do the flow identification, so that, other than ipflow_fastforward() itself, the ip_tos is not necessarily used for the flow identification. This is useful for local hash preterbation: the common case for any application other than a generic router is going to have identical ip_tos values on almost all traffic, which makes it not very useful for uniquifying the hash. Rather than dictate what I personally think would be useful, I'd like to have implementation-not-policy; also, the break out of the value would make the code more generally useful. Right now, ip_tos (and ipf_tos) is an 8 bit value, of which only the first 6 bits are used in the hash, while the hash value pass itself is a 32 bit value (in most cases: it's "unsigned"). I'd like to push the value into the same space as the src.s_addr feedback, which would have the net effect of making 2 more bits of the standard implementation useful. What do people think about this? The changes themselves are really trivial, and it only puts an extra push/pop into the common code path in order to get the functionality, and doesn't bloat the data structure size at all... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message