From owner-freebsd-net Tue Apr 30 8: 7:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from web.cs.ndsu.nodak.edu (web.cs.ndsu.NoDak.edu [134.129.125.7]) by hub.freebsd.org (Postfix) with ESMTP id C4B5437B41A for ; Tue, 30 Apr 2002 08:07:56 -0700 (PDT) Received: (from tinguely@localhost) by web.cs.ndsu.nodak.edu (8.11.4/8.11.4) id g3UF7tN32713; Tue, 30 Apr 2002 10:07:55 -0500 (CDT) (envelope-from tinguely) Date: Tue, 30 Apr 2002 10:07:55 -0500 (CDT) From: mark tinguely Message-Id: <200204301507.g3UF7tN32713@web.cs.ndsu.nodak.edu> To: net@FreeBSD.ORG, tlambert2@mindspring.com Subject: Re: ip_flow and ipf_tos In-Reply-To: <3CCC41FA.D2BA610E@mindspring.com> 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 > 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. I have no complaints to your proposal. The question I had was: what would happen when the high bits implement Early Congestion Notification (RFC3168)? Wouldn't we want to mask off these bits from the hash anyway? --mark tinguely. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message