WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

RE: [Xen-users] Another GPLPV pre-release 0.9.11-pre20

> > Where are you seeing these? If you are seeing them at any point
before
> > the packet has passed through a physical network card then they will
> > indeed have an incorrect checksum. The checksum calculation should
be
> > deferred until the latest possible time.
> 
> I am using tcpdump in my Dom0, eg. tcpdump -vv -i br13.
> 
> Here is one example:
> 10:22:23.172581 IP (tos 0x0, ttl 128, id 18177, offset 0, flags [DF],
> proto: TCP (6), length: 74) 213.250.XX.XX.ms-wbt-server >
> 213.250.XX.XX.41635: P, cksum 0x6884 (incorrect (-> 0xc813), 39:61(22)
ack
> 1 win 64620 <nop,nop,timestamp 46147 22223084>

Yes, I would expect to see that. The checksum calculation is deferred as
late as possible. If the packet goes from DomU to DomU and both support
rx+tx offloading, then it won't be done at all - the tx side will
'offload' the calculation to it's virtual card, Dom0 will record the
fact that the data is correct, and will tell the receiving DomU that the
checksum has been verified and is good (even though it is incorrect).
That's one less pass of the data to be done, and if you are transferring
gigabits/second, thats gigabits of data per second that don't have to be
added up.

Sort of the same with large send offload.

> 
> I am bridging VLAN interfaces to Xen DomUs
> 
> eg.
> vconfig add peth0 13
> brctl addbr br13
> brctl addif br13 peth0.13
> ifconfig br13 up
> 

If you can get iperf on your windows machine, Dom0 machine, and Bacula
machine, it will make things much easier to test. In your domU, run
'iperf -s -w1M' (run as server with 1Mbyte window). In Dom0 and Bacula,
run 'iperf -c name_of_DomU_windows_machine -w1M'. What is performance
like:

Dom0<->WinDomU
Bacula<->WinDomU

With and without offload enabled?

Based on that, I'll get you to try some tcpdumps with offload enabled.
If you want to do them straight away, we are looking for:

Dom0<->WinDomU - incorrect checksums
Bacula<->WinDomU - outgoing packets from each machine have bad checksum,
incoming packets have good checksum

In Dom0 I really need to see tcpdump's of the vif interface, the bridge
interface, and the peth0.13 interface.

Also, at Dom0 you should see packets much larger than MTU appearing from
WinDomU, and the same packets but split up into MTU sized chunks
appearing on the Bacula machine. I suspect that you won't see these
packets though...

Is there a way you can check this without vlan's being involved? If
there are bugs in the Linux side of things, combining all that
offloading stuff with vlan might just be too much for it...

James

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