DPDK patches and discussions
 help / color / mirror / Atom feed
From: Yong Wang <yongwang@vmware.com>
To: Padam Jeet Singh <padam.singh@inventum.net>,
	Stephen Hemminger <stephen@networkplumber.org>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] vmxnet3 TX TCP/UDP checksum not getting computed with L2_len > 14
Date: Thu, 13 Sep 2018 21:39:02 +0000	[thread overview]
Message-ID: <9BF3B720-6381-4574-97B4-450F54C67E60@vmware.com> (raw)
In-Reply-To: <C09E6F4E-22DC-444B-B23D-AB6FFCB7ADDE@inventum.net>



-----Original Message-----
From: Padam Jeet Singh <padam.singh@inventum.net>
Date: Sunday, June 17, 2018 at 12:00 PM
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Yong Wang <yongwang@vmware.com>
Subject: Re: [dpdk-dev] vmxnet3 TX TCP/UDP checksum not getting computed with L2_len > 14


    >> On 17-Jun-2018, at 10:16 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
    >> 
    >> On Sun, 17 Jun 2018 14:55:06 +0530
    >> Padam Jeet Singh <padam.singh@inventum.net> wrote:
    >> 
    >>> Hello,
    >>> 
    >>> Issue observed when using vmxnet3 based interface on packet with following structure is sent:
    >>> 
    >>> Ethernet + PPPoE + PPP (22 bytes) as the Layer 2 header, 
    >>> IPv4 (20) 
    >>> UDP
    >>> DNS Payload
    >>> 
    >>> The tx offload value in this case is 0x0f0000000000000 (PKT_TX_IPV4  | PKT_TX_IP_CKSUM | PKT_TX_UDP_CKSUM)
    >>> 
    >>> The checksum of the packet seen by the receiver shows incorrect checksum and it’s value is the pseudo checksum value that was set at the time of the TX. However the IP header checksum is correct.
    >>> 
    >>> The same issue is not seen when the L2 header is a just the Ethernet (14 bytes).
    >>> 
    >>> Also, with the same setup on the same hardware if we switch the driver from vmxnet3 to e1000e, all checksums are computed correctly.
    >>> 
    >>> Is this a DPDK vmxnet3 driver bug or that of underlying esxi? The ESXi version is 6.0.0 (Build 3620759).
    >>> 
    >>> Thanks,
    >>> Padam
    >> 
    >> I don't think VMWare supports IP checksum offload. Since IP checksum is trivial and in cache,
    >> the IP header checksum offload is usually not a speed up anyway. Linux for example, never does
    >> IP header checksum offload.
    
    >  It’s not the IP checksum - it’s the TCP/UDP checksum (L4) that’s not getting computed. In fact the IP checksum is coming correctly because we are handing it in software. The driver when queried returns TX offload flags with the IP header checksum bit off, but L4 checksum (TCP & UDP) are available. The UDP checksum gets computed correctly if and only if the l2_len is 14. In case of other encapsulations, e.g. pppoe (l2_len=22), this checksum computation is being skipped and the packet is simply sent out with the pseudo checksum value of the IP header. 

Vmxnet3 backend does not support Ethernet + PPPoE + PPP as layer 2 header if l4 checksum if requested.


      reply	other threads:[~2018-09-13 21:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-17  9:25 Padam Jeet Singh
2018-06-17 16:46 ` Stephen Hemminger
2018-06-17 19:00   ` Padam Jeet Singh
2018-09-13 21:39     ` Yong Wang [this message]

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=9BF3B720-6381-4574-97B4-450F54C67E60@vmware.com \
    --to=yongwang@vmware.com \
    --cc=dev@dpdk.org \
    --cc=padam.singh@inventum.net \
    --cc=stephen@networkplumber.org \
    /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).