[Catching up on email]
Sunay Tripathi wrote:
The first step is to understand why M_CTL is bad. Mostly to do with
overload, performance and code cleanliness/readability. Code paths
which don't care about the content of the M_CTL have to deal with it
causing performance and cleanliness impact an
On 18 Mar 2006, at 01:41, Alexander Kolbasov wrote:
It was like that before a new STREAMS message allocator was introduced
in 1996
(as bug 1241255). The old code had to deal with issues introduced by
dupb/pullupmsg/freeb. Here is a comment from the bug report:
Interesting. I was not aware of
> "Paul" == Paul Durrant <[EMAIL PROTECTED]> writes:
Paul> Actually, I often wondered whether the current mblk_t/dblk_t layout
Paul> hurts the OS anyway. I often wondered whether, in code scanning large
Paul> numbers of relatively small (sub-page) STREAMS messages it made sense
Paul> t
>
> Why not flesh out M_MULTIDATA further? It has a nice programming API, and
> already has support for attributes.
>
M_MULTIDATA messages are not what I'd call *real* STREAMs messages
anyway since you cannot use all the standard message manipulation
functions on them. If the network stack goes d
On 3/16/06, Sunay Tripathi <[EMAIL PROTECTED]> wrote:
> Plus do we allocate
> a mblk with space for each possible attribute type or do we do lazy
> allocate etc etc.
>
Actually, I often wondered whether the current mblk_t/dblk_t layout
hurts the OS anyway. I often wondered whether, in code scannin
> So sort this out, any mechanism that requires prepending stuff is
> probably not the best. Also adding the constraints that mblks are in
> use by loads of things and is exposed externally for decades, you need
> to maintain backward compatibility as well. One such idea that we have
> kicked
We started discussing this but this might be of wider interest ..
> Dan McDonald wrote:
>
> > ...
> >
> > - de-STREAMS-ing IPsec (aka. BigAjax) --> Part of this would be
> > examining M_CTLs and finding a better way. (I wonder if PEF will
> > end up doing part of this anyway?)
