Re: mbuf_outbound_finalize bug?
Re: mbuf_outbound_finalize bug?
- Subject: Re: mbuf_outbound_finalize bug?
- From: "Bhavesh Davda" <email@hidden>
- Date: Fri, 29 Dec 2006 09:31:47 -0800
Hi Terry,
That's exactly what I ended up implementing. I haven't read RFC 1624,
but I will.
Related question: if ever csum_flags has both CSUM_IP and CSUM_TCP |
CSUM_UDP set, then what is csum_data going to point to?
Thanks!
- Bhavesh
On 12/28/06, Terry Lambert <email@hidden> wrote:
Are you changing the length of the packet, or only the contents?
If you are only changing the contents, then I suggest an mbuf-chain
aware incremental checksum update as an alternative to copying it to a
contiguous buffer, operating on it, converting it to mbufs, then doing
a full software checksum of the whole packet.
See RFC 1624.
-- Terry
On Dec 22, 2006, at 10:12 AM, Adi Masputra wrote:
> 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
>
> _______________________________________________
> 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
--
Bhavesh P. Davda
_______________________________________________
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