Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 7 Oct 2002 17:14:29 -0700 (PDT)
From:      Julian Elischer <julian@elischer.org>
To:        Luigi Rizzo <rizzo@icir.org>
Cc:        Sam Leffler <sam@errno.com>, freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG
Subject:   Re: CFR: m_tag patch
Message-ID:  <Pine.BSF.4.21.0210071712491.36581-100000@InterJet.elischer.org>
In-Reply-To: <Pine.BSF.4.21.0210071633100.34884-100000@InterJet.elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help


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-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0210071712491.36581-100000>