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 3207AA034C for ; Mon, 28 Mar 2022 05:12:07 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BBF6F4285A; Mon, 28 Mar 2022 05:12:06 +0200 (CEST) Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) by mails.dpdk.org (Postfix) with ESMTP id 149DC4068B for ; Mon, 28 Mar 2022 05:12:05 +0200 (CEST) Received: by mail-vs1-f52.google.com with SMTP id k15so11986663vsr.11 for ; Sun, 27 Mar 2022 20:12:04 -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=oG9VjU16lypL2bVsxAk1PBAWtM/LGRAC47tuEjNo1/U=; b=g5KUmkE35HCdwZYVP39qKGtGbOmonMqhIYO8UGGmmz5t8kga97oaw9z0nkao+Y80ei vo6jrwydXaLMRnow+nYQaez3Fpo0tnkKUcOnp/RnjN/E2w2CEFIPHAMCde9JGxiyeAxD CePaiu431c6tlGWAKpDPKC559ICosCoVVQonAKhg+cIUrOuq/3oeO9vJMAtMJWGsQQEA EyxNUnRGnwe4VUkuHwNrSNgyK4FqKLKQ3xS6OhstLixlREzD/Bw6gEfVf9Xb5PauV0BK M9hjEH7LTrCu2GRhjGcNK/gutjcSW/PdVOepCBpFouw60VPrCpJEv1JLDT5Ix6epw63F 4mBQ== 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=oG9VjU16lypL2bVsxAk1PBAWtM/LGRAC47tuEjNo1/U=; b=52VEnht9ifp0qRktqOO7PUPfyIZTFle8AhcAK3ZraHuCmoyQmC11L7upKsKgCpOcq8 0FXcVQO8KjP+wzb8mbuLcEb4pokageiqMz9zki2E30S4Qkhk0lonKTr7FYzgEKUyYEXZ cCMfZwFULpzPgFG0iulUnajAGst9pMYWNwPBRFqGFXEtCoHyCraLbdgEl35l6bFllOv6 axCG5GCsfDORfwaHBlpZ4szttq/xDwAMCDdeT8oIxbGJV3HZ5XbxzZZhs1oMZb/tquyH mTpZ+Jvu/3Ddne3US4JSWIzsVwgCpZO19WCnBQLECazh1yl0WNevruaniz6q+/k/uIBT BheA== X-Gm-Message-State: AOAM530RqSLoApt62zRVlq+S86zq5Tvj8kxAb6KAM+vhymtb7jUlHflK chSTrwC6+3vYT/ei7hj9k4mRRjgNeCwA+UrCzZY= X-Google-Smtp-Source: ABdhPJx7p+cAnIGgRUv06gpCck5/RjFP+T/3fbojGOYE5wc+W9J86e/px3sXIx5Z4Hon3LqA3fS0wNu8NsRLBeOGhow= X-Received: by 2002:a67:f882:0:b0:322:ef79:7713 with SMTP id h2-20020a67f882000000b00322ef797713mr8648834vso.70.1648437124386; Sun, 27 Mar 2022 20:12:04 -0700 (PDT) MIME-Version: 1.0 References: <20220326115923.715473aa@hermes.local> In-Reply-To: <20220326115923.715473aa@hermes.local> From: fwefew 4t4tg <7532yahoo@gmail.com> Date: Sun, 27 Mar 2022 23:11:53 -0400 Message-ID: Subject: Re: [dpdk-users] DPDK RX TCP checksum failed To: Stephen Hemminger Cc: "jiangheng (H)" , "users@dpdk.org" Content-Type: multipart/alternative; boundary="0000000000003bd31705db3eadd1" 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 --0000000000003bd31705db3eadd1 Content-Type: text/plain; charset="UTF-8" https://github.com/rodgarrison/reinvent demonstrates ether/UDP chec-kum offload running on AWS which uses virtio. I don't think TCP offload is substantially different. Look here: https://github.com/rodgarrison/reinvent/blob/main/integration_tests/reinvent_dpdk_udp/reinvent_dpdk_udp_integration_test.cpp#L345 for where the mbuf needs to be setup. But I kind of agree with Stephan, although I haven't tested it, avoiding more sets into mbuf which might involve cache misses it might be faster to do by hand since the data is already in cache. On Sat, Mar 26, 2022 at 2:59 PM Stephen Hemminger < stephen@networkplumber.org> 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. > > --0000000000003bd31705db3eadd1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
https:= //github.com/rodgarrison/reinvent
demonstrates ether/UDP chec-kum=C2= =A0offload running on AWS which uses virtio. I don't think TCP offload<= div>is substantially different. Look here:

https://github.com/rodgarrison/re= invent/blob/main/integration_tests/reinvent_dpdk_udp/reinvent_dpdk_udp_inte= gration_test.cpp#L345

for where the mbuf needs to be setup.
<= br>But I kind of agree with Stephan, although I haven't tested it, avoi= ding more sets into mbuf which might involve cache misses it might be faste= r to do by hand since the=C2=A0data is already in cache.

On Sat, Mar 2= 6, 2022 at 2:59 PM Stephen Hemminger <stephen@networkplumber.org> wrote:
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 =3D DEV_RX_OFFLOAD_TCP_CKSUM
> tx_offload_capa =3D DEV_TX_OFFLOAD_TCP_CKSUM
>
> so I config rxmode.offload txmode.offloads as below:
> rxmode.offloads =3D DEV_RX_OFFLOAD_TCP_CKSUM
> txmode.offloads =3D DEV_TX_OFFLOAD_TCP_CKSUM
>
> For TX, I set the following parameters, it works good.
> mbuf->l2_len =3D sizeof(*ethhdr)
> mbuf->l3_len =3D ip header len
> mbuf-ol_flags =3D RTE_MBUF_F_TX_IPV4 | RTE_MBUF_F_TX_TCP_CKSUM


Virtio does not support IP checksum offload.=C2=A0 Because Virtio passes packets to Linux kernel, and Linux kernel does not do IP checksum offload.<= br> 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=C2=A0 virtio_rx_offload function :=
>=C2=A0 =C2=A0 =C2=A0if (hdr->flags & VIRTIO_NET_HDR_F_NEEDS_CSUM= ) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0hdrlen =3D hdr_lens.l2_len + hdr_lens= .l3_len + hdr_lens.l4_len;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (hdr->csum_start <=3D hdrlen= && l4_supported) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0m->ol_flags |=3D RTE= _MBUF_F_RX_L4_CKSUM_NONE;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} 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_CKS= UM
in the rxmode when port is configured.=C2=A0 This will tell virtio to ask t= he
host to do rx offload. Again, virtio does not do IP checksum offload and you should always query device capability first.

--0000000000003bd31705db3eadd1--