> On 17-Jun-2018, at 10:16 PM, Stephen Hemminger <step...@networkplumber.org>
> wrote:
>
> On Sun, 17 Jun 2018 14:55:06 +0530
> Padam Jeet Singh <padam.si...@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.
