Re: mbuf_outbound_finalize bug?
Re: mbuf_outbound_finalize bug?
- Subject: Re: mbuf_outbound_finalize bug?
- From: Adi Masputra <email@hidden>
- Date: Fri, 22 Dec 2006 10:12:03 -0800
On Dec 22, 2006, at 9:58 AM, Bhavesh Davda wrote:
I compare the result of mbuf_pkthdr_len agains the network-byte-order
value of IP length on purpose, to know whether indeed the value of IP
length in the packet is *not* in host-byte-order, as I thought you
said mbuf_outbound_finalize() expects.
Since your module is an interface filter, the field(s) in the header(s)
will be in network byte-order. All you need to do is to byte-swap
the length at all times assuming it is an IPv4 packet.
Oh boy. This is going to get quite expensive to do on a per packet
basis. I thought I could simply get a pointer into the packet payload
to the IP length field in the IP header, and do a memory read/write,
rather than going through so many function calls and memcpy's, albeit
small (2 byte) ones.
Well, you are already requesting the stack to perform software checksum
calculation on the packet which includes the transport payload; in terms
of per-byte cost that is much more significant than traversing the mbuf
chain to safely obtain the 2-octets IP length in the header. :)
Is there any other way to do it more optimally? I understand your
concern about non-linear mbufs, and not assuming that the IP header is
in the pkthdr mbuf. But realistically, is that ever going to be the
case?
There's no guarantee that the headers will be in contiguous span
although for the majority of cases they would. Sorry, but as I said
the fix is already in order.
Adi
Thanks!
--
Bhavesh P. Davda
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