From owner-freebsd-net Mon Oct 7 17: 0:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1372F37B406; Mon, 7 Oct 2002 17:00:11 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7066A43E75; Mon, 7 Oct 2002 17:00:10 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021008000009.VNMZ6431.sccrmhc01.attbi.com@InterJet.elischer.org>; Tue, 8 Oct 2002 00:00:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA36501; Mon, 7 Oct 2002 16:55:43 -0700 (PDT) Date: Mon, 7 Oct 2002 16:55:42 -0700 (PDT) From: Julian Elischer To: Luigi Rizzo Cc: Sam Leffler , freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch In-Reply-To: <20021007163101.A27463@carp.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Mon, 7 Oct 2002, Luigi Rizzo wrote: > 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. In my usage, the API id also includes other parts of the API, not just packet metadata. I use teh same cookie to define control command messags within netgraph. In fact the control messages currently FAR exceed the metadata types. At this moment there are about 37 APIS defined in netgraph and they implement about 150 different control messages there are only 2 metadata types in use. (priority and "dropability") To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message