From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0089.outbound.protection.outlook.com [104.47.32.89]) by dpdk.org (Postfix) with ESMTP id DD0CC237 for ; Mon, 11 Dec 2017 11:38:25 +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=tAH2SZFsEPILfQpGYjpxrYC9dFpDlN+sOOU0Bu5wAxQ=; b=Ccok6R6/OhA5OG5+hwc933PmUzTZGsd3En/aTOmysNl/0jk45up1V8gvaNIpjGr2US3rQlR+Pz1m9NwwNCcb9hoe1HxN3m3BdrhKr8X6yrgNRlNCVTEHFjfnYEdqZ7r3/LoUE9bDheE+WuyGk0fbOfe35IlvJS9RiYLCWbQc7HY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Anoob.Joseph@cavium.com; Received: from hyd1ajoseph-dt.caveonetworks.com (115.113.156.2) by SN4PR0701MB3647.namprd07.prod.outlook.com (2603:10b6:803:4d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Mon, 11 Dec 2017 10:38:21 +0000 Cc: anoob.joseph@caviumnetworks.com, Narayana Prasad , Jerin Jacob , dev@dpdk.org To: Radu Nicolau , Akhil Goyal , Declan Doherty , Sergio Gonzalez Monroy , Bruce Richardson 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> <5d0bed52-ad0e-df65-158e-4e62b79fe754@nxp.com> <19976ae6-23db-9d35-4fa1-894317bd998a@caviumnetworks.com> <5e4c92fd-1fa1-648c-0c9e-b6b282c232e7@intel.com> From: Anoob Joseph Message-ID: <1293e784-b4e5-23a5-caca-63cdaac22e5a@caviumnetworks.com> Date: Mon, 11 Dec 2017 16:08:13 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5e4c92fd-1fa1-648c-0c9e-b6b282c232e7@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [115.113.156.2] X-ClientProxiedBy: DM5PR21CA0002.namprd21.prod.outlook.com (2603:10b6:3:ac::12) To SN4PR0701MB3647.namprd07.prod.outlook.com (2603:10b6:803:4d::13) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8610c5b4-ce43-4411-dfc5-08d540834e63 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(7168020)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:SN4PR0701MB3647; X-Microsoft-Exchange-Diagnostics: 1; SN4PR0701MB3647; 3:ZuoCqg1M4JEtmlGycuzzOfTWi7EPHB1urOMYINN0wqgVD+rBI/5SBk8hJT3K0qA2qz1btVflHBdKIgrsjh4V8gWW+tei7UA7MuYyGeycFl+DS1+so/Acz3arzSU7vYTR1Z/tX23g0ZmG/TjS7B0B2vkv8Uh+YG68JXZlNAhzNyXYiC7nKb2KsywwU4U6zgqb/hYliec1Jhjy6zn7MmKKD7kh+OeP5QJiTx3L+4iQ/M/XhMw6U9wfY9A3J30IOg/y; 25:fn9xB4e2CBv/0xWIs83WW+0HCCa4q2GtB4EzVb+1FETREBk5uxI78f3koIILkgqy5o3vY8r41cHDadVm3o1BgPJWiViHRielO3qCSAAg0fVD3P4h+MjnvyC73MuAPdrNeLWl1lUK4NQWFEi0WXT5jnvng9Vi+k49IrjG8NnMM4JrbK05W1aK6GTb3hbiJlDCK8dRfs+a/JM0FzLRWtMP9Vdqab7dg0ep4UztWKQ1g0M9pDfXjEs3biRE+1oT5pKZzmD5vSDdwKcNk9ix9aJR4A/dQ608EKw6oMfnEAlkAaq/ac9SzN0iQw4Em/hE/AmhE/DqOshMAdshfNq8WfrkwxztkhWPkUs207KFnu/QrpE=; 31:anF1y01ls8YVpsX4wYkQfjL/N9fX/mwydiFbyZLrd7I7VMUaPoOwsmwt5f0WVSJGuxY8iu4jANt1X18umaqdxUm2TJKuJkikF9NkgFgprRG0Hq42FF/d7eQfgKwIUivgRY1CostghKlery0v67TBnjvSDps58EB85M9HnMRJy1qItNt09nEk4Sx4BWGi5RkC6SAUT/FllUm6EK+/Vk2Iw4ce7Iay1IjE8JMZ7odCy18= X-MS-TrafficTypeDiagnostic: SN4PR0701MB3647: X-Microsoft-Exchange-Diagnostics: 1; SN4PR0701MB3647; 20:YGluR24PfEvEhnSttmxV44MsuoKULETdOGRwA/WbrnUCDkXt4U0aYM2/Fk5Oj82QVLkgKKFxgtMRocNblEvpYQKmnSepmc3wWcCcP9zmDyZ3dp9x742TALg2FOo+zw4i+g96Nx2XDXs3sc2sB0FDDNLyLfiFPT3QJ66qUL6OJQjD8RuuAeD6nPGGXSQBWrXczP+6RFJn9xeBXlwq+134/E4gvKx3Ou28bS9EncMBqFY9WHA0HaZEjL2eWw1q29omQL5E1QWHDKNYlEmwYTpNmSGTm57VnNw9gqhNTu3bit/FfP7xn9zbuRgsfVV9mi7NF7JSHQG61xyhjSWbpc0b6+Vd/sX4cnOkPFXyDOv9D18bimEKgcOpWsfETjOJSBL44gEFjdsOYqgOQABqpSWcx9+I3NaeSXFlT+wP/zv9FnP6dVCYk2fs3vZ3erlnMT1fpnDabsEIsx76m+x+2c0KDLzkT8F3fAvSc5dBvDltNXSk6VSVkHw5Mh2/yuMdkMA9tm1MykSh329/WKVzqqq4hKZrLLACsgwr0hT5+7gnvWHsNRGblJbeDuaFLvE5HK3WhVlDLj4r9NYva60ebzS2H1wzUP9RDvI+OymxFV0ZDx4=; 4:wsNjrpgWQEqfHY4TvBVMT2/LkkYEU+swOM+HFdDKPhH33gWPa4Llij+SOSSpA9S+EOlJ0CrCb2FeaPsAYI4SF21lG702nqPS7W7uYfyJftrJBcxCf9CWCBDvX8YDq4Zy70X1sBmGUxaTkpHgWkC+akvp3AVSBH5PNOtd77jXf21aQ8E5caj32flvU3vt1QIF7S1dBZTUx4yCTcBCGN6EZxZdRjtQbLZAdP8oeyNzjrW3oOTzFMTPFdAISwHYOK37sPDRWxSTHX8SI86Epwi6aV94GQF/6IOIUTw7myNgFxNhHKBcSDOpmoLuxzbABY96 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(3231022)(3002001)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011); SRVR:SN4PR0701MB3647; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN4PR0701MB3647; X-Forefront-PRVS: 0518EEFB48 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(24454002)(52164004)(377424004)(199004)(189003)(25786009)(33646002)(52146003)(2486003)(105586002)(52116002)(67846002)(316002)(83506002)(64126003)(53546010)(23676004)(76176011)(6116002)(8676002)(4326008)(8936002)(31696002)(53416004)(81166006)(81156014)(3846002)(16526018)(69596002)(72206003)(106356001)(97736004)(54906003)(110136005)(229853002)(58126008)(6486002)(31686004)(6506006)(2950100002)(42882006)(53936002)(2870700001)(65826007)(305945005)(7736002)(59450400001)(68736007)(6666003)(478600001)(66066001)(65956001)(65806001)(47776003)(55236003)(36756003)(5660300001)(2906002)(8656006)(93886005)(6512007)(6246003)(50466002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN4PR0701MB3647; H:hyd1ajoseph-dt.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) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjRQUjA3MDFNQjM2NDc7MjM6RGY2YmlROVBDZHpYOW9SZnl2aVZhOFls?= =?utf-8?B?T2Z0bzhyTXc4bVJ5eXZUUksvV0d4OEF0WGxtTlVrS0RJMCtjb2lUR3MrN3Z1?= =?utf-8?B?NmxZMGFhZDRzNmRYbGpYSkFsaTVjY08rekZBZGVQUm9PN0pia1hVZEd2V1dE?= =?utf-8?B?WGhvQ3dveHEySVpRMThxR1RhTUVwQmNuOTRMUE9wVGYzcHVwMk9oUmduVFBt?= =?utf-8?B?VTUzYU9GdEk4Tnl1ZkV1a2xlV2xObnNzZ1hMcmF5SkliWDN3VDRtV1Q3S29z?= =?utf-8?B?VGpoNnkxelJmaXVCZmVERzhIL1VXM3dOOWtjWFU4a0tjQmthZTQrQk1ReXNN?= =?utf-8?B?NHdyUUlUWG1sZDhyRmdKdDB6T3c4QVV2NDVlZ1JFRi9ncjlZcVVWamYwMXBk?= =?utf-8?B?Z0VRSUc1akgydFpaNjJGbFpWNmFlVTFyQ1JhWmlIVU4xd2xUU3BVMTlLRGlG?= =?utf-8?B?bmJxVFRaZFFVdnhzRVVLakJLdmtSZ1pzMFRGNkFoZ0RSUnZDcm5SZlRIVS95?= =?utf-8?B?UmhaWVRrSHlIVXRjWVl5aW9nR1hCVGNPdG00bTNSVE9Nc2YrSTlrblU3eUQ0?= =?utf-8?B?aXFVSFk3TUJDKzhsL3UzY0l3VVhhU2J3U20vQS8wRmpHa1MyRXJNVnFFWUU3?= =?utf-8?B?S0IxYnlLUmJvOGY4T3FYUDkwSFllaVpmUzNnZTM1RWlOaC9ONmhJL2tHc1A0?= =?utf-8?B?UVRFRDRUekpwYXl0clVRUjI2K3JMNXFxMG51c25EbGsxdnZybkovbEovQldI?= =?utf-8?B?Tngxc0JXQ2ZrNFp6K2RHd1B6akcxOWd0UVpZSkliU0l0WnlCcnYyZzFwRy9v?= =?utf-8?B?Y3NIMEcvemY4cFRRN1VEN1JubVBmTFE5N0F2RUtldnJZRTY4N09XUGVlYVFZ?= =?utf-8?B?L244SnlncC9HcHd0OU12d3plNElVWG1JSzhUMDhmT0pYRkpMaXF3R1NhZTQv?= =?utf-8?B?RnlkU1paR1ViWUlMazRCTGlRaGh5Zy9ST29YNnpWK3ZqaktKM3B0Z1ptR2xO?= =?utf-8?B?WUkxZVZlOWRFSGx5cXhEdVRuTW1rME5QU3JFMEpXMkZMSFNMMmpGVzQxV1FV?= =?utf-8?B?YmV5Y3JLVkk3WDRhOUE3OHFlM1BmQTRjMVZFeFJoeE1aU0lrUkx1WEMwTFhh?= =?utf-8?B?SUg3WDZpeHZWbUtWNmpOUUVueDdIRml1ZFQzNXlwbmtvTEFsL29CTVlGcGpJ?= =?utf-8?B?RjZwcGJ6Q2VBZWZubTZYN1NNMTg1RUE4bFpXSXJ3TnA3bzhzOWQ3ZXFHQW91?= =?utf-8?B?aWNVd2VBb3VHdVM2eW40NHhKMGRGNGUrbWNpaHV5azVUM1B5TmlHZWwyS3U3?= =?utf-8?B?MHdaT3dRMDh2L01OTVNMV09qQyswUC9hdUNwUkFsU1dBL2RIWVk3MjJFWmJk?= =?utf-8?B?c0ZiM1hEMEpnU1FadXQ1NHAvUWp6Sk5aVk5UY2lOSTl1RHVzSmZEa1h6ejBP?= =?utf-8?B?UHJkbzJGOWllVjhvek5EV0U0NlBHQUY3Zk4zUGlwZDYvd09hZFJNVzR5c3g4?= =?utf-8?B?Tk9kQjdRR1hBZzhGSkRRakU4Y1FQQjMyaFp5di9oV21CUHFKSlBjR3lHZlhJ?= =?utf-8?B?TjNjZXRNYkhjU0ROMlpBNUhSclFhZkNxcXovdTRhMkl5VEpFY0huK2FuYU9E?= =?utf-8?B?T1l4Wm13U2RqUVkva1dWL2ZYL0luakhtRmYvMmg5cm5mTzRTclpjcjRzUVFi?= =?utf-8?B?SzNtTlZHS2hWWGtrd0JDTkNYbC9lZi8zdC9jTDZiL0Z4RTY3Qk1xd25kbm03?= =?utf-8?B?U3JhRXpQbkorVTVCL01hckRwSVRad0Jidit5VEo4YnhYZVFOZlRBUlA4YWJv?= =?utf-8?B?RW9UeURWN1FBdWJpQkRQOVhaZWNpTFFPbEZDdG5CbkptNjN1SjQ4NzBjTkpT?= =?utf-8?B?NW5wMWhTZjVwb1FsNGMvSmZuY0lESTdnRnJFQUMraEg2QmVRbGl4N1ZtN0FR?= =?utf-8?B?dFJ4QkcxTEM1cTFET2ZPRCtvWmJwYnZ6c1k4UU1UZEx6eDhWL1FrZFFnL2Fi?= =?utf-8?B?YkU3T0pIK3BraWNQQ2xMWXl1RXlXck5ueUtBN3ZDeDFvS2VMUThod1BsQm00?= =?utf-8?Q?t8/GxA=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN4PR0701MB3647; 6:d+rv5z1LaAEeDDHEJfC6xb+wMqds/Lh2IfCSA/4wVT7F0psbSCBGLI9v7Jryzq0TG8NUSCoyDi0siQQVqv893GIawAFDWWDXGZRF6UOlkbbL/Tg/+20VBaWnRpQGpYA11Xec9HxT2aGqtFeawyg/dWPAMJUSZ7Q4y3aevLkDQhrrc+lzR6qYlwr0l9gzBUlA2YVmwqr8+LrzFAA4IlpMIo+FCCbHXae5xdYQJrA09KqojCmhWX2yehtFTq4UOJOUnvAlsmK04RwQqULElpcQWu6lSVXS9NuN9clGVhkgGOMvEqqq+jlg6+W8DWqVCDWnnSoG225IigHnrdinU7ldHPS2cJPej1RE2VH3R7DaMSM=; 5:e3to0K3J8MSnijQA+7mq0V27PsJyx1k3hco5B7mwh2BlM7SmlPDUsJaYgngbwidqr04oB2/qwIhiEnGBkmXGpLM+AnN2kqnL6WcKoFEqA/DZn8G9qk8uayoFmA+zeORWCiDfF3dJg2quEShJ3wJEQRugb3cxqkWkLT7xJUV2VLI=; 24:E9yj5aWes6u92KXHQCWgcPC+2CYpXblHhX12NTKhZLmeXtIfvNMIwirZo0qr6Q0OfYrSBUO1fLmL8KoeUhv4KTO1OhkpmeLWbYTPayDjB4U=; 7:vRhc0uD6ObmzLzI59WgDIqUpZTgyMoYiDJGI0vEtb4/5/WlhdrOzQXQG2koiYZtD74GaJ/lndoT/3rOI5d7oiXEOtutWcmQ1I/5WGoFERJjYk3RDRFvKvces5oTibmSwT325PcWFCK63HZiFMBdMLnIqBS5vC84dWzQqXiTqWz1Xgf6bZJVGzIOkIyAGinvd1xeKMITA2PDAbOv7Zp1VIb2RGSOcrX41VCHIzdWTebVpN/BuJHMnVghLmuoh5og6 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Dec 2017 10:38:21.3949 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8610c5b4-ce43-4411-dfc5-08d540834e63 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR0701MB3647 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: Mon, 11 Dec 2017 10:38:26 -0000 Hi, On 12/11/2017 03:56 PM, Radu Nicolau wrote: > Hi, > > > On 12/6/2017 11:08 AM, Anoob wrote: >> Hi Akhil, >> >> On 12/04/2017 01:19 PM, Akhil Goyal wrote: >>> Hi Anoob, >>> On 11/29/2017 9:51 AM, Anoob Joseph wrote: >>>> Hi Akhil, >>>> >>>> >>>> On 24-11-2017 16:19, Akhil Goyal wrote: >>>>> Hi Anoob, >>>>> >>>>> On 11/24/2017 3:28 PM, Anoob wrote: >>>>>>>>   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. >>>>> >>>>> my concern over this patch is that there is an addition of an >>>>> extra check in the non inline case and we can get rid of that with >>>>> some changes in the code(lib/app). Regarding route6_pkts, the code >>>>> looks cleaner than route4_pkts >>>> If we have ipv4 and ipv6 variants of the >>>> "get_hop_for_offload_packet" function, the code would look much >>>> cleaner. Shall I update the patch with such a change and send v4? >>> >>> I believe we shall get rid of "RTE_LPM_LOOKUP_SUCCESS" from the >>> rte_lpm_lookup_bulk(), we shall have similar error flags for v4 and >>> v6 APIs. Either we can have RTE_LPM_LOOKUP_SUCCESS or -1 as check >>> for errors. >> This will call for an ABI change. And LPM library has multiple >> variants for v4 & v6 lookups. We will need to modify all such >> instances. I've CCed Bruce for his opinion on this matter. If >> maintainers can decide on how to address this properly, I can plan my >> next steps accordingly. > Maybe this alternative approach will help: change the > get_hop_for_offload_packet to return -1 for v6 and clear > RTE_LPM_LOOKUP_SUCCESS flag for v4 errors. This will be on the error > path so the extra code to check the pkt type will have no performance > impact, and the route function can be cleaner and we can lose the > extra if in the v4 one. That should be fine I guess. So the get_hop_for_offload_packet will have one more argument to specify whether it is ipv4 or ipv6, right? I'll revise the patch with this suggestion. >>> Sergio can comment on this. >>> >>> Duplicating code for get_hop_for_offload_packet may not be a good idea. >>> >>> -Akhil >>> >> >