Re: replaceOrCopyPacket() question
Re: replaceOrCopyPacket() question
- Subject: Re: replaceOrCopyPacket() question
- From: Joe Liu <email@hidden>
- Date: Mon, 27 Oct 2003 08:36:33 -0800
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 | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.