From owner-freebsd-arch Mon Oct 7 17:50:31 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 9DFA137B401; Mon, 7 Oct 2002 17:50:29 -0700 (PDT) Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3442B43E6A; Mon, 7 Oct 2002 17:50:29 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0113.cvx22-bradley.dialup.earthlink.net ([209.179.198.113] helo=mindspring.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17yiZs-000018-00; Mon, 07 Oct 2002 17:50:24 -0700 Message-ID: <3DA22B42.FBB6ECBF@mindspring.com> Date: Mon, 07 Oct 2002 17:48:02 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: Sam Leffler , Julian Elischer , freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch References: <185201c26e54$43339f40$52557f42@errno.com> <20021007163101.A27463@carp.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Luigi Rizzo wrote: > 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. Julian wants to use "32 bit seconds since epoch" as the "random" value, and then rely on statistical protection. This wasn't clear to me, either. It depends on knowing netgraph developement well enough, and following the recommended approach well enough that you use the seconds-since-epoch method of obtaining interface IDs. > 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. That's why I suggested a void *, and that it would not be good enough for 64 bit machines. If everyone followed the seconds-since-epoch assignment methodology, though, Julian's approach would provide statistical protection (I worry about "the birthday paradox" making the likelihood much higher; for example, I'd expect the space to be smaller almost instantly, due to time zones...). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message