[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] ip/udp checksum offload from minios guest



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.

> How am I supposed to entirely offload the IPv4 checksum calculation
> for UDP?  Setting the flag unconditionally for non-TCP/UDP traffic
> (e.g. ARP/ICMP) results in lots of dropped frames, so I am only
> setting it in the outgoing UDP frames.

Which is the right thing to do.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.