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 90066430CC for ; Tue, 22 Aug 2023 08:12:17 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 84CA442D13; Tue, 22 Aug 2023 08:12:17 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 37CCB42D0C for ; Tue, 22 Aug 2023 08:12:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1692684735; 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=LshnDY7y5J0SW19cpmQfQ3E6IUgu6A41a685epsBVS8qYUn4U0DmMCxqhyub5oIaowlC9m 5V3xw9qAUmo4YH6Zrf4xO7FBGfLFO4cz/s0xhmw3/1W9QkMM9vfHqxLH1Ftfrr0OfXzdnJ TXxnnpbtjTYUtUbyH9H19CB0sRftv8M= 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-274-27Y5M2yHMYCN9--J4CYnow-1; Tue, 22 Aug 2023 02:12:12 -0400 X-MC-Unique: 27Y5M2yHMYCN9--J4CYnow-1 Received: by mail-lf1-f71.google.com with SMTP id 2adb3069b0e04-4fe3c8465e0so4318154e87.1 for ; Mon, 21 Aug 2023 23:12:12 -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=bGMAaxrLHGSTUMHJNayAM0u/rQ2154hM8n4NY1tIXTaNCUA95UtepQyVLPHg6wNvAJ l3rRUsgY8NCpx1lUHZH6tjakbiG9WnM7gnkJ+EvoSDybHaX4n5Xo72kVYlDlGD2yA3tb NMGlK+dqk7DmRXOcUhYQuPf9sft/bbXwklPRXY9YmeyA0bN/6ohL50xiGYm3UwsxMpjz D9iErXeS/iu8QHy0lTHWEMmiaXgiMfJ333BB16zr0J6FyxnPrHDSGATPpi4IIV+PQVbz BCi7SOntj0qoyn/elXM+OSnDsXV6GLp6ADpj16hVht0BwSkszuRqabmSoCZk7jEOUp2W Hj0g== X-Gm-Message-State: AOJu0YzU3vA702zEGAUa+2YOqnq90K3xV07tJ2fr8sW+gRZ6dW/jwd3C GO/52RHJKTKPjfSromhzcd/KyK+M1GI1SRFR8qgnMuw3tRYKplo8DJOUzEELEi4S/krDd9T5ra4 KSIT0PYjqsFPHoUuYbg+6aTE= X-Received: by 2002:a05:6512:2084:b0:4fe:7e64:3c1a with SMTP id t4-20020a056512208400b004fe7e643c1amr5479412lfr.2.1692684730873; 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: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-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