From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0070.outbound.protection.outlook.com [104.47.42.70]) by dpdk.org (Postfix) with ESMTP id 05CC42B91 for ; Fri, 24 Nov 2017 10:58:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EFXBMGY3bUCTu/OBFfBqKVKiiMoJxeJeUD30dPA2NRU=; b=MJnfwwpBkuNd2QX9Zfk7+mypgi1HcWPdojZfaHeYXLyGYzDFoab22nnS0XSKH3ilWJEk8rABvGuYlLUJGIwtJLy/j+yreI7lYYHKbf6Bxssq7z1InhBOSDQA9DV8B8+fG2sZXc8t6zZIW8Y5Am0UEwGQQfLbJfcv+RCnJClMa5o= Received: from ajoseph.in.caveonetworks.com (14.140.2.178) by SN4PR0701MB3648.namprd07.prod.outlook.com (2603:10b6:803:4d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Fri, 24 Nov 2017 09:58:43 +0000 To: Akhil Goyal , Declan Doherty , Sergio Gonzalez Monroy , Radu Nicolau Cc: Narayana Prasad , Jerin Jacob , dev@dpdk.org References: <1510673823-24475-1-git-send-email-anoob.joseph@caviumnetworks.com> <1510738915-14712-1-git-send-email-anoob.joseph@caviumnetworks.com> <0349861e-de98-92b5-8b6f-7ab944dd45bf@nxp.com> From: Anoob Message-ID: Date: Fri, 24 Nov 2017 15:28:38 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <0349861e-de98-92b5-8b6f-7ab944dd45bf@nxp.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [14.140.2.178] X-ClientProxiedBy: DM5PR07CA0027.namprd07.prod.outlook.com (2603:10b6:3:16::13) To SN4PR0701MB3648.namprd07.prod.outlook.com (2603:10b6:803:4d::14) X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(7168020)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:SN4PR0701MB3648; X-Microsoft-Exchange-Diagnostics: 1; SN4PR0701MB3648; 3:YzYMqGaRuwL23RqzoJsJxz1NL3CDwUDT2QQ2ou1R9a9W7lSE9YroEyFJ4BrKntPE5OX/WNb/hc9xO1SJkww87iWMAGyV+tN+KVOFetCyjysJSbT8P3T+TKFDHrP3tkR0N7+7lsOnJJWzp7PuxqBVgJ96rP1WmIgxo0sgbGsnIdJE4K5yfGYKuA8w+R6NS9sUHEGKfnDbuTdMbGvmo82Iz3rvccPsV0BUpq5orQAZ14qeTs+axjSbYx3lOLa2V4YF; 25:aYZfAuXg571Wm6MuURLO82uHNJFmjVFTV1y61Zq0HB/l+xVwDkpWfiTF/J7CYlRzCZECIzKMEYArNqXxVM8NiVtOBhzjGE50Tlb0zGgWN5vIU5o2sW8GhJ7gKNF04KnB+Ehn3ulaY8xMWT4MIt4LRpdSUVnfGdhFNAetf4+tsEjBA8PAn9tLRkkRO2zlBsFnaRXrofor39ycetHnnbCY0mY9FGgy79JWKEf5LVAm+0Iy6HHIYldcrdgR1/OtYLNisIqcZJ12VV+KOG97Q6sBiQrcV5SL1TJpyEaRT3X+7d5e6QGmEgFMDp0WDJC+Nd+bGj0yMpuuI3sRCofVdKlc4A==; 31:CoxyEScGLuktQIj5iOJ+gXwbPW6duJB00q7HjCL3MsRum1jmFPb9uZDlfXb+j405QVBLtdawJgHuV34t1mlHcXI2qJtibaJE/fC2t0jcnJIFMACsrhWo64O0040sfBU86klTfL7MzXWEFH0lzKMJ26HFAVjZ2YYnX6GWSSgXYOqXvLHv6sBmkIdFwrz0lGBNTcflfFpEuS81VCHDk9WK7umfzMOPHT36EvQKJaZaEpc= X-MS-TrafficTypeDiagnostic: SN4PR0701MB3648: X-MS-Office365-Filtering-Correlation-Id: 290e8285-842a-4ad5-cab3-08d53321f3c3 X-Microsoft-Exchange-Diagnostics: 1; SN4PR0701MB3648; 20:b3vZ+S6sO3YIsYz0PggqtoxqevO0+8VYhUJ9xYdncpft4ULJfLbO6DfiLxjYqrsfjwmzOeZGWxQPJHE6kS3KJnuI9ROWnAimd+72xTa+EGYJ/SNs9ohcu4nskLJalNntoHzVT/bbKC7SFP1M8Sw7X5W4OLtIjDRSyyn8AYQciZ2Pa7djYfDtr5YAzbaeMQ767yvKOfN6LYUEwNR/ssWeBv2K56pfiwSju/XNhdm9epHlqENwNlhOzL1jyojxSWU7eQ31XPmpKaWi7ggxB6KqCTXx7ym0PwwrNuvv3RjYRLmbz896UWdBcsqX9AV+rLFz1YTlBd9yP8qmCkkiBkL+UYpXR3a9opUJNYQbPoSFwsjiqNuaDP7r/Gvzl+6Bgfr+6EQDbP2VvlRkHIiGRI2zygOZFjhUSn+4X0vchuVFlA1nEncLTrk1jypc+UB2wmCMulYk371EnbQ4XyevenQncoAekVM4ZITR8bzSKOczM/FzcME//E1hreypJ7kt2fqRodN9DhRTiz0KQ+0qoEQT0RYFJNfLO3nYbTKbCRkdIRUUOYFLTvdKeMa/yAgaHQ4AL1nYKW7abduAQSXuqG6ChZKv/F5r+HprKiyrh0tc2EU=; 4:r6V/8kdSDsMxXyPtHUOovGWVpjnrZuUzd9aaenRQGxYoVUwnUHuJo9DyMfjDv1oH/i34tPa992xQK5QxxKC27srrwILok8r+Ky/b3aRwPgB3GW76/uPCprmAIUv4+cioDS0rPtfUsog8weLeTAFLFOOyLK38hrZIB9wH5G2b4QMCqY81IOrBZiwULfef58D4xPy/8JQdaR+tjvyvMEEbWq1NfhOFvZZvXUqWMCHOE0ffJd+f+hU0REZTJFmwGplJtUD0RnLGecljA7PFl7u9u0hy08Jk2Bo+wU6xygPudL70zCZnkD8BRE9Z1CEHdjjR X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(10201501046)(3002001)(3231022)(6041248)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123558100)(6072148)(201708071742011); SRVR:SN4PR0701MB3648; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN4PR0701MB3648; X-Forefront-PRVS: 05015EB482 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(366004)(346002)(376002)(24454002)(199003)(189002)(16526018)(7736002)(6506006)(305945005)(67846002)(6246003)(229853002)(50986999)(65826007)(54356999)(5660300001)(76176999)(6486002)(189998001)(52116002)(101416001)(106356001)(55236003)(316002)(31686004)(52146003)(6512007)(105586002)(58126008)(83506002)(23676004)(33646002)(53546010)(66066001)(65806001)(65956001)(64126003)(97736004)(54906003)(110136005)(53936002)(25786009)(31696002)(81156014)(6116002)(3846002)(50466002)(478600001)(36756003)(2950100002)(2906002)(8656006)(72206003)(8936002)(2486003)(6666003)(68736007)(42882006)(8676002)(5009440100003)(2870700001)(4326008)(81166006)(47776003)(110426004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN4PR0701MB3648; H:ajoseph.in.caveonetworks.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Anoob.Joseph@cavium.com; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjRQUjA3MDFNQjM2NDg7MjM6TisyOWRTL2lJd2NUNFdGTzRKTGIrdU10?= =?utf-8?B?ZVVzV0VPS25mWXdGUnZidGxMNkYzZCtYVXJWN2crZzdPQlBad3VlbWhKd2t0?= =?utf-8?B?ZUJQMjRRVExoWVFCY0FwQnk5YTc1VE1lSFc0N3RvMjFIaHVoVENkT2phVEVt?= =?utf-8?B?b2o4U2MrZ1phUmFUUjM3endXbFl0akF6U0tWd0FNKy9xWXNLajJxaDJWdW9V?= =?utf-8?B?S0JHaUI2WEY0YmRkNXdad28zczJZK0REaXg5cDdaY0pvSitBTXlYL1hoalRi?= =?utf-8?B?QXBqU2JjdE9TeWZCdTJUVnFRNmg2RE1NMXBrdDluVUtTN3BIbk0xd1paTUt1?= =?utf-8?B?MXdONk4zUW5QQXlLMzlZZS9Fc2tWTnppeElSS3EyNTV3V2VWTVRUQjhPbElw?= =?utf-8?B?MDlZdVV4TzhiOTVEMnIxM3RsSnp6NWlFdmpIWWd1aCtOSk5ObHlucll4UWk3?= =?utf-8?B?aDRSMG9DSlZtaGxKQ1NkM2NaVmsvdFZieWFscG4vU2Z6Z3RVaklLQmFXUkdS?= =?utf-8?B?NnZGYVpVZ2l2WnpQRWxvd3kxbG1ucFJoeHVPakk3MGJ6QzlXZ3ZTaEVzWmlt?= =?utf-8?B?aFB4KzNEcWZMR3VMRG5GTUpBdnoyc2t5L2xnZEZza3grcFMraVVXY2hvU2NZ?= =?utf-8?B?Vlk5OVRMTzl0VWVucVpsZDJZckUzcitGVHY1UHFwU0NwR2JrNWl1S2EwMFBF?= =?utf-8?B?cGtaYzZWNHFXRDVzUVNLZlJSUVEzZHBtRlpTSHpRTEs5NVQvby9jUURkck1Q?= =?utf-8?B?WklLaW9INkNIMkpjN3BtNE9obnVJbW16YUc2M29COXZFbUh6bldqYlZMdWJY?= =?utf-8?B?WVlQSERBTUp1bXQ0ZGllZ0FtT2Z4dEhYYzc3cy9DODJrZXZGVDdpb2JZS04x?= =?utf-8?B?Y05ObWx0Y09LWkdvd2s1U0dhZFp2QURhT0NIOFliYStmRVRZVkJiRVFEWGRp?= =?utf-8?B?ZXFxYUo3TW1OditWRWRTcUNoSVo3b1czcXhiV28xWEwxdkhGVmZsclRhQmF1?= =?utf-8?B?M2ZqdzJXa3I0YXZRNGFBSU95czYxR2taZ1g1RHJ6OXljd2JOa1hRdkQwRmVG?= =?utf-8?B?RFAvR25sc0dNbTBBWVhsb25pVUJ2bXl2TUlZWnVZTXZ4K05SRHgyVUZmb01H?= =?utf-8?B?eWV0SXQ1b25vaGE3THlES216S1BMajlPUkp2cmpNdGl0T0dwK04xYkU3SFox?= =?utf-8?B?RjFhTHVWNUNTTEdjeTZUcHM4akszL0owa0FFSFFqRnV3VDJjRjlVZmt1eUxX?= =?utf-8?B?YzBva3VkWDVSYVRwM1g0SktuR3J5T1hZZEhDS0ZYU0dtN2V6aFowYWxHU1BK?= =?utf-8?B?U2JaLzh0NStvbHZlM25XRHhybWxYRnhoTzdmSWtLSEpnL080S0gySndiTCtT?= =?utf-8?B?VUQ0OE9ENUhsT3BlNTlMZ09kNTZRVjhsQmpEWXB1eDZCT2VGMk1BSTJkQ25i?= =?utf-8?B?SlJ5eWEyMko3dCtKZGV4WDYzeDh3b2ovSlE3bkYyOXc0Mi8yeUlDaHFVY0t5?= =?utf-8?B?clZWbXhML0NLb2t3aTF6L1hGN3RaQzNOUDVrNXdPTjlpazF5YU5SaE8vVTEz?= =?utf-8?B?bWorUXRoWHU0eDB6MFdnWE9wVFN6MjcvY21HN2VnUDJSYjV1SmtBd055Q1FF?= =?utf-8?B?YU9adlhmczdXaitkK0RIVkFLL0tlbXZJTml2cVZENnNlKzBkZUIwblpUQzdy?= =?utf-8?B?Ri9MSWpJZWJIaHlDbGRvR0J6QjFrVHBGY1dpY3NrcGpjQlVmYlA3Y2d5cDNK?= =?utf-8?B?SG92V2pVWlVXRGF3ZDRla0RXd21MZVpqNVRZMUd4QXBpUXFZVHpGT0JYOHpV?= =?utf-8?B?Z1F3RWNjSCt1V3VmYWVaMnhvTUYyeGZOb2pKV2MyQnFEM0ZEQ2lnV1o4aVdK?= =?utf-8?B?K1VOejRJT21DdGNzZW9XMUZCWFhhNTFWa3hZR1V1eXhPUk8vYlNKemNGT1JE?= =?utf-8?B?Y2EzcXRYcXNyVUpJODJBQ0VjMkhLUGlQTUJocDlqM1ZpMkgwTnIzUVQ3dGJx?= =?utf-8?B?YUFUZE1xSXFmak9BY25RaTlraFdvdVU3WEZQdGdBSEh1UEpRVTloMnZ2a2Uv?= =?utf-8?Q?1WL/GhH7qZgw7L97Uf2tOW5l0o3?= X-Microsoft-Exchange-Diagnostics: 1; SN4PR0701MB3648; 6:DLAmwdGc4yCnL2aiz8DHb4XAW433ZwTVXi014EnYMEop0L2Vzzuw4HrU9C70AZ9tOWtxGFNaZ8Sr0+yBCQ9r57PfFrFzt0MopqjBnLyimX2f90t0JqoUwYfiihlsVpWUhoTm6meb0xR8zGhOUQ9oYSxGrs7PH1ZGBSjx6VNLUU7U25uwOEOxd8U4zicEdBH5kMyvztXvhyHRhNoZUCKveKgxX0G13gOqJYgtKiXtcXJiEfARXa/uyITcPYsB6S/5blxXBC62X8X/GWKaEtee8q514cg8q0iC+RknHfvzPLb7Kq8SROFlB9ekwiPpKQiLB9JQdLH3FEKkobt17EMYDcG7wgZ7FOQv+qsY6m51plo=; 5:28Qn2Y6Cyda8Q9BGaigQ1BjnzONXimsNBE/74qIjQQACI+unNwBje2PhCUyEYC+dkWz726lzTfsl371YTds7A8J7stMC4SXt+MCdIXCFSFAcHs9YsziiQso4IRQg4q0QHsiekACHVDxDN/FDJVVrGaUY7NqjHwG/GoyqFinZXl8=; 24:F8WmCMNe0x7jvX1visRhzhiVskg+fY82nh+GLYoVkxav+tRRejQEt4IS2Pij9UlWJOb/lU1NKZNU4VaPJzpUv/qn7LPal8Tf9Ijvwkb4zJc=; 7:1cH5ww+q7LhemEHfTzBLFTTayOzIvCppXDM93lZB64/KYnKZWG4BNVnI0NOdX6fsMXlpJOo8YsbxqqysmpJo3ds2uVdk814vukG9mxHwftkc8mSdIYi9IcLnNW0BvDvNo0j6101TpQaZLg7o+A/yUBAHYcwzMVIh207aJsSur/icf+Kco+wo6C79To4dqO1l5hY+MrF4tgW3edAtTh6hmx5BDPqX4DTMU0kLjlHdPHHkuiPiDZv5arBwr6F0ZLD+ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2017 09:58:43.3487 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 290e8285-842a-4ad5-cab3-08d53321f3c3 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR0701MB3648 Subject: Re: [dpdk-dev] [PATCH v3] examples/ipsec-secgw: fix usage of incorrect port X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 09:58:49 -0000 Hi Akhil, Please see inline. Thanks, Anoob On 11/24/2017 02:58 PM, Akhil Goyal wrote: > Hi Anoob, > > On 11/15/2017 3:11 PM, Anoob Joseph wrote: >> When security offload is enabled, the packet should be forwarded on the >> port configured in the SA. Security session will be configured on that >> port only, and sending the packet on other ports could result in >> unencrypted packets being sent out. >> >> This would have performance improvements too, as the per packet LPM >> lookup would be avoided for IPsec packets, in inline mode. >> >> Fixes: ec17993a145a ("examples/ipsec-secgw: support security offload") >> >> Signed-off-by: Anoob Joseph >> --- >> v3 >> * Bug fix (fixed a wrong if condition) >> * Minor changes in documentation >> >> v2: >> * Updated documentation with the change in behavior for outbound inline >>    offloaded packets. >> >>   doc/guides/sample_app_ug/ipsec_secgw.rst | 10 +++- >>   examples/ipsec-secgw/ipsec-secgw.c       | 92 >> +++++++++++++++++++++++++++----- >>   2 files changed, 87 insertions(+), 15 deletions(-) >> >> diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst >> b/doc/guides/sample_app_ug/ipsec_secgw.rst >> index d6cfdbf..ae18acd 100644 >> --- a/doc/guides/sample_app_ug/ipsec_secgw.rst >> +++ b/doc/guides/sample_app_ug/ipsec_secgw.rst >> @@ -61,6 +61,12 @@ In case of complete protocol offload, the >> processing of headers(ESP and outer >>   IP header) is done by the hardware and the application does not >> need to >>   add/remove them during outbound/inbound processing. >>   +For inline offloaded outbound traffic, the application will not do >> the LPM >> +lookup for routing, as the port on which the packet has to be >> forwarded will be >> +part of the SA. Security parameters will be configured on that port >> only, and >> +sending the packet on other ports could result in unencrypted >> packets being >> +sent out. >> + >>   The Path for IPsec Inbound traffic is: >>     *  Read packets from the port. >> @@ -543,7 +549,9 @@ where each options means: >>    ```` >>      * Port/device ID of the ethernet/crypto accelerator for which >> the SA is >> -   configured. This option is used when *type* is NOT *no-offload* >> +   configured. For *inline-crypto-offload* and >> *inline-protocol-offload*, this >> +   port will be used for routing. The routing table will not be >> referred in >> +   this case. >>      * Optional: No, if *type* is not *no-offload* >>   diff --git a/examples/ipsec-secgw/ipsec-secgw.c >> b/examples/ipsec-secgw/ipsec-secgw.c >> index c98454a..cfcb9d5 100644 >> --- a/examples/ipsec-secgw/ipsec-secgw.c >> +++ b/examples/ipsec-secgw/ipsec-secgw.c >> @@ -585,31 +585,72 @@ process_pkts_outbound_nosp(struct ipsec_ctx >> *ipsec_ctx, >>           traffic->ip6.num = nb_pkts_out; >>   } >>   +static inline int32_t >> +get_hop_for_offload_pkt(struct rte_mbuf *pkt) >> +{ >> +    struct ipsec_mbuf_metadata *priv; >> +    struct ipsec_sa *sa; >> + >> +    priv = get_priv(pkt); >> + >> +    sa = priv->sa; >> +    if (unlikely(sa == NULL)) { >> +        RTE_LOG(ERR, IPSEC, "SA not saved in private data\n"); >> +        return -1; >> +    } >> + >> +    return sa->portid; >> +} >> + >>   static inline void >>   route4_pkts(struct rt_ctx *rt_ctx, struct rte_mbuf *pkts[], uint8_t >> nb_pkts) >>   { >>       uint32_t hop[MAX_PKT_BURST * 2]; >>       uint32_t dst_ip[MAX_PKT_BURST * 2]; >> +    int32_t pkt_hop = 0; >>       uint16_t i, offset; >> +    uint16_t lpm_pkts = 0; >>         if (nb_pkts == 0) >>           return; >>   +    /* Need to do an LPM lookup for non-offload packets. Offload >> packets >> +     * will have port ID in the SA >> +     */ >> + >>       for (i = 0; i < nb_pkts; i++) { >> -        offset = offsetof(struct ip, ip_dst); >> -        dst_ip[i] = *rte_pktmbuf_mtod_offset(pkts[i], >> -                uint32_t *, offset); >> -        dst_ip[i] = rte_be_to_cpu_32(dst_ip[i]); >> +        if (!(pkts[i]->ol_flags & PKT_TX_SEC_OFFLOAD)) { >> +            /* Security offload not enabled. So an LPM lookup is >> +             * required to get the hop >> +             */ >> +            offset = offsetof(struct ip, ip_dst); >> +            dst_ip[lpm_pkts] = *rte_pktmbuf_mtod_offset(pkts[i], >> +                    uint32_t *, offset); >> +            dst_ip[lpm_pkts] = rte_be_to_cpu_32(dst_ip[lpm_pkts]); >> +            lpm_pkts++; >> +        } >>       } >>   -    rte_lpm_lookup_bulk((struct rte_lpm *)rt_ctx, dst_ip, hop, >> nb_pkts); >> +    rte_lpm_lookup_bulk((struct rte_lpm *)rt_ctx, dst_ip, hop, >> lpm_pkts); >> + >> +    lpm_pkts = 0; >>         for (i = 0; i < nb_pkts; i++) { >> -        if ((hop[i] & RTE_LPM_LOOKUP_SUCCESS) == 0) { >> +        if (pkts[i]->ol_flags & PKT_TX_SEC_OFFLOAD) { >> +            /* Read hop from the SA */ >> +            pkt_hop = get_hop_for_offload_pkt(pkts[i]); >> +        } else { >> +            /* Need to use hop returned by lookup */ >> +            pkt_hop = hop[lpm_pkts++]; >> +            if ((pkt_hop & RTE_LPM_LOOKUP_SUCCESS) == 0) >> +                pkt_hop = -1; >> +        } >> + > I believe the following check is redundant for non inline case. I > believe get_hop_for_offload_pkt can also set the > RTE_LPM_LOOKUP_SUCCESS if route is success and take the (pkt_hop & > RTE_LPM_LOOKUP_SUCCESS) == 0 check outside the if else block and free > the packet if it is unsuccessful. > > Same comment for route6_pkts. Checking with -1 may not be a good idea > if we have a flag available for the same. > Others can comment. The problem is ipv4 & ipv6 LPM lookups return different error values, but we are using a single routine to get the hop for offload packets. The flag(RTE_LPM_LOOKUP_SUCCESS) is only for ipv4 lookups. For ipv6, error is -1. If we need a cleaner solution, we can have ipv4 & ipv6 variants of "get_hop_for_offload_pkt". But that would be repetition of some code. > >> +        if (pkt_hop == -1) { >>               rte_pktmbuf_free(pkts[i]); >>               continue; >>           } >> -        send_single_packet(pkts[i], hop[i] & 0xff); >> +        send_single_packet(pkts[i], pkt_hop & 0xff); >>       } >>   } >>   @@ -619,26 +660,49 @@ route6_pkts(struct rt_ctx *rt_ctx, struct >> rte_mbuf *pkts[], uint8_t nb_pkts) >>       int32_t hop[MAX_PKT_BURST * 2]; >>       uint8_t dst_ip[MAX_PKT_BURST * 2][16]; >>       uint8_t *ip6_dst; >> +    int32_t pkt_hop = 0; >>       uint16_t i, offset; >> +    uint16_t lpm_pkts = 0; >>         if (nb_pkts == 0) >>           return; >>   +    /* Need to do an LPM lookup for non-offload packets. Offload >> packets >> +     * will have port ID in the SA >> +     */ >> + >>       for (i = 0; i < nb_pkts; i++) { >> -        offset = offsetof(struct ip6_hdr, ip6_dst); >> -        ip6_dst = rte_pktmbuf_mtod_offset(pkts[i], uint8_t *, offset); >> -        memcpy(&dst_ip[i][0], ip6_dst, 16); >> +        if (!(pkts[i]->ol_flags & PKT_TX_SEC_OFFLOAD)) { >> +            /* Security offload not enabled. So an LPM lookup is >> +             * required to get the hop >> +             */ >> +            offset = offsetof(struct ip6_hdr, ip6_dst); >> +            ip6_dst = rte_pktmbuf_mtod_offset(pkts[i], uint8_t *, >> +                    offset); >> +            memcpy(&dst_ip[lpm_pkts][0], ip6_dst, 16); >> +            lpm_pkts++; >> +        } >>       } >>   -    rte_lpm6_lookup_bulk_func((struct rte_lpm6 *)rt_ctx, dst_ip, >> -            hop, nb_pkts); >> +    rte_lpm6_lookup_bulk_func((struct rte_lpm6 *)rt_ctx, dst_ip, hop, >> +            lpm_pkts); >> + >> +    lpm_pkts = 0; >>         for (i = 0; i < nb_pkts; i++) { >> -        if (hop[i] == -1) { >> +        if (pkts[i]->ol_flags & PKT_TX_SEC_OFFLOAD) { >> +            /* Read hop from the SA */ >> +            pkt_hop = get_hop_for_offload_pkt(pkts[i]); >> +        } else { >> +            /* Need to use hop returned by lookup */ >> +            pkt_hop = hop[lpm_pkts++]; >> +        } >> + >> +        if (pkt_hop == -1) { >>               rte_pktmbuf_free(pkts[i]); >>               continue; >>           } >> -        send_single_packet(pkts[i], hop[i] & 0xff); >> +        send_single_packet(pkts[i], pkt_hop & 0xff); >>       } >>   } >> >