DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Gray, Mark D" <mark.d.gray@intel.com>
To: Franck Baudin <franck.baudin@qosmos.com>,
	"Xie, Huawei" <huawei.xie@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: Wed, 3 Sep 2014 16:07:48 +0000	[thread overview]
Message-ID: <738D45BC1F695740A983F43CFE1B7EA92D723605@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <540721E8.2010307@qosmos.com>

> 
> 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.

This sounds like a DPDK issue. However, we did "clone and own" the vhost
code as it is a sample app. It may have changed since we integrated it.

We plan to use the vhost library interface when it is available on dpdk.org. So
that would pick up the latest version of the vhost code.

> 
> Franck

  reply	other threads:[~2014-09-03 16:04 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 [this message]
2014-09-04  2:54         ` Xie, Huawei
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=738D45BC1F695740A983F43CFE1B7EA92D723605@IRSMSX102.ger.corp.intel.com \
    --to=mark.d.gray@intel.com \
    --cc=dev@dpdk.org \
    --cc=dpdk-ovs@lists.01.org \
    --cc=franck.baudin@qosmos.com \
    --cc=huawei.xie@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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).