Thanks, this is all clear now. I was not setting NETTXF_data_validated along
with NETTXF_csum_blank in my transmit path, which was confusing the backend.
Ian: yes the IPv4 checksum is of course only over the header. I wrote the code
right, and then re-read it wrong while hacking on a flight :) The ICMP errors
confused me (since I was setting NETTXF_csum_blank for those too and the
checksum functions error out).
On 29 Mar 2011, at 15:19, Paul Durrant wrote:
> Maybe there's some confusion of terms here... There are 2 checksums: the IPv4
> header and UDP checksum.
>
> The IPv4 header checksum must *always* be calculated by the frontend.
>
> If NETTXF_csum_blank is set (implying NETTXF_data_validated must also be set)
> then the UDP checksum must be set to cover the UDP pseudo-header since the
> SKB will be marked CSUM_PARTIAL and thus any h/w driver it is presented to
> will expect the pseudo-header checksum to be valid. If the SKB is presented
> to another guest then CSUM_PARTIAL will translated into
> NETRXF_csum_blank|NETRXF_data_validated and the frontend is at liberty to
> present it up the stack as being checksum-valid without anything in the
> datapath having had to walk over the payload to actually calculate the value
> of that checksum.
>
> Paul
>
>> -----Original Message-----
>> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-
>> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Anil Madhavapeddy
>> Sent: 29 March 2011 18:16
>> To: Ian Campbell
>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: Re: [Xen-devel] ip/udp checksum offload from minios guest
>>
>> On 29 Mar 2011, at 12:37, Ian Campbell wrote:
>>
>>> On Tue, 2011-03-29 at 17:17 +0100, Anil Madhavapeddy wrote:
>>>> I'm just adding checksum offload support into a custom guest, and
>> wanted to clarify a few things.
>>>>
>>>> In netfront, I can mark outgoing frames with:
>>>> - NETTXF_csum_blank
>>>> - NETTXF_data_validated
>>>>
>>>> These refer to UDP or TCP checksums, and not the IP checksum,
>> right?
>>>> Linux seems to never offload IP header checksumming, so it must
>> be
>>>> offloading the UDP/TCP calculation and then adjusting the IPv4
>>>> checksum based on that calculation.
>>>>
>>>> For outgoing UDP, my guest is setting the checksum to 0 (as it's
>>>> optional in the protocol), and calculating the full IPv4 checksum
>> in
>>>> software, and all works (slowly). However, setting
>> NETTXF_csum_blank
>>>> in the outgoing frame and leaving the IPv4 checksum at 0 doesn't
>> seem
>>>> to result in any adjustment by netback, and the packet gets
>> dropped.
>>>
>>> I think you need to set the checksum to the psuedo-header checksum
>>> rather than 0 since that is what csum_blank means (such a well
>> named
>>> flag!)...
>>>
>>> It's not clear why anything would drop a UDP frame with
>> checksum==0
>>> since, as you say, it is optional. My guess is that since the
>>> NETTXF_csum_blank and data_validated turn into an skb->ip_summed
>> ==
>>> SKB_PARTIAL on the backend side this causes the Linux network
>> stack to
>>> drop it because that statement conflicts with the checksum being
>> 0.
>>
>> Right, but I'm setting the IPv4 checksum to 0 too, since I want to
>> offload the whole lot and never calculate a body checksum in the
>> guest. But if the UDP checksum is set to 0, then the backend can't
>> just adjust it to obtain the IPv4 checksum and has to iterate over
>> the packet body at some stage.
>>
>> I've tried setting the UDP checksum to 0, the pseudoheader, and the
>> full checksum, and the IPv4 checksum is never set by the backend in
>> any of these cases. If I set the IPv4 checksum in software to the
>> correct value, then packets go through, but the UDP checksums are
>> never altered.
>>
>> Guess it's time to start slapping printfs all over the dom0 kernel
>> to see what's going on unless you know what I "should" be setting
>> both the IPv4/UDP checksums to with NETTXF_csum_blank...
>>
>> Anil
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home