DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Xie, Huawei" <huawei.xie@intel.com>
To: Franck Baudin <franck.baudin@qosmos.com>,
	"Gray, Mark D" <mark.d.gray@intel.com>,
	Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"dpdk-ovs@lists.01.org" <dpdk-ovs@lists.01.org>
Subject: Re: [dpdk-dev] Wrong TCP checksum of packets sent by Linux guest (virtIO/vhost)
Date: Thu, 4 Sep 2014 02:54:02 +0000
Message-ID: <C37D651A908B024F974696C65296B57B0F2859D3@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <540721E8.2010307@qosmos.com>



> -----Original Message-----
> From: Franck Baudin [mailto:franck.baudin@qosmos.com]
> Sent: Wednesday, September 03, 2014 10:13 PM
> To: Xie, Huawei; Gray, Mark D; Thomas Monjalon
> Cc: dev@dpdk.org; dpdk-ovs@lists.01.org
> Subject: Re: [dpdk-dev] Wrong TCP checksum of packets sent by Linux guest
> (virtIO/vhost)
> 
> 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

Hi Franck:
I checked your original thread.
root at linux-native:~# tcpdump -vnei eth0
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:27:09.262926 00:1b:21:b9:9b:2c > 52:54:00:51:51:12, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 47743, offset 0, flags [DF], proto TCP (6), length 60)
   1.1.1.3.34272 > 1.1.1.2.5555: Flags [S], cksum 0x0435 (incorrect -> 0xb2dd), seq 1963818356, win 14600, options [mss 1460,sackOK,TS val 49530635 ecr 0,nop,wscale 7], length 0
17:27:09.263220 52:54:00:51:51:12 > 00:1b:21:b9:9b:2c, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 64, id 3367, offset 0, flags [DF], proto TCP (6), length 40)
    1.1.1.2.5555 > 1.1.1.3.34272: Flags [R.], cksum 0x1db4 (correct), seq 0, ack 1963818357, win 0, length 0

The packet from the guest, received on the native machine, has "correct" checksum 0x1db4. The TCP connection is refused is due to this packet has R flag. Could you check if it is the firewall that blocks the 
connection?

Besides, I did ssh tcp test between two guest VMs,  the ssh connection could be established correctly with tx checksum off. I didn't use OVDK, but set the arp table and route table manually.
The packet flow is
	Guest A(virtio)<->vhost example->Guest B(virtio)









  parent reply	other threads:[~2014-09-04  2:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-02 13:20 Franck BAUDIN
2014-09-02 13:29 ` Thomas Monjalon
2014-09-02 14:37   ` Franck Baudin
2014-09-03 10:00   ` Gray, Mark D
2014-09-03 11:13     ` Xie, Huawei
2014-09-03 14:12       ` Franck Baudin
2014-09-03 16:07         ` Gray, Mark D
2014-09-04  2:54         ` Xie, Huawei [this message]
2014-09-04  9:24           ` Franck Baudin
2014-09-04 10:35             ` Xie, Huawei
2014-09-03 16:15       ` Gray, Mark D

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C37D651A908B024F974696C65296B57B0F2859D3@SHSMSX101.ccr.corp.intel.com \
    --to=huawei.xie@intel.com \
    --cc=dev@dpdk.org \
    --cc=dpdk-ovs@lists.01.org \
    --cc=franck.baudin@qosmos.com \
    --cc=mark.d.gray@intel.com \
    --cc=thomas.monjalon@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git