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 6D98D431FA for ; Wed, 25 Oct 2023 11:08:01 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 675CF4064E; Wed, 25 Oct 2023 11:08:01 +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 D4005402E8 for ; Wed, 25 Oct 2023 11:07:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1698224878; 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=K6Pk42lbF7eBumzG616JMatpqWaFJIvLwM7403PUPJc=; b=DSbGrBMm+3RpU20oWFoKy6mTnVWjmZoOjlXmw0eqc8yHTknvt+xdMkUPoBQ84HE2rurbKe 56z44pTF+q5ZAnR5jvupKThbzGR/NGNGdxyE560clz5N0uP/uP4DScyfcbpaCi8spaLwu3 /X3R34OEhcCWwTU1YgTpg5CHzt9j5tg= 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-549-oekxDmRdOJiGOEeS5UdbRQ-1; Wed, 25 Oct 2023 05:07:57 -0400 X-MC-Unique: oekxDmRdOJiGOEeS5UdbRQ-1 Received: by mail-lj1-f197.google.com with SMTP id 38308e7fff4ca-2c54b040cf2so46094631fa.2 for ; Wed, 25 Oct 2023 02:07:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698224875; x=1698829675; 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=K6Pk42lbF7eBumzG616JMatpqWaFJIvLwM7403PUPJc=; b=uRWPPXH/Bik8sRyqu3neLkMKbO8Yn3uZX7Kc9O2tKV7ycGcaA6rdXGetQSbMXEV23/ QrcPGoPWa7KNi3fyRZMRWTe8Q0D5OXU1K18Bzaah1EqAzLR3QMjD3rpw6Eps+xgqjSNd zqthJCyOYABZfLEHMu7fnYLAOZu63hOh/mOgysDkvxi7OAFxT+BvXzcLIVd18cLy2aNE Bz5skJJxTZA0B23a/zuToXJSucU66h2X2v1o9P95LuYNZ2LDA+zAOTYbSrdO/+pdk/ta qSEUiygc8KPAXGUOAnH89UQ6vAYWbPfB8dp9QmRLtBl33Bt01Kp8m4Tyx6qzZidIsuFH grRQ== X-Gm-Message-State: AOJu0YzlvMrOd2w+b3b+WQgXLaLx6u2yAefGEADh0Lxg3SZEo007J0e2 cwH4hPnkRcCg0lpmJZ6u48gpGJSAMDf6s5Qf12KAaDgS7Rw4v8XDzl8IwKqa64j2YGMmVKirxGw ORfAubpLLkkgzt8Mpr1dwXWE= X-Received: by 2002:a2e:720d:0:b0:2c5:1037:b54d with SMTP id n13-20020a2e720d000000b002c51037b54dmr9666463ljc.31.1698224875534; Wed, 25 Oct 2023 02:07:55 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFGT6TqPzTl1Ex9ej0UZjc+QFaXBrI77bpF9pi1cr3tv+ljjXPmw4sQtkxQGkxe3dZ8nB2GJAovQ07dNgKhhAM= X-Received: by 2002:a2e:720d:0:b0:2c5:1037:b54d with SMTP id n13-20020a2e720d000000b002c51037b54dmr9666447ljc.31.1698224875142; Wed, 25 Oct 2023 02:07:55 -0700 (PDT) MIME-Version: 1.0 References: <20231024091328.11933-1-radu.nicolau@intel.com> <54859de7-c108-8389-43bc-9602a9897afc@intel.com> <59156c1c-c023-2504-6de5-6a84457e5ede@intel.com> <71a76142-86f6-729c-c0bc-4be7a41fb77a@intel.com> In-Reply-To: <71a76142-86f6-729c-c0bc-4be7a41fb77a@intel.com> From: David Marchand Date: Wed, 25 Oct 2023 11:07:43 +0200 Message-ID: Subject: Re: [PATCH] net/iavf: fix IAVF_TX_OFFLOAD_MASK definition To: Radu Nicolau Cc: "Zhang, Qi Z" , "Wu, Jingjing" , "Xing, Beilei" , "dev@dpdk.org" , "stable@dpdk.org" 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 Wed, Oct 25, 2023 at 11:02=E2=80=AFAM Radu Nicolau wrote: > > > On 25-Oct-23 12:30 AM, Zhang, Qi Z wrote: > > > >> -----Original Message----- > >> From: Nicolau, Radu > >> Sent: Tuesday, October 24, 2023 10:49 PM > >> To: Zhang, Qi Z ; Marchand, David > >> > >> Cc: Wu, Jingjing ; Xing, Beilei ; > >> dev@dpdk.org; stable@dpdk.org > >> Subject: Re: [PATCH] net/iavf: fix IAVF_TX_OFFLOAD_MASK definition > >> > >> > >> On 24-Oct-23 12:24 PM, Zhang, Qi Z wrote: > >>>> -----Original Message----- > >>>> From: Radu Nicolau > >>>> Sent: Tuesday, October 24, 2023 6:23 PM > >>>> To: Marchand, David > >>>> Cc: Wu, Jingjing ; Xing, Beilei > >>>> ; dev@dpdk.org; stable@dpdk.org > >>>> Subject: Re: [PATCH] net/iavf: fix IAVF_TX_OFFLOAD_MASK definition > >>>> > >>>> > >>>> On 24-Oct-23 10:49 AM, David Marchand wrote: > >>>>> On Tue, Oct 24, 2023 at 11:13=E2=80=AFAM Radu Nicolau > >>>>> > >>>> wrote: > >>>>>> IAVF_TX_OFFLOAD_MASK definition contained > >>>> RTE_ETH_TX_OFFLOAD_SECURITY > >>>>>> instead of RTE_MBUF_F_TX_SEC_OFFLOAD. > >>>>>> > >>>>>> Fixes: 6bc987ecb860 ("net/iavf: support IPsec inline crypto") > >>>>>> Cc: stable@dpdk.org > >>>>>> > >>>>>> Signed-off-by: Radu Nicolau > >>>>> Something is not clear to me. > >>>>> How was the IPsec inline crypto feature supposed to work with this > >>>>> driver so far? > >>>>> > >>>>> Any packet with the RTE_MBUF_F_TX_SEC_OFFLOAD flag should have > >> been > >>>>> refused in iavf_prep_pkts. > >>>>> > >>>> It worked because the IPsec sample app doesn't call > >>>> rte_eth_tx_prepare, and from what I can see no other sample app does= . > >>> To keep consistent, its better to refine the > >> IAVF_TX_OFFLOAD_NOTSUP_MASK definition. > >> > >> You mean like this? > >> > >> > >> #define IAVF_TX_OFFLOAD_NOTSUP_MASK ( \ > >> RTE_MBUF_F_TX_OFFLOAD_MASK ^ ( \ > >> RTE_MBUF_F_TX_OUTER_IPV6 | \ > >> RTE_MBUF_F_TX_OUTER_IPV4 | \ > >> RTE_MBUF_F_TX_IPV6 | \ > >> RTE_MBUF_F_TX_IPV4 | \ > >> RTE_MBUF_F_TX_VLAN | \ > >> RTE_MBUF_F_TX_IP_CKSUM | \ > >> RTE_MBUF_F_TX_L4_MASK | \ > >> RTE_MBUF_F_TX_TCP_SEG | \ > >> RTE_MBUF_F_TX_UDP_SEG | \ > >> RTE_MBUF_F_TX_TUNNEL_MASK | \ > >> RTE_MBUF_F_TX_OUTER_IP_CKSUM | \ > >> RTE_MBUF_F_TX_OUTER_UDP_CKSUM | \ > >> RTE_MBUF_F_TX_SEC_OFFLOAD)) > > Sorry, I miss understanding this code change, actually you didn't remov= e a flag, but just replace it, NOTSUP_MASK no need to be changed > > > > Then I don't understand why "Any packet with the RTE_MBUF_F_TX_SEC_OFFL= OAD flag should have refused in iavf_prep_pkts" > > But I assume tx_pkt_prepare should reject only invalid packets while st= ill functioning correctly with inline IPsec. > > rte_eth_tx_prepare would have rejected the packets before this fix, but > no app calls rte_eth_tx_prepare. The only app that calls it is testpmd. >From my understanding, applications that want checksum offload are required to call rte_eth_tx_prepare. --=20 David Marchand