* 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