There shouldn't be instances of code that does static sizeof (mblk_t),
or uses mblk_t's as structure members, etc.
But a bigger question, to my mind, is the impact of changing the size
with respect to cache alignment, etc. On a busy system there could be
millions of these things getting allocated/used/destroyed *each second*.
Even just the extra cycle it takes to bzero another 32-bits of storage
in allocb() might have a bad impact on overall system performance.
I definitely do _not_ think the idea of an enclosing structure (or
another indirect pointer) is a good idea.
Sometimes I even wonder if the current level of indirection (mblk_t
versus dblk_t) is worth the extra cost. (How many times do mblk_t's get
dupmsg()'d properly? ... and the risks of code incorrectly failing to
check db_ref and modifying dblk_t's while in-flight, etc.)
-- Garrett
On Thu, 2007-08-30 at 19:49 -0700, [EMAIL PROTECTED] wrote:
> One of the more interesting problems we have with OpenSolaris'
> networking is that the structure and contents of the mblk seem
> to be fixed (for all time.)
>
> This is somewhat at odds with evolving networking in OpenSolaris
> as there's an invariant here that is limiting us. At least two
> projects have contested for the right to use part of the few
> remaining bits in the flag field and without doubt there will
> be more.
>
> Why do people want to use flag bits? Because it's the only way
> to store a single bit of "private" data on the mblk and have it
> be carried forward...
>
> Which brings is to the problem.
>
> For people that want to build on top of OpenSolaris, there is
> no way to attach private "meta-data" to a packet as it enters
> the system on one interface and be able to retrieve it as it
> exists the system on another. We need the means to do this.
>
> There are some options here, but not a lot of them:
>
> 1) We actually extend the mblk to have another field that is
> a pointer to a chain of meta data and we further define how
> that meta data is treated as various things happen to the
> packet as it moves through the system.
>
> 2) We invent a new data structure to pass around that contains
> a pointer to the mblk_t rather than the mblk_t itself and we
> define it in such a way as to allow it to carry private data.
> There isn't a chain of these data structures, just one -
> a packet head structure if you like.
>
> 3) ??? maybe define a new mblk type ???
>
> Whatever it is we do, it is going to have large repercussions
> throughout the source code for the Solaris' IP stack.
>
> This is a serious problem for OpenSolaris and we need to
> discuss how we're going to solve it.
>
> Part of this may mean deciding that code which does
> "sizeof(mblk_t)" is just broken and does not deserve
> to work forever and ever.
>
> For reference, see:
> http://bugs.opensolaris.org/view_bug.do?bug_id=6327695
>
> Darren
>
> _______________________________________________
> networking-discuss mailing list
> [email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
