Date: Mon, 7 Oct 2002 16:23:00 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Sam Leffler <sam@errno.com> Cc: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch Message-ID: <Pine.BSF.4.21.0210071613260.34884-100000@InterJet.elischer.org> In-Reply-To: <185201c26e54$43339f40$52557f42@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 7 Oct 2002, Sam Leffler wrote: > > So all this is to say that you want m_tag_id to be u_int32_t. Having > another 16-bit field is immaterial to anything I've thought of but given > that switching to a 32-bit tag_id will require allocating an additional > 32-bit item you can have that for free since there's little point in having > a 32-bit length. The obvious downside is that m_tag structs now go from 8 > bytes to 12, but this is still a darn sight better than allocating a 256 > byte mbuf. sure... "an extra 4 bytes please sir" :-) > > If you allocate tag id's using your 32-bit time scheme then the fixed values > above would never be hit since they are all for impossible times and so > there'd be no conflict. Just make them all IDs in a single "Legacy" API > > > > > (this is a contrived example because priority is a "BASE API" metadata > > type in netgraph, and the base API doesn't have a magic number at the > > moment but probably should have one. (certainly would in this case) > > > > > > As I mentionned before, it is also not clear to me that the metadata > > needs to be in linked list form, but I could live with it. > > > > 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. You could "mis-use" the API identifier as you suggest, or you could just keep them in theID and have "Legacy" API identifier of 1034032666 (the output of date -u +'%s' for right now.. the suggested method of deriving an API ID.) I'd rather not pollute the namespace of other modules, but it's up to you. first check if it's an API you understand. if not skip to next if it is, go to some switch table to identify more exactly.. heck take API identifier #0 :-) I have actually had code with 2 version sof the same API. Being able to just assign a different API ID was good. I could support both sorts of input. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" 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.0210071613260.34884-100000>