[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


 


Rackspace

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