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 52F0FA034C for ; Mon, 28 Mar 2022 04:15:37 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DF7624068B; Mon, 28 Mar 2022 04:15:36 +0200 (CEST) Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by mails.dpdk.org (Postfix) with ESMTP id E608640143 for ; Mon, 28 Mar 2022 04:15:34 +0200 (CEST) Received: by mail-pl1-f169.google.com with SMTP id w8so13571463pll.10 for ; Sun, 27 Mar 2022 19:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X6eBicOX+NNPf3bUEqRYu52f7oBq1VlB4trvnXvHTVA=; b=f+kH9td2lbRglKRvkpnSG9WG4rMhssT8A7tsHsdiqVbbbbq7ZxNhLPz2kmNJ4wD80R PAnB1Xe6tk3mL7vKX63DGBGv0Mgakz6E+CAwB/wC58zWrGU/vKdK9BWSL6K/6ihFLnIZ By0R1i3yr+kW9qnIlwcG93GlIgRuz1xUTG4h90Hy7HRrx8lAKqgitfBr/lHtnlpZggvO k9fDXRKJXQpRPO9oR7Htb9mQd6jfJSC4ZF0FAEwjhILvh345SuG6RRDWPUM6ZoMhftho RJemp4mCx4QFvsZF+YEFDXK4DkqprxQGLvAC1vre5Xkk+nU1iAbRRriqy3nPPzNa1is9 VJSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X6eBicOX+NNPf3bUEqRYu52f7oBq1VlB4trvnXvHTVA=; b=thd7T7fSO/ZYUAdAMDdDU9vg14Re7TJQtcq8TSSCmUiFTfCtCoLXno81TZvR0vK6au cllCJYI3XR2NCE+8gWpEauMaf7z1IbeYGtZjL9b7pwJ34S9omSzxF4iFPe4/dAMO7Up6 RYohW9s8NgjjYcFpsmVLmEJKwPCHDrb1GK1FNxSER0SV3tb7fwFabGMZ3UNUrlOjUrzY HtshFZU/NDt6SQOuD0zCUqguG3Yw5zVL/KVe4xN6H5/DGtJt0ezv94uPN2tX+qkU30W/ FeXY48by6XWeWqIEpL0qd2KLkKnzckkPHU4RZp5sgX+kqeggk10M9Q6DidL7MBAoIcvs +MNg== X-Gm-Message-State: AOAM531IXZjDRPnMoVnbdPnNslPBUBE60Sgx/02y4Sa8w/1lVRKru/hP GxVjRfvhOrMT2foFM5tbbbOR/2WrlD7dCKvHRag= X-Google-Smtp-Source: ABdhPJzjLqFm9i5e0P6ooQrNSrm+uMO+GC0l1mpZUu/ooIqRuw3Lwapoznr7yQVF9ficSBDLM4Lw2uFPFtwuVVj9rTU= X-Received: by 2002:a17:903:18c:b0:154:9ee:cedc with SMTP id z12-20020a170903018c00b0015409eecedcmr24367652plg.123.1648433733955; Sun, 27 Mar 2022 19:15:33 -0700 (PDT) MIME-Version: 1.0 References: <20220326115923.715473aa@hermes.local> <2ca34799291042f9b2ce8e1adc0fde0a@huawei.com> In-Reply-To: <2ca34799291042f9b2ce8e1adc0fde0a@huawei.com> From: Harold Huang Date: Mon, 28 Mar 2022 10:15:22 +0800 Message-ID: Subject: Re: [dpdk-users] DPDK RX TCP checksum failed To: "jiangheng (H)" Cc: Stephen Hemminger , "users@dpdk.org" Content-Type: text/plain; charset="UTF-8" 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 Mon, Mar 28, 2022 at 9:50 AM jiangheng (H) wrote: > > > 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. > > I have queried device capability and it tell me it supports tcp checksum, not supports ip checksum. > So I have set RTE_ETH_RX_OFFLOAD_TCP_CKSUM(DEV_RX_OFFLOAD_TCP_CKSUM) flag when port is configured(use rte_eth_dev_configure function) > But RX checksum still failed in below branch: > 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) { > if (hdr->csum_start <= hdrlen && l4_supported) { > m->ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_NONE; > } else { > Hdr->csum_start <= hdrlen, m->ol_flags will set to RTE_MBUF_F_RX_L4_CKSUM_NONE, causing RX checksum failed. Could you show the hdr->csum_start and hdrlen value in your test case? IIRC, hdr->csum_start should be hdr_lens.l2_len + hdr_lens.l3_len according to virtio sepc. The virtio spec has an example as follows: ``` For example, consider a partially checksummed TCP (IPv4) packet. It will have a 14 byte ether- net header and 20 byte IP header followed by the TCP header (with the TCP checksum field 16 bytes into that header). csum_start will be 14+20 = 34 (the TCP checksum includes the header), and csum_offset will be 16. ``` -- Thanks, Harold.