[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: Trouble with TCP between domUs
* Ian.Campbell@xxxxxxxxxxxxx [2006-12-07 15:52:27] > On Thu, 2006-12-07 at 16:38 +0100, Jacob Gorm Hansen wrote: >> >From dom0 I can ping and TCP connect to the domain just fine, but from >> the domU the TCP connection hangs after the first few packets. UIP >> complains about missing TCP checksums on the incoming packets, > > You can get round that one by writing a feature-no-csum-offload=1 node > in xenstore. netfront.c in the sparse tree does this conditionally in > order to support older Linux kernels that also don't cope well with > missing checksums. With that set dom0 should do checksumming for you. I worry about what seems like a lack of clarity around what checksum offload capability is assumed by a domain about its' peer. Let's imagine a dom0 kernel that is minimised - it has as much non-essential stuff removed as possible. That would include any protocol support that is not necessary for its functioning as a dom0. A domU runs on top of the dom0 and wishes to use a protocol that is not present in the dom0 kernel (SCTP, perhaps). If the domU kernel produces an SCTP packet and doesn't bother to calculate the relevant checksum, on the basis that dom0 is providing that facility (either via hardware in the NIC or software), what should dom0 do when it doesn't recognise the SCTP packet? Perhaps the details of checksum offload capability need to be more precisely specified (using feature declarations in the store). The mechanism introduced recently to allow a domU to say "please don't send me NETTXF_csum_blank packets" is useful - it would also be convenient to allow the dom0 to make the same request of any domU. (If a patch for this would be accepted I'll do it.) dme. -- David Edmondson, Sun Microsystems, http://www.dme.org _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |