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 DB2BE430CC; Tue, 22 Aug 2023 08:12:15 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6BFFB4021D; Tue, 22 Aug 2023 08:12:15 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 879AD40041 for ; Tue, 22 Aug 2023 08:12:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1692684734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qMS5Ckdxw8YV4uG+amWF4PsH+wcYhG2v8uYA0oYxB5c=; b=C5e4JUHfMzuvxwzsk+iHxcI0L4j3jCu7dzM+8FaC1flt13YmWnCkumLkvW9BcMKftCVPtw k2rIHO/u27Vbu03ZOdwWTFJDzirRxpuX6hL/ZoJ969o/FuuBOvJUGCqqxNg9sv8vX5IwAg KWZ5Zkvad3R1aegKZFYTWyfjgVLJvI0= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-63-rQHJTASnPLiPr_fDI4ui6A-1; Tue, 22 Aug 2023 02:12:12 -0400 X-MC-Unique: rQHJTASnPLiPr_fDI4ui6A-1 Received: by mail-lf1-f71.google.com with SMTP id 2adb3069b0e04-4ff908143acso4322956e87.0 for ; Mon, 21 Aug 2023 23:12:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692684731; x=1693289531; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qMS5Ckdxw8YV4uG+amWF4PsH+wcYhG2v8uYA0oYxB5c=; b=UXYZvqkqWvOq9ehkPloPkxaJrcXnwt8jzA9+3EitExrbM4cbaF9sQEvGoT27uziVsP VrhCBkciJLP9B4hi9kPo62joALnGXtPjsTSvALNf/snjjbqrfuHTjEgwNL3LwVT4Mrm6 T70DazVaMlmr9+QoOWOT+J5DUGnqPDXyAK3/x7qPkalEkI0m7A/bgUJGfyhrKGk6hTKv Hp9SKbe9yG5pplnJlS9FcZC9fjXbBQsANsLhc84yoM1jGYs6H9vehRg2CGf66ecn4BF1 1cMJW3cRFfVD50kUgawyHw5MLIiacngju8k2U7kQl0jMxLoucEtxa44MSQDzGoL15jbC Nk1w== X-Gm-Message-State: AOJu0YxoCsjDE0qf912snuOVApS8+kL1ifkgPsSZ8jn8gTGV1LnThMCx 8X9yhjL/CSn3FxS+3f38Rm7e8bbzvLijG1vMEh127P6HnioWXd5boPLUzZlLNNpOcTK267NBOcj u8Z4se8HcAaJ3MIYZDjA= X-Received: by 2002:a05:6512:2084:b0:4fe:7e64:3c1a with SMTP id t4-20020a056512208400b004fe7e643c1amr5479416lfr.2.1692684730874; Mon, 21 Aug 2023 23:12:10 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEyBRKqzf1Sc1h3uvP2sG9lkNqdvxmeT3pmpkVU3B/L/jok82zINtMbvNVC5yNExZmJ8Op9atV8yewDU+ks0Z0= X-Received: by 2002:a05:6512:2084:b0:4fe:7e64:3c1a with SMTP id t4-20020a056512208400b004fe7e643c1amr5479402lfr.2.1692684730565; Mon, 21 Aug 2023 23:12:10 -0700 (PDT) MIME-Version: 1.0 References: <20230818090351.2402519-1-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Tue, 22 Aug 2023 08:11:58 +0200 Message-ID: Subject: Re: [PATCH] net/iavf: fix checksum offloading To: "Zhang, Qi Z" Cc: "dev@dpdk.org" , "echaudro@redhat.com" , "mkp@redhat.com" , "stable@dpdk.org" , "Wu, Jingjing" , "Xing, Beilei" , "Doherty, Declan" , "Sinha, Abhijit" , "Nicolau, Radu" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, Aug 22, 2023 at 3:52=E2=80=AFAM Zhang, Qi Z = wrote: > > > > > -----Original Message----- > > From: David Marchand > > Sent: Tuesday, August 22, 2023 1:29 AM > > To: Zhang, Qi Z > > Cc: dev@dpdk.org; echaudro@redhat.com; mkp@redhat.com; > > stable@dpdk.org; Wu, Jingjing ; Xing, Beilei > > ; Doherty, Declan ; Si= nha, > > Abhijit ; Nicolau, Radu > > Subject: Re: [PATCH] net/iavf: fix checksum offloading > > > > On Mon, Aug 21, 2023 at 1:54=E2=80=AFPM Zhang, Qi Z wrote: > > > > Subject: [PATCH] net/iavf: fix checksum offloading > > > > > > > > The only presence of RTE_MBUF_F_TX_IPV4 can't be used as an > > > > indicator that a checksum offload has been requested by an applicat= ion. > > > > > > According to current implementation, actually the only presence of > > RTE_MBUF_F_TX_IPV4 will cause IIPT =3D 10b, this scenario corresponds t= o an > > 'IPv4 packet with no IP checksum offload,' according to datasheet. > > > So, I assume in this situation, the PMD continues to operate under t= he > > assumption that the application has not requested checksum offloading. > > > > > > Could you share more insight what is the failure, maybe we can perfo= rm a > > more comprehensive investigation? > > > > I think the missing piece is that OVS passes a l2_len =3D=3D l3_len =3D= =3D 0. > > In our tests, we could see that tx_errors get incremented for each fail= ed packet > > to transmit. > > OK, do you think to ignore RTE_MBUF_F_TX_IPV4 when l3_len =3D 0 is a bett= er fix? Looking at the mbuf API, l2_len and l3_len should be considered by a driver if ol_flags contains at least one of RTE_MBUF_F_TX_SEC_OFFLOAD, RTE_MBUF_F_TX_TUNNEL_*, RTE_MBUF_F_TX_TCP_SEG, RTE_MBUF_F_TX_(IP|TCP|UDP|SCTP)_CKSUM. Here, it is not the case. If the driver reads l2_len or l3_len, this is an undefined behavior: for example, OVS might have been using l2_len or l3_len for its internal uses (though I agree it would be risky for an application to do so). We probably need to fix access to l2_len a few lines before my patch. if (m->ol_flags & RTE_MBUF_F_TX_TUNNEL_MASK && !(m->ol_flags & RTE_MBUF_F_TX_SEC_OFFLOAD)) offset |=3D (m->outer_l2_len >> 1) << IAVF_TX_DESC_LENGTH_MACLEN_SHIFT; else offset |=3D (m->l2_len >> 1) << IAVF_TX_DESC_LENGTH_MACLEN_SHIFT; But to be clear, no I don't think looking at l3_len value is better: it should not be read at all. --=20 David Marchand