From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id CE116A034C for ; 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 ; Sat, 26 Mar 2022 19:59:27 +0100 (CET) Received: by mail-pl1-f172.google.com with SMTP id p17so11399162plo.9 for ; 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 To: "jiangheng (H)" Cc: "users@dpdk.org" Subject: Re: [dpdk-users] DPDK RX TCP checksum failed Message-ID: <20220326115923.715473aa@hermes.local> In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org On Sat, 26 Mar 2022 08:13:21 +0000 "jiangheng (H)" 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.