From mboxrd@z Thu Jan 1 00:00:00 1970 From: Franck Baudin Subject: Re: Wrong TCP checksum of packets sent by Linux guest (virtIO/vhost) Date: Wed, 03 Sep 2014 16:12:56 +0200 Message-ID: <540721E8.2010307@qosmos.com> References: <1686757.iSdNo6aMGt@xps13> <738D45BC1F695740A983F43CFE1B7EA92D72308F@IRSMSX102.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev-VfR2kkLFssw@public.gmane.org" , "dpdk-ovs-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org" To: "Xie, Huawei" , "Gray, Mark D" , Thomas Monjalon Return-path: In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" Hi, On 09/03/14 13:13, Xie, Huawei wrote: > Looping in the dpdk-ovs list. > > * Does the new vhost API allow a user to know if all the relevant offloads have > been > turned on/off for that interface? It seems that this is possible through the > virtio_net > structure but it would be good to get some feedback from the relevant person > working on DPDK (Huawei?). > > * If this is the case, then it is probably in the realm of the vswitch do the actual > checksum (for VM-VM) or correctly configure the NIC when sending out through > the physical interface. > > Comments? > > Mark: > So far not supported. This is important as well in VxLan case. For the packet flow > Guest A-> virtio -> ..->OVDK->.. -> Guest B. > 1) If guest A and B are on different host machines, say A and B respectively, and if the nic on A supports > vxlan checksum offload, then both guest and host needn't generate checksum, the nic will > generate checksum for both inner and outer packet. > 2) In VM2VM case, as it is trusted communication channel, could we negotiate with the guest tcp stack not to verify checksum > for received packet? The problem is that any TCP packet send by a vanilla Linux guest through vhost is incorrect (VM to anything, including other colocalied VMs). In other words, the VM cannot use TCP. QEMU options and ethtool -K csum off tso off ("TCP stack negociation") have no effect, maybe because the vhost backend is misbehaving. Franck