From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <users-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id CE116A034C
for <public@inbox.dpdk.org>; Sat, 26 Mar 2022 19:59:29 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 9C0B24285F;
Sat, 26 Mar 2022 19:59:28 +0100 (CET)
Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com
[209.85.214.172])
by mails.dpdk.org (Postfix) with ESMTP id 1F78642858
for <users@dpdk.org>; Sat, 26 Mar 2022 19:59:27 +0100 (CET)
Received: by mail-pl1-f172.google.com with SMTP id p17so11399162plo.9
for <users@dpdk.org>; Sat, 26 Mar 2022 11:59:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=networkplumber-org.20210112.gappssmtp.com; s=20210112;
h=date:from:to:cc:subject:message-id:in-reply-to:references
:mime-version:content-transfer-encoding;
bh=L3fGkm960touch63/HLsndD8P5oxrgGmURr94ei8Wxc=;
b=FlyrL0jaaQ7wwvA9RqQTZNrij2XAz0Spb3Ub2oSdGPeAu9oaDRyfMGOTPagnPs4ovq
7iv8UDsxXy4chrw249v+UXcHYJlFGwfIuwKn3km9QP8YQFo2pvndPWY51uO7txsrjbhl
fbVpFsNrCrpTTNQifsW5ydEerZiOoCLLXN+ZkGwKCYXJLxctaRZIV6vLhy73RekJkDWc
RaqjXxQIS0Qw0Zi8Yj9JwnYfruqtbY59HvkhMgcQ9LqpY38rFw8PGZLQVzpo7ze9MD75
T1bCdvGPaNxnukp2bV9/xJdYkqhkF2dC/uFTEXSH7Mig74HDp8uhjI9uT8yhk3KsRjFX
u5KQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
:references:mime-version:content-transfer-encoding;
bh=L3fGkm960touch63/HLsndD8P5oxrgGmURr94ei8Wxc=;
b=BoqtygVQjRetQ4mqO0m0mzRAjA+HIaGnldtPbhp1RYRblynGeH9cYq0auq7vp8omoQ
LugFSrWdzc2N/LsH7ji/DnD5M4xHvsX2dcD3dGdl5ebKUKFSmcehD5HHXQujqOdPUED6
mhUGYtwTKiBAOBzVC34+xN9LAHthiJBPakpgkXfnQ905yh3NBNgvMzEV3tq/ojv0JYVZ
w0My+pC1GWvhu06c+sbSqxJFghQ46KrZMGbFRO6DhY7/9QZW7OJfpn/Zq0ulw27quCrt
tEgd+6wipK2EwtPysLYXQ39PWkJU2TpguIV7k8PAO29nDle2o/cG0B4hhhpvFoSWjpu5
7PPQ==
X-Gm-Message-State: AOAM533osXFd141jJST0ffITO06+AY707C1KFzS/h/fObjRfLXlz1nLG
NTU/KUJE8cuNk+PIVwugnPV7Hw==
X-Google-Smtp-Source: ABdhPJw+//gxuTNmP9tmvoVMVWtObpypEwU1JeqQ74j5P/tZsFAYBm18z3t4hf/myAn2W8DAbVIMsw==
X-Received: by 2002:a17:90a:306:b0:1c6:ff30:70da with SMTP id
6-20020a17090a030600b001c6ff3070damr31563990pje.117.1648321166953;
Sat, 26 Mar 2022 11:59:26 -0700 (PDT)
Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199])
by smtp.gmail.com with ESMTPSA id
l6-20020a17090a660600b001c985b0cb53sm1143254pjj.26.2022.03.26.11.59.26
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 26 Mar 2022 11:59:26 -0700 (PDT)
Date: Sat, 26 Mar 2022 11:59:23 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: "jiangheng (H)" <jiangheng12@huawei.com>
Cc: "users@dpdk.org" <users@dpdk.org>
Subject: Re: [dpdk-users] DPDK RX TCP checksum failed
Message-ID: <20220326115923.715473aa@hermes.local>
In-Reply-To: <cb53d6174669407b96a0f6a09d6bf134@huawei.com>
References: <cb53d6174669407b96a0f6a09d6bf134@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-BeenThere: users@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK usage discussions <users.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/users>,
<mailto:users-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/users/>
List-Post: <mailto:users@dpdk.org>
List-Help: <mailto:users-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/users>,
<mailto:users-request@dpdk.org?subject=subscribe>
Errors-To: users-bounces@dpdk.org
On Sat, 26 Mar 2022 08:13:21 +0000
"jiangheng (H)" <jiangheng12@huawei.com> wrote:
> Hi all,
>
> I tried using the checksum offloads feature in DPDK and it did not see working under virtual machine.
>
> Port only support TCP checksum and do not support IP checksum:
> rx_offload_capa = DEV_RX_OFFLOAD_TCP_CKSUM
> tx_offload_capa = DEV_TX_OFFLOAD_TCP_CKSUM
>
> so I config rxmode.offload txmode.offloads as below:
> rxmode.offloads = DEV_RX_OFFLOAD_TCP_CKSUM
> txmode.offloads = DEV_TX_OFFLOAD_TCP_CKSUM
>
> For TX, I set the following parameters, it works good.
> mbuf->l2_len = sizeof(*ethhdr)
> mbuf->l3_len = ip header len
> mbuf-ol_flags = RTE_MBUF_F_TX_IPV4 | RTE_MBUF_F_TX_TCP_CKSUM
Virtio does not support IP checksum offload. Because Virtio passes
packets to Linux kernel, and Linux kernel does not do IP checksum offload.
The IP checksum is so trivial it is faster for most things to just
do it in software; the header is only 20 bytes and it will be in cache.
You should always check device capability before enabling an offload.
> For RX, It will execute the following code:
> In drivers/net/virtio/virtio_rxtx.c virtio_rx_offload function :
> if (hdr->flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) {
> hdrlen = hdr_lens.l2_len + hdr_lens.l3_len + hdr_lens.l4_len;
> if (hdr->csum_start <= hdrlen && l4_supported) {
> m->ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_NONE;
> } else {
>
> m->ol_flags set to RTE_MBUF_F_RX_L4_CKSUM_NONE, causing the TCP RX checksum failed.
> How do I avoid the above code going into this branch?
>
If you want TCP checksum offload you have to set RTE_ETH_RX_OFFLOAD_TCP_CKSUM
in the rxmode when port is configured. This will tell virtio to ask the
host to do rx offload. Again, virtio does not do IP checksum offload and
you should always query device capability first.