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

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



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


 


Rackspace

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