On 9/09/09 08:46 AM, Kacheong Poon wrote:
Darren Reed wrote:
Given the [], I'm not sure if this is an editorial mistake or not,
but something that has been brought up a few times is expanding the
mblk_t (or dblk_t?) to store a packet length and other useful
information. Whilst the mblk_t is currently a nice multiple of system
word size (and in some cases cache line size as well),
micro-optimisation shouldn't be a design goal. With the above comment
and the IP Refactoring project almost behind you now, what are your
thoughts on allowing for this type of change?
My guess is that this special field does not help much since
ULPs, such as TCP and SCTP, can use multiple mblks per send.
Similarly, since TCP/SCTP can segment (or break up) what the
app layer sends down, knowing the size of an app layer send
call may not help avoid the use of msgdsize().
"can" but don't always.
I think it would be a worthwhile experiment to modify the
mblk_t, add in a size field, "fix" all of the places where this
would help and see what, if any, performance change there
is. That's the only way to really find out. Although I wonder
if there are more "hidden" benefits from a change like this
than there are obvious ones.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
