site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Aug 15, 2005, at 2:17 PM, Allan Hoeltje wrote: This is correct, ctl_enqueuembuf consumes the mbuf If so then it seems that ctl_enqueuembuf is no more efficient than ctl_enqueuedata. I don't believe one is much more efficient than the other. Vincent _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... I want to send IP packets from my kext to a client app. Up to now I've been making a copy of the mbuf data with mbuf_copydata and then sending the data to the client with ctl_enqueuedata. Today I looked at the source for ctl_enqueuedata and saw that it takes my flat data and copies it into a newly allocated mbuf which is then passed to sbappend and sbcompress. So, it seemed to me that I could be more efficient if I just used ctl_enqueuembuf to send the original mbuf to the client. However, when I do that I get the Grey Screen of Death. I noticed that ctl_enqueuedata allocates a new mbuf but does not free it. Should I assume that sbappend causes the mbuf to be freed? If so, then calling ctl_enqueuembuf would also cause the original mbuf to be freed, right? It would certainly explain the GSofD. The source for sbcompress seems to indicate that it does free the mbuf space but I am not sure if I am reading m_free correctly. Do I need to do an mbuf_dup on my original mbuf and ctl_enqueuembuf the duplicate? Yes you need to duplicate the mbuf if you plan to use it after calling ctl_enqueuembuf. This email sent to site_archiver@lists.apple.com