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?) > > > > > > When you say "finding a better way", do you mean move away from > attaching something to mblk_t's or coming up with a better method > for doing it that is extensible?
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 and then everyone using M_CTL for their private stuff causes overload and loss of readability. 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 around during fireEngine timeframe was creating something called mblk_ext_t which has mblk_t embedded. So code that only knows about mblks still works but more information (attributes) can be added at the end and transport through layers transparently. The issue being do we put a flag for each attribute in b_flag? If yes, it does help the paths which don't care about any attribute but if you are expecting something, you need to still check the flags. Plus do we allocate a mblk with space for each possible attribute type or do we do lazy allocate etc etc. I was trying to dig for the proposal which had couple of other alternatives as well but I can't find it. But hopefully you get the drift. Each approach has some pluses and minuses if you try to retrofit it in current code. What is needed is someone to sit down, think this through and drive it. Any Volunteers? Cheers, Sunay > > Darren > -- Sunay Tripathi Solaris Core Networking Technologies Sun MicroSystems Inc. email: [EMAIL PROTECTED] Phone: 650-786-6007 (W) ----- End of forwarded message from Sunay Tripathi ----- -- Sunay Tripathi Solaris Core Networking Technologies Sun MicroSystems Inc. email: [EMAIL PROTECTED] Phone: 650-786-6007 (W) _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org
