site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Jun 28, 2005, at 14:24 , Carl Smith wrote: Justin- Got it, guess I was just confused on the 'ifp' struct. Thanks for enlarging on that idea. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for General Semantics -------- Men are from Earth. Women are from Earth. Deal with it. -------- _______________________________________________ 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... Using the term 'create from scratch' was with idea that when I capture the original mbuf I play around with it, i.e. the data, then send it out after I copy back 'my' data. In the mean time, other mbufs, might/will be coming in to a pool, of mbufs, I have. Of course I keep the flow all linear, but I was just concerned with 'hanging' on to the 'ifp' as other mbufs backed up. But then I am not 'hanging' onto the original, my pool of mbufs, are 'copies' of the originals. It's been a while since I looked deeply at the output path, but there are a few things to consider here. Perhaps Josh can comment. I believe that, unless the destination is the loopback adapter ("lo0"), rcvif on outbound packets is NULL; it is mostly used on the input path. If it is used in a serious way on the outbound path, you should be really careful about doing what you are doing. If there is an "ifp" associated to the mbuf, and it is somehow pointing to the outbound interface, a change in routing information that occurs between the time you snag the original and the time that you inject the munged mbuf might affect the proper value for that ifp. I don't think this is the case, but you should try to verify it (i.e., try to follow the ip_output code, as well as that for the transport protocols :-}). This is just a note of caution; as I said, I don't think it's an issue. Josh? This email sent to site_archiver@lists.apple.com
participants (1)
-
Justin C. Walker