Re: replaceOrCopyPacket() question
Hi Michael, On Oct 27, 2003, at 6:28 AM, Michael Cashwell wrote: Greetings, I've read the docs and done a cursory examination of the source but thought I'd ask here in case someone "just knows" the answer. I'm working on packet reception in an Ethernet driver and have questions about replaceOrCopyPacket() and friends. I originally allocate a set of packets large enough to hold an entire received frames in one segment. This allows me to use mbufs almost directly with the card's DMA hardware. As I understand it, when I get back one of these buffers I need to determine its true logical length and then call replaceOrCopyPacket() to handle what goes up the stack and what is returned back to the DMA engine. OK, so far. But for efficiency I want to set the packet's m_pkthdr.len length [and possibly the internal m_len member as well, I'm unsure here] before calling that method. There's no way it can efficiently do its job if I haven't supplied the logical length first. Perhaps I'm suppose to leave the member fields alone and supply the logical length only via the argument to replaceOrCopyPacket() and it magically does what I need. That would be great, but the docs don't say and I haven't taken the source apart enough to figure it out. When you allocate a packet, the length fields in the mbuf are initialized to the capacity requested. When it is replaced, its m_pkthdr.len is examined so that the replacement mbuf will have the same capacity. The length passed to replaceOrCopyPacket() will be used to truncate the mbuf destined for the networking stack. In essence, you shouldn't need to update the mbuf length fields directly. In any case, I'm worried about the packet I get back for reuse with the DMA hardware not having the same attributes as what I originally allocated. They need to have the same capacity and be single-segment just like the original. No need to worry. If the length + alignment padding is less than MCLBYTES (2048 bytes), then it is guaranteed that it will come back as a single mbuf, likely attached to a mbuf cluster. This mbuf memory can be described with no more than 2 physical memory segments (typically 1 will suffice). -Joe _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.
participants (1)
-
Joe Liu