[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] ip/udp checksum offload from minios guest
On Wed, 2011-03-30 at 11:23 +0100, James Harper wrote: > > > > On Tue, 2011-03-29 at 23:26 +0100, Anil Madhavapeddy wrote: > > > 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. > > > > Right, that would have ended up confusing things, I think. c_s && !d_v > > still ends up a CHECKSUM_PARTIAL in relatively recent backends. I'm not > > sure that has always been implemented correctly though. > > > > In recent netback there is fixup for the case where a GSO packet sets > > csum_blank but not data_validated which recalculates the partial > > checksum (since Linux requires that all GSO SKBs are CHECKSUM_PARTIAL to > > simplify the software GSO checksum stuff). That's only in the GSO case > > though since we can't detect it otherwise. > > > > > 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 :) > > > > Easily done! > > > > > The ICMP errors confused me (since I was setting NETTXF_csum_blank for > > > those too and the checksum functions error out). > > > > Yeah, don't do that ;-) > > > > Is IPv6 offload (gso and/or checksum) supported at this time? For GSO only TCPv4 is supported. For checksum only TCPv4 and UDPv4 are supported. Extending netback to cover more cases would be relatively trivial, I think. e.g. extending checksum_setup and/or netbk_set_skb_gso in netback.c, plus doing the opposite same on the guest RX paths. I suspect most of the complexity will probably come from the correct negotiation of the featureset via xenstore ;-) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |