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 6EDC6431EE; Tue, 24 Oct 2023 11:24:57 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8EC6A40DF6; Tue, 24 Oct 2023 11:24:56 +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 7147D402BE for ; Tue, 24 Oct 2023 11:24:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1698139493; 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=Lj/sIyjScBeKuV3Ytx1VR7RihMWWmYrlkcTbQ70+FYY=; b=IJi5ziFT4GpKPy8vLAwCy8HYodAyjLRdmN9ylkaQk3LCoO1ZeqS0xo/M42hAmA0gVCvJUj l1P3IpnqnzfG5iD4DHr7PXPQ96HAeSDMXZl7oal8We/pxE526kRZyRc4z/ESehuJGAGWCR IcZAQXMWtLbDqDKv00sKjC/ddjrb8PE= Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-626-zmv3hv-DON6ngv-mf5Jczw-1; Tue, 24 Oct 2023 05:24:52 -0400 X-MC-Unique: zmv3hv-DON6ngv-mf5Jczw-1 Received: by mail-lj1-f197.google.com with SMTP id 38308e7fff4ca-2c50257772bso38072171fa.3 for ; Tue, 24 Oct 2023 02:24:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698139491; x=1698744291; 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=Lj/sIyjScBeKuV3Ytx1VR7RihMWWmYrlkcTbQ70+FYY=; b=nTeNIryIz35Pu7hw6xa2oe3msQQV/rdNi3WnuqMYi5KhBJiWqocpRxo60dXwuhpep+ uVQQK+SG3Ly2X41uTZicENexD/CcZO+VCQ2PAMTaNyjbAFmoY5fdMvA0aQ7l8FPA4AA1 ceu+ttWKNSRuUyX7grgQKsvLOGf+oRkZtC4w6x5gZpXVwimi8MLMz/fiVSyaNJqP+flD mulrSirPsC7Nb4lK6L2DyzSJDaHglmlR671eu9uQ8GHRvyKjkFxOI8a9TnnIDQ6PHs9X R6sHpTeQzo7WQOiaqqgWzSHC7GgtY3Nf0k6ROuPjSs9u2XSbjMsxdww5nBgta3fUEW7A rM/w== X-Gm-Message-State: AOJu0YwBPK2CIje8mlR9GWNEfQwxpLK6ER51hSKeOmtHNEbhzzhLwgcg u+jVCRIyXsQv024a7sCdkSPkg20hW8hQjxlh1OVOnw4Ra+h0F+LFk6lX6OPSKNMKLLPto4Mieq9 qYV3jDC76BOcsZUpemBE= X-Received: by 2002:a2e:8196:0:b0:2c5:1ea4:35aa with SMTP id e22-20020a2e8196000000b002c51ea435aamr8954821ljg.48.1698139490963; Tue, 24 Oct 2023 02:24:50 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHI9cBnWd8PhLxkUm0I4bDmiZOTf0zrcAjeiZ9yz6cbL2P6FtNZR5YhdEBwfZ6ylaiB2hg8RGQ74FGHLMa6/Ao= X-Received: by 2002:a2e:8196:0:b0:2c5:1ea4:35aa with SMTP id e22-20020a2e8196000000b002c51ea435aamr8954810ljg.48.1698139490629; Tue, 24 Oct 2023 02:24:50 -0700 (PDT) MIME-Version: 1.0 References: <20231023163803.98455-1-radu.nicolau@intel.com> <25b95ddc-3cc5-a715-2160-f04a7145a92e@intel.com> In-Reply-To: <25b95ddc-3cc5-a715-2160-f04a7145a92e@intel.com> From: David Marchand Date: Tue, 24 Oct 2023 11:24:39 +0200 Message-ID: Subject: Re: [PATCH] net/iavf: fix Tx offloading flags check To: Radu Nicolau Cc: "Zhang, Qi Z" , "Wu, Jingjing" , "Xing, Beilei" , "dev@dpdk.org" , "stable@dpdk.org" , Ferruh Yigit , Thomas Monjalon , Akhil Goyal 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, Oct 24, 2023 at 11:04=E2=80=AFAM Radu Nicolau wrote: > On 24-Oct-23 9:44 AM, David Marchand wrote: > > On Tue, Oct 24, 2023 at 10:40=E2=80=AFAM Radu Nicolau wrote: > >> > >> On 24-Oct-23 6:42 AM, Zhang, Qi Z wrote: > >>>> -----Original Message----- > >>>> From: Radu Nicolau > >>>> Sent: Tuesday, October 24, 2023 12:38 AM > >>>> To: Wu, Jingjing ; Xing, Beilei > >>>> Cc: dev@dpdk.org; Nicolau, Radu ; > >>>> stable@dpdk.org; Marchand, David > >>>> Subject: [PATCH] net/iavf: fix Tx offloading flags check > >>>> > >>>> Use IAVF_TX_OFFLOAD_MASK flags instead of > >>>> IAVF_TX_CKSUM_OFFLOAD_MASK. > >>>> > >>>> Fixes: 3c715591ece0 ("net/iavf: fix checksum offloading") > >>>> Cc: stable@dpdk.org > >>>> Cc: david.marchand@redhat.com > >>>> > >>>> Signed-off-by: Radu Nicolau > >>>> --- > >>>> drivers/net/iavf/iavf_rxtx.c | 2 +- > >>>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>>> > >>>> diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rx= tx.c index > >>>> c6ef6af1d8..85f8c141ce 100644 > >>>> --- a/drivers/net/iavf/iavf_rxtx.c > >>>> +++ b/drivers/net/iavf/iavf_rxtx.c > >>>> @@ -2664,7 +2664,7 @@ iavf_build_data_desc_cmd_offset_fields(volatil= e > >>>> uint64_t *qw1, > >>>> l2tag1 |=3D m->vlan_tci; > >>>> } > >>>> > >>>> - if ((m->ol_flags & IAVF_TX_CKSUM_OFFLOAD_MASK) =3D=3D 0) > >>>> + if ((m->ol_flags & IAVF_TX_OFFLOAD_MASK) =3D=3D 0) > >>> Not sure if this will break previous fix. > >>> Could you please provide some clarification regarding the specific of= fload flags that not in IAVF_TX_CKSUM_OFFLOAD_MASK, but you still don't wan= t to skip? > >> A specific flag is RTE_ETH_TX_OFFLOAD_SECURITY, and because this is no= t > >> contained in IAVF_TX_OFFLOAD_MASK the previous fix broke the inline > >> crypto feature. > > RTE_ETH_TX_OFFLOAD_SECURITY is a ethdev level flag. > > This is not supposed to be in a mbuf ol_flags, is it? > > No, it's not, you are right. Actually it's RTE_MBUF_F_TX_SEC_OFFLOAD, > and that also means the IAVF_TX_OFFLOAD_MASK definition is not correct. > I will send another patch to fix the definition of IAVF_TX_OFFLOAD_MASK. Thanks. > > As for this fix, if you prefer a safer approach I can add another check > only for RTE_MBUF_F_TX_SEC_OFFLOAD, but one way or the other we need to > have this fix. There are multiple helpers touching offloads in this code and I don't have a clear view of what the best fix for this driver is. My concern is that IAVF_TX_OFFLOAD_MASK mixes both packet types (RTE_MBUF_F_TX_IPV[46], RTE_MBUF_F_TX_OUTER_IPV6[46]...) and actual offloading requests (RTE_MBUF_F_TX_VLAN, RTE_MBUF_F_TX_IP_CKSUM etc...). In the mbuf API, the presence of "packet types" tx flags is not described as something that requires filling l2_len / l3_len etc... For a similar reason, the presence of RTE_MBUF_F_TX_VLAN tells nothing about l2_len / l3_len. So switching to IAVF_TX_OFFLOAD_MASK seems dangerous. As for your suggestion, it seems safer only checking RTE_MBUF_F_TX_SEC_OFFLOAD, I agree. This code is still really hard to follow, so I'll let Intel maintainers advise on the best fix. --=20 David Marchand