From owner-freebsd-net Mon Oct 7 17:20:21 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 5800B37B401; Mon, 7 Oct 2002 17:20:19 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D7A143E3B; Mon, 7 Oct 2002 17:20:18 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021008002017.TFCJ27763.sccrmhc02.attbi.com@InterJet.elischer.org>; Tue, 8 Oct 2002 00:20:17 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA36615; Mon, 7 Oct 2002 17:14:29 -0700 (PDT) Date: Mon, 7 Oct 2002 17:14:29 -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: 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, Julian Elischer wrote: > > > 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") I lie.. there is a bandwidteh manager written in netgraph that uses metadata to hold the queueing and packet category info. so there are maybe 2 more types defined in their own API. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message