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 D578AA0032; Fri, 18 Feb 2022 15:00:07 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B9FAD40150; Fri, 18 Feb 2022 15:00:07 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by mails.dpdk.org (Postfix) with ESMTP id 9AF2A40141 for ; Fri, 18 Feb 2022 15:00:05 +0100 (CET) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 21IACu7t025799; Fri, 18 Feb 2022 06:00:05 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pfpt0220; bh=lRg8+sHmSJCTrqRp9qulzB8sLsm8nExkJ4WHXVcKBDY=; b=XAWAl3RbfPH4xH1cE7fQzN1FiuaGUx3b6Fga9BIN+WDrNZEX0hGoxw17wbtdo3xGRQxS CGu3/Jx1/io7aylmCxOk7TYqsObrZDcWhPsB5vkliVzXVHnNqXXPuDJ+4/MWTh7KSW5g UgA4RKIHXfDQgSzY//N0OGM9qBHKsBuFoQVq4Z8XrT1O8SFbL52GU5rdLnmPjJ9bMCvD rsVwtqMmfO8Lthbp/2emeYmP2suiVASwmuBERUaZd+WRLPgQFR/WlfIiXj/NlAcBC7js HovRuAh4XmT032/XZd4X+/aCPTWng2kCmHrGAPSbpa/WqefoqXWvNm6z5FTC38GZIVwR LQ== Received: from dc5-exch01.marvell.com ([199.233.59.181]) by mx0b-0016f401.pphosted.com (PPS) with ESMTPS id 3e9kktx669-9 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 18 Feb 2022 06:00:04 -0800 Received: from DC5-EXCH02.marvell.com (10.69.176.39) by DC5-EXCH01.marvell.com (10.69.176.38) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 18 Feb 2022 05:59:02 -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; Fri, 18 Feb 2022 05:59:02 -0800 Received: from [10.28.175.194] (PE-LT1350.marvell.com [10.28.175.194]) by maili.marvell.com (Postfix) with ESMTP id 6F2705B6927; Fri, 18 Feb 2022 05:59:00 -0800 (PST) Message-ID: <01076921-41f5-97a9-9c02-808ac6a91be7@marvell.com> Date: Fri, 18 Feb 2022 19:28:58 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: [PATCH 2/4] examples/ipsec-secgw: disable Tx chksum offload for inline Content-Language: en-US To: "Ananyev, Konstantin" , "dev@dpdk.org" CC: "Nicolau, Radu" , "gakhil@marvell.com" References: <20220206143022.13098-1-ndabilpuram@marvell.com> <20220206143022.13098-2-ndabilpuram@marvell.com> From: Nithin Kumar Dabilpuram In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-ORIG-GUID: gARzSrYI7U8Yesv1-6BFIlZnUjbU9eph X-Proofpoint-GUID: gARzSrYI7U8Yesv1-6BFIlZnUjbU9eph 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-18_05,2022-02-18_01,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/18/22 12:47 AM, 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. > > Ok, but apart from inline modes we also have lookaside modes. > Why to disable ip cksum for them? Ack, I missed that case. I'll make the change to enable Tx checksum offload enabled even for Lookaside crypto. > >> >> > 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. > > As I remember we always recalculate ip cksum if RTE_MBUF_F_TX_IP_CKSUM > is not set: > > static inline void > prepare_tx_pkt(struct rte_mbuf *pkt, uint16_t port, > const struct lcore_conf *qconf) > { > struct ip *ip; > struct rte_ether_hdr *ethhdr; > > ip = rte_pktmbuf_mtod(pkt, struct ip *); > > ethhdr = (struct rte_ether_hdr *) > rte_pktmbuf_prepend(pkt, RTE_ETHER_HDR_LEN); > > if (ip->ip_v == IPVERSION) { > pkt->ol_flags |= qconf->outbound.ipv4_offloads; > pkt->l3_len = sizeof(struct ip); > pkt->l2_len = RTE_ETHER_HDR_LEN; > > ip->ip_sum = 0; > > /* calculate IPv4 cksum in SW */ > if ((pkt->ol_flags & RTE_MBUF_F_TX_IP_CKSUM) == 0) > ip->ip_sum = rte_ipv4_cksum((struct rte_ipv4_hdr *)ip); > > ... > I'm working on another series to restructure fast path based on different mode. As part of that, I think we can avoid checksum recalculation in cases of inline protocol offload. >> >> 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 >>>