Re: struct dlil_if_flt_str
Re: struct dlil_if_flt_str
- Subject: Re: struct dlil_if_flt_str
- From: Josh Graessley <email@hidden>
- Date: Tue, 15 Mar 2005 11:22:19 -0800
And to add to Justin's comments with my own little plea...
If you are looking to implement a new media type, please don't use
the frame_ptr. Leave the whole packet in the mbuf. This gives the
inbound and outbound filters whole packets. This also sidesteps the
problem of variable length headers. There is no reason to specify the
frame_ptr separately.
If you think of using a frame_ptr and setting it to point somewhere
other than space in the mbuf, please be aware of a few things. When
you pass the packets off to the stack, the packets are queued. This
means you can not allocate storage for the frame header on the stack.
There is no notification to let you know when the stack is done with
the frame header. In the current shipping stack, you could specify a
function pointer to handle notification of the cluster for the mbuf
being freed but that may not be available in the future.
-josh
On Mar 15, 2005, at 11:10 AM, Justin Walker wrote:
On Mar 15, 2005, at 10:52, Josh Graessley wrote:
*frame_ptr points to the frame header. The driver is responsible
for setting this pointer. For ethernet interfaces, this points to
the ethernet header. It is passed as a ** so the filter may change
where the value of the pointer. The header is usually set to point
at the start of the packet in the mbuf. The mbufs data pointer is
then moved to point to the data in the packet following the header.
On the output side, there is no frame_ptr because the the entire
packet including the frame header is in the mbuf.
Yes. The mbuf stores the meat of the packet. On the outbound path,
it stores the entire packet. On the inbound path, it store the
entire packet, but the data pointer has been incremented past the
packet header and the pointer to where the header starts is passed
separately as the frame_ptr. There are no guarantees that the
frame_ptr points to data in the mbuf, but that's how it's
implemented, and any other implementation would be problematic, so
that probably won't ever change.
I am adding the following note to the thread:
While Josh is correct in what he says, we designed this collection
of mechanisms to deal with disparate media layers. The ethernet
media (and those similar to it) make Josh's prediction likely, but
if another media type rears its ugly head, it is possible that
implementations may choose to provide frame headers and payloads in
different buffer areas.
Since you (Carl) are implementing code that deals with media info,
you will know the nature of the packets you are getting, but you
should, none-the-less, be wary of making too many assumptions
regarding "the right way" to implement, based on the way things
currently work.
Cheers,
Justin
--
Justin C. Walker, Curmudgeon-At-Large *
Institute for General Semantics | Some people have a mental
| horizon of radius zero, and
| call it their point of view.
| -- David Hilbert
*--------------------------------------
*-------------------------------*
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden