[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] TCP checksum offload with Xen
On 19 August 2014 16:07, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote: > On 19 Aug 2014, at 09:32, Thomas Leonard <talex5@xxxxxxxxx> wrote: > >> On 19 August 2014 11:18, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote: >>> >>> On 19 Aug 2014, at 05:08, Thomas Leonard <talex5@xxxxxxxxx> wrote: >>> >>>> I see Xen allows guests to indicate that the packet checksum is blank >>>> (XEN_NETTXF_csum_blank). Then dom0 will either fill it in itself or >>>> get the NIC to do it. How can I use this with Mirage? >>>> >>>> I tried using ~flags:3 (Checksum_blank + Data_validated) in >>>> mirage-net-xen's netif.ml, but I don't see any TCP packets at all this >>>> way, even when the checksum is actually still being set. DHCP still >>>> works, though. >>>> >>>> Does anyone know how this is supposed to work? >>> >>> Probably best to trace through what netback is doing here: >>> http://lxr.free-electrons.com/source/drivers/net/xen-netback/netback.c#L1580 >>> >>> Looks like XEN_NETTXF_data_validated may need to be set as well >>> (and local packets are treated differently from off-host ones, to >>> add an extra twist). >> >> The problem turned out to be that I was setting the flag for all >> packets, including ARPs. >> Getting this to work properly will require so API changes, because >> NETWORK needs to tell the ethernet driver which types of packet can be >> offloaded, and let the driver say which packets require checksums to >> be added. >> >> Then similar changes are needed to ETHIF. Here are the hacks I used to test >> it: >> >> https://github.com/talex5/mirage/commits/csum-offload >> https://github.com/talex5/mirage-net-xen/commits/csum-offload >> https://github.com/talex5/mirage-tcpip/commits/csum-offload > > Looks good -- since V2.mli isn't tagged yet, this can just extend the call > to `write` instead of having a `write2`. I actually tried that first, but it makes V1 incompatible with V2 which complicates things a bit. As it is, if you have a V2 module you can use it with anything that wants a V1 type, which makes upgrading easier. > However, would it be better to > define an interface flags type in `NETWORK`, and just let the `write` call > supply a list of flags? That would permit easier extension to other > offloads in the future. Yes, probably. Should the flags type be abstract? > A pull request to mirage/mirage of the WIP patches would be good to track > this in the issue tracker. Done: https://github.com/mirage/mirage/pull/286 -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA _______________________________________________ MirageOS-devel mailing list MirageOS-devel@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |