> The speed benefit comes from switching to a stack mbuf except in the > case of errors, right?
I have worried about this diff since the first time seeing it. if anyone ever makes a mistake in this code-path, and sends that mbuf out into the wild, it will be an "un-managed" mbuf. by managed, i mean that we do all sorts of special things to mbufs now to count them in various ways, and a large variety of mbuf manipulation macros and functions end up playing with allocators/deallocators which can massage them. this one, being on the stack, not so much. of course the idea is to have this code-path never send that mbuf further. except mistakes might happen later. perhaps there is another way to write this so that it is more obvious that it is being contained.
