From owner-freebsd-arch Mon Oct 7 16:31: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5023337B401; Mon, 7 Oct 2002 16:31:05 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE83B43E91; Mon, 7 Oct 2002 16:31:04 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g97NV1O2028018; Mon, 7 Oct 2002 16:31:01 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g97NV1Gn028017; Mon, 7 Oct 2002 16:31:01 -0700 (PDT) (envelope-from rizzo) Date: Mon, 7 Oct 2002 16:31:01 -0700 From: Luigi Rizzo To: Sam Leffler Cc: Julian Elischer , freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch Message-ID: <20021007163101.A27463@carp.icir.org> References: <185201c26e54$43339f40$52557f42@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <185201c26e54$43339f40$52557f42@errno.com>; from sam@errno.com on Mon, Oct 07, 2002 at 03:52:49PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG the 16 vs. 32 bit On Mon, Oct 07, 2002 at 03:52:49PM -0700, Sam Leffler wrote: ... > Sounds to me like the real issue for you is insuring unique m_tag_id values. > We're certainly less likely to have collisions with a 32-bit value than a > 16-bit value and expanding this way gives you your "field ID" too. I guess > the question I have is whether the existing API's that search only by > "cookie" are sufficient for your needs. If so then I'm ok with changing > things. Otherwise we have an API incompatibility with openbsd that I'd like > to avoid. i wonder what do we gain by moving to 32 bit m_tag_id -- because there is is still no strict guarantee that we have no conflicts if people randomly choose "cookies", and also, using the same reasoning for allocations one could argue that having the cookie chosen as the number of _days_ since the epoch, will still give low conflict probability while still fitting in 16 bits. Also, those modules that require one or a very small number of different annotations (e.g. all the ones currently using m_tags) would just need the "cookie", whereas others with a large set of subfields could as well consider the field_id as part of the opaque data. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2988 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message