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 6C87FA034F; Mon, 7 Feb 2022 15:15:43 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3B221410F3; Mon, 7 Feb 2022 15:15:43 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by mails.dpdk.org (Postfix) with ESMTP id 9964B410EA for ; Mon, 7 Feb 2022 15:15:41 +0100 (CET) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 2178sijB010001; Mon, 7 Feb 2022 06:15:40 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=message-id : date : mime-version : subject : to : references : from : cc : in-reply-to : content-type : content-transfer-encoding; s=pfpt0220; bh=4MQHz1cnfdYdZAejjQGQFUdQ+z9TlSMoYwfElrsKFQo=; b=WMTNJx73UyC0WvK0oXCNRWP/sURy7IOxWeljN0U+EKW7U0c8HmwJrwylPodV+WK7YapD I4JebBDqFIXp05eE01mUWceZPJIQy05/PTq8fi1KngVkI8rPzHWMClIBdPSBWAtYWiBO aSOOdFYWfMAryxR9zptsfIS3ZgmJqcfS2qUj5T1W5zTD/Hzte5IEFLGVmcbUCWlmR5GH +gOg5NUXCa3tsjR56bOHpZk7/s2WsIqXOQORzpJeWoCS2xUXXCCPiXcEKTuXfVzNCR+O 1ouMqv1YYWDcAbRNlwXG8LOk3K7rhZ1SKvpqCR6tA3JZV9K5surUS2/pTZd3Q5IkWlrS og== Received: from dc5-exch02.marvell.com ([199.233.59.182]) by mx0a-0016f401.pphosted.com (PPS) with ESMTPS id 3e30b095tb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 07 Feb 2022 06:15:40 -0800 Received: from DC5-EXCH02.marvell.com (10.69.176.39) by DC5-EXCH02.marvell.com (10.69.176.39) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 7 Feb 2022 06:15:39 -0800 Received: from maili.marvell.com (10.69.176.80) by DC5-EXCH02.marvell.com (10.69.176.39) with Microsoft SMTP Server id 15.0.1497.18 via Frontend Transport; Mon, 7 Feb 2022 06:15:39 -0800 Received: from [10.28.175.194] (PE-LT1350.marvell.com [10.28.175.194]) by maili.marvell.com (Postfix) with ESMTP id 9D4513F7068; Mon, 7 Feb 2022 06:15:37 -0800 (PST) Message-ID: Date: Mon, 7 Feb 2022 19:45:36 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH 2/4] examples/ipsec-secgw: disable Tx chksum offload for inline Content-Language: en-US To: , References: <20220206143022.13098-1-ndabilpuram@marvell.com> <20220206143022.13098-2-ndabilpuram@marvell.com> From: Nithin Kumar Dabilpuram CC: , In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-GUID: WutFiA7KF6y7FrbyfZotCrFapx2B_Lo2 X-Proofpoint-ORIG-GUID: WutFiA7KF6y7FrbyfZotCrFapx2B_Lo2 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-07_05,2022-02-07_02,2021-12-02_01 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 2/7/22 3:22 PM, Ananyev, Konstantin wrote: > >> Enable Tx IPv4 checksum offload only when Tx inline crypto is needed. >> In other cases such as Tx Inline protocol offload, checksum computation >> is implicitly taken care by HW. > > Why is that? > These is two separate HW offload and user has to enable each of them explicitly. In Inline IPSec protocol offload, the complete tunnel header for tunnel mode is updated by HW/PMD. So it doesn't have any dependency on RTE_ETH_TX_OFFLOAD_IPV4_CKSUM as there is no valid l2_len/l3_len yet in the mbuf. Similarly in case of Transport mode, the IPv4 header is updated by HW itself for next proto and hence the offsets and all can vary based on the HW implementation. Hence my thought was for Inline IPsec protocol offload, there is no need to explicitly say that RTE_ETH_TX_OFFLOAD_IPV4_CKSUM is enabled and need not provide ol_flags RTE_MBUF_F_TX_IP_CKSUM and l2_len and l3_len which might not be correct in prepare_tx_pkt(). >* RTE_MBUF_F_TX_IP_CKSUM. > * - fill the mbuf offload information: l2_len, l3_len (Ex: Tunnel header being inserted is IPv6 while inner header is IPv4. For inline crypto I agree, the packet content is all in place except for plain text->cipher text translation so l2/l3 offsets are valid. > Also we can TX clear-text traffic. Ok, I agree that we can have clear-text traffic. We are already handling ipv4 checksum in SW in case Tx offload doesn't have IPv4 Checksum offload enabled. And for clear text traffic I think that is not needed as well as we are not updating ttl. My overall intention was to have lighter Tx burst function for Inline IPsec protocol offload as mainly IPsec traffic and not plain traffic is primary use case for ipsec-secgw. > >> The advantage of having only necessary >> offloads enabled is that Tx burst function can be as light as possible. >> >> Signed-off-by: Nithin Dabilpuram >> --- >> examples/ipsec-secgw/ipsec-secgw.c | 3 --- >> examples/ipsec-secgw/sa.c | 9 +++++++++ >> 2 files changed, 9 insertions(+), 3 deletions(-) >> >> diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c >> index 21abc0d..d8a9bfa 100644 >> --- a/examples/ipsec-secgw/ipsec-secgw.c >> +++ b/examples/ipsec-secgw/ipsec-secgw.c >> @@ -2314,9 +2314,6 @@ port_init(uint16_t portid, uint64_t req_rx_offloads, uint64_t req_tx_offloads) >> local_port_conf.txmode.offloads |= >> RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE; >> >> - if (dev_info.tx_offload_capa & RTE_ETH_TX_OFFLOAD_IPV4_CKSUM) >> - local_port_conf.txmode.offloads |= RTE_ETH_TX_OFFLOAD_IPV4_CKSUM; >> - >> printf("port %u configuring rx_offloads=0x%" PRIx64 >> ", tx_offloads=0x%" PRIx64 "\n", >> portid, local_port_conf.rxmode.offloads, >> diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c >> index 1839ac7..b878a48 100644 >> --- a/examples/ipsec-secgw/sa.c >> +++ b/examples/ipsec-secgw/sa.c >> @@ -1790,6 +1790,15 @@ sa_check_offloads(uint16_t port_id, uint64_t *rx_offloads, >> RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) >> && rule->portid == port_id) { >> *tx_offloads |= RTE_ETH_TX_OFFLOAD_SECURITY; >> + >> + /* Checksum offload is not needed for inline protocol as >> + * all processing for Outbound IPSec packets will be >> + * implicitly taken care and for non-IPSec packets, >> + * there is no need of IPv4 Checksum offload. >> + */ >> + if (rule_type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) >> + *tx_offloads |= RTE_ETH_TX_OFFLOAD_IPV4_CKSUM; >> + >> if (rule->mss) >> *tx_offloads |= RTE_ETH_TX_OFFLOAD_TCP_TSO; >> } >> -- >> 2.8.4 >