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 [EMAIL PROTECTED]
> with "unsubscribe freebsd-arch" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
