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 F29D1A034F; Wed, 11 Aug 2021 12:31:50 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ADC6340042; Wed, 11 Aug 2021 12:31:50 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id 566D040040 for ; Wed, 11 Aug 2021 12:31:48 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10072"; a="215086837" X-IronPort-AV: E=Sophos;i="5.84,311,1620716400"; d="scan'208";a="215086837" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Aug 2021 03:31:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,311,1620716400"; d="scan'208";a="460702427" Received: from fmsmsx605.amr.corp.intel.com ([10.18.126.85]) by orsmga007.jf.intel.com with ESMTP; 11 Aug 2021 03:31:46 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Wed, 11 Aug 2021 03:31:46 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Wed, 11 Aug 2021 03:31:46 -0700 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10 via Frontend Transport; Wed, 11 Aug 2021 03:31:46 -0700 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.101) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.10; Wed, 11 Aug 2021 03:31:45 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CNnXPdozyq+HRxT+iUVBfieGuVeSRP8VHjj79dfQWE86X5HW7lnI5nyeQTnUK2RzT5s/yJobjx8wKTavHYGkTq1Msuxdg8PB8YuaBoVCqSk9MXP/TZeH8TRe3GXlaX6pmV+yU2eTrYQv1h9EQuCoGDOBYxtNUDio4ZhBZa2sISY4sNH8Piqf3hqML2UlpROJfD9SXB8mS+jmGfa9yCCA5hfCHMuy1ZXLoGOx/dnWvdMi3fa3IWjHjZ09sbfcwM3J4A1EPGaWDHZ65ag8opP0Q6n1P9NUXxKtsu2XMGLHwi1S6s/pY1RksTD4Sf+9CGpK7eVVGXeoW23qfjrxn0UKQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iEXX9z5VrAd7nspVcHbahjTTf7grwiAsAqnw2S9I9YU=; b=HVn+VzKo7pmvkbqIuyauJVGJEPVe5nYmr7jKwlqdB7hzGJkxnSIxAZL+6g0oky6/vlFtpgmcNcLD3a3tdfwgQJTyxT0COow4Y+fX90sq9c+3F9NCjWuVtqg6xtMonT0ddb4ocdKyK354K0Kvdu7jbSP+m+pVDLaEInoAgFwXY+tEuch3b/n4ShlDIq8SPfAElp6GTCCS01j9Yn24J9kDobFaYNjFpSiG2+NWkBetZE56dhdEfoHv8p0Ge/dsCPLTReMAYp/bkPYMPbDJIhHKQSqBkTxR7YiQaoAk5MF+bfnqBzgfwgvK6KTytMtWOgu2dPG14F1dXj6oAHOayy8JVQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iEXX9z5VrAd7nspVcHbahjTTf7grwiAsAqnw2S9I9YU=; b=FTFBGbt+ONMr8kET7S++lMnB9Cl488XgbZhUPdR00fkTtgv0KObpbWOZs0FWX77P5W9SX2zUICUZmsUjuTike4FsqVXmd0kYpgB9cgbQzDV9cwvW5bS/P20DhRDYEamVqVldRlJpvpuO0ityYwATpbsJukMcDGFjahnxygqxupw= Authentication-Results: tilera.com; dkim=none (message not signed) header.d=none;tilera.com; dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) by PH0PR11MB4982.namprd11.prod.outlook.com (2603:10b6:510:37::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.17; Wed, 11 Aug 2021 10:31:44 +0000 Received: from PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::2979:70ca:38a:dbaf]) by PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::2979:70ca:38a:dbaf%7]) with mapi id 15.20.4415.016; Wed, 11 Aug 2021 10:31:44 +0000 To: =?UTF-8?B?546L5b+X5a6P?= CC: , , "Singh, Aman Deep" , Igor Russkikh , "Cyril Chemparathy" References: <20210809062548.30187-1-wangzhihong.wzh@bytedance.com> <20210809065200.31134-1-wangzhihong.wzh@bytedance.com> <09afb669-2152-6770-5f89-bebc36bad6e9@intel.com> From: Ferruh Yigit X-User: ferruhy Message-ID: Date: Wed, 11 Aug 2021 11:31:38 +0100 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: FRYP281CA0010.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::20) To PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.0.206] (37.228.236.146) by FRYP281CA0010.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.8 via Frontend Transport; Wed, 11 Aug 2021 10:31:42 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1958b5e8-c8d7-48ca-4489-08d95cb33707 X-MS-TrafficTypeDiagnostic: PH0PR11MB4982: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: BMCiuWOL9PVi8NNJw31izXlZch32N9hutRFXoSfdGmLQZAAmpajrQiXuadAEnRbB9SlyT6c1QobL/jmBv4OHLm0sSn0hIcPiygvjiZ9AXpU3EVXjoiZCacJRYRm7jLcTnAp6j6yferpSynFnszZwYoWyiwIeKGvThWrXT8jVlVYALcZI/HT50XSPxSCD4ORxnwxMcSPFn2hM8AqAvkgshTpHgULRzoHRhNdvMVsL2rQ9+6B0Va7SFTJZFajQ8NvR8fGSAaUjI78EXIRX7fbpNabGH4BB+Zp7nxfPWKLHG+8muxJszv9FvFAyBj6Z+iMXcEDP5030uHBpSu+csbBdmZMNgh5alDSBnDNxNWZsGb4x4PaYVxDCWqZ8Sc1hxaQytz/aaFIVVUbX3yTkVaK/TZoPWvbz3BNj3xR+k+oNF6aFYBcVVDBTOi5GMJTluqxRX9VthsZZvaCwO1w+wGSGP5DPU2hasRo1YBD26aR2aiQlt41ww3W+i0sY3DTDH+gnTiQsB09ivvEhpVa1GeZWWR9iGhueThEZOxy64F9I4S/kEmtz247G0Ad7EZpBgH1Xl5wI/nDR1XKLAl4AuKbdQfnOec6H5DE6fpaVXnIHDIMqQ0etnv0YnfAqwqUMFOei1CE49f+5hnUvOobnePlvLig1RxXnLVAYe0kpDm8ffvxl7Abpz6uHKWKD5uNyC5INapEfICvOiduQOUNFVAotAg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5000.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(346002)(136003)(396003)(376002)(2906002)(478600001)(8676002)(8936002)(53546011)(66476007)(6666004)(4326008)(956004)(66556008)(2616005)(5660300002)(66946007)(26005)(186003)(44832011)(316002)(38100700002)(83380400001)(36756003)(6916009)(31696002)(54906003)(31686004)(86362001)(6486002)(16576012)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bk1kWXVNNnE2dnIyVHcwQVQwWFRVRitYekd2NXNHdEFPdk1HZ0hiQ3lvN1ZR?= =?utf-8?B?ZFlaaVpoNTRxandHdkUwWXpjRzluSTdGb0d0OWRxRXpSMzhyZnlxV0lxUkUx?= =?utf-8?B?Q3VNaEJsUkdJS3IyWFU5N29WYktFRlNZQ210WExRaExXcVlkbHhzQzJtL3lm?= =?utf-8?B?TUpZcTI3SlJWTzF1T0RmQ0FYS1hHZTA2RG4ydkJYR0ZrRURXMjBhSHFmaDFZ?= =?utf-8?B?OWxMYXE0RU16eWlwNS9HS0pYWjY3YW04RUI5SGw5ZjhtQVFvQUYyN1pHa1Zk?= =?utf-8?B?dzhaYU5LSFJub2RQR1RqS09NZ2pBck5SMjREWTFVK1dsYmh0MURucEpZMXgz?= =?utf-8?B?WmNwckxSUHN0ZlNvV3dHMEhOc0s2NENvSThhTW1HNkdLSzhaZllhMWNzbEhR?= =?utf-8?B?ZHNCMnhKbWU5VXdiY2RESUZhcGpmNEJBcGxkakg0dGY2bGo1bGVyRTgvVWlM?= =?utf-8?B?TFhTR2ZlbGF4d3crbHhCeTJUaHZjU1RvNHlGYUdFSTBSMEZCSlJoVkcvdjRq?= =?utf-8?B?L1NCeGJOaktwZmRXY24wRWNHVWlvdTNmTExva3oxM1hjeThSWnRpZ2JMcEta?= =?utf-8?B?MDV3RmpGTUNGMm5NUnBTRlNnUzNuaHRvQ3NxZjNBakV3WUFGQU5sdVk3VHpZ?= =?utf-8?B?S0tSdlZsUXVIUkNDak4rNGV1NklpVHlQQUxiaUhWeVp6akFyWXVQQWt5MW8y?= =?utf-8?B?QzhDUlBLL0c0VTd2RXBuNmorZzJQaGFhOU9uaE1EOWM5ZXJMS3l5a1pkR2ZF?= =?utf-8?B?MHJraElMN1FFZXJQQ2t0OWgvY3F4blFEeXhRWjdsL3AxdGRIREphLzkzeEdv?= =?utf-8?B?YklYUlFXelVRVEM3TTRTeUtRcXM5cjUwRWh3ZFk1TmxiU3dVOTJ6SFFaVW5j?= =?utf-8?B?NThSN3k0bUx2anh2RER4SUxqZHBLTHdYSnIzVVM0VFVXUmpGeFpnR3J2V3or?= =?utf-8?B?UmMzbi9kM0hLeTA0UGdBNWoxVUJtU3grZDRoTm45QWw3YTUwQmhIdXBEMUhE?= =?utf-8?B?OEJoQThCdmlaRUNmSFJqcVdsRTBDajFXZzQ4cE5uRFpxMjBUZFlYWE4yczQ0?= =?utf-8?B?TlZCaGF2T2oxczdKb3hsYkw4dGhBVjU5TVpiY1ZSWlNQQlhUWG83OEtQYmpw?= =?utf-8?B?dzY1MUQyakRpaDVwZFJhUmo4WWpnL1hTSVhmZ21BZDYvREkvYVprSDcyUmVP?= =?utf-8?B?TEdjOHpONGh4WkU5emIzNkc3L21qcnVOaUZrRVlDbGZCYXljR2FXanVZWGVX?= =?utf-8?B?U1RnRXN3c29NTW13TEhaUS9GNTB4RXBwZzFZRGMveUJhMGs5R1MrMWlBUEpl?= =?utf-8?B?U1pnaG9YWnBZWW5sYjBOVk0zb2VuYmc3WGpkWFd0Q3RmN2NyZnBiZWdQMzFR?= =?utf-8?B?ZVowa2p0a1ZiRk9ZMHVSVnJLSTFPZEV1cFpmbjZZdU1YakVnZnY5Qk9JOGhI?= =?utf-8?B?amNhU1JuUDNoaW9BcXlQY0U0WVFuWWd3RXFkS3F3a21uaEhxOGNOWlJiUTlh?= =?utf-8?B?WjRLU1hSaWpHRzZGOXRqK1o3c0dtYUlpMWhUWlM4R1pCMzdiUFhFZVBmTTMz?= =?utf-8?B?NjBZSTVoM016QW5sYUFXRU90aVdtMkZxdG1EY2l5TGJJTTVYQm5zYXlXTW9P?= =?utf-8?B?S05HRzdvOXVvZzZLVWRXcGVvZzRCWjc4QjlTNUcxR0t4NzUyS2FBUjJiUXFF?= =?utf-8?B?R2FhcENzeXJVZnhidWxabjh4aEhhTnE0ZzAxWlNYMG5UUUttQitTbWh3VlBt?= =?utf-8?Q?kBw3R/oJRT76YUK49tqhV9OJ9no3ViG1ZNLwx/0?= X-MS-Exchange-CrossTenant-Network-Message-Id: 1958b5e8-c8d7-48ca-4489-08d95cb33707 X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2021 10:31:44.4563 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ayIWVX6L/Z3MTfG4S4CeYNLn/MmwGUGn5ROLbAM3T7H6/9bsBHctwkXAFS6sphaIlGeZ6GMMxqIkIgMJ/a4gNg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4982 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [External] Re: [PATCH v2] app/testpmd: flowgen support ip and udp fields 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 Sender: "dev" On 8/11/2021 3:48 AM, 王志宏 wrote: > On Tue, Aug 10, 2021 at 5:12 PM Ferruh Yigit wrote: >> >> On 8/10/2021 8:57 AM, 王志宏 wrote: >>> Thanks for the review Ferruh :) >>> >>> On Mon, Aug 9, 2021 at 11:18 PM Ferruh Yigit wrote: >>>> >>>> On 8/9/2021 7:52 AM, Zhihong Wang wrote: >>>>> This patch aims to: >>>>> 1. Add flexibility by supporting IP & UDP src/dst fields >>>> >>>> What is the reason/"use case" of this flexibility? >>> >>> The purpose is to emulate pkt generator behaviors. >>> >> >> 'flowgen' forwarding is already to emulate pkt generator, but it was only >> changing destination IP. >> >> What additional benefit does changing udp ports of the packets brings? What is >> your usecase for this change? > > Pkt generators like pktgen/trex/ixia/spirent can change various fields > including ip/udp src/dst. > But testpmd is not packet generator, it has very simple 'flowgen' forwarding engine, I would like to understand motivation to make it more complex. > Keeping the cfg_n_* while setting cfg_n_ip_dst = 1024 and others = 1 > makes the default behavior exactly unchanged. Do you think it makes > sense? > >> >>>> >>>>> 2. Improve multi-core performance by using per-core vars> >>>> >>>> On multi core this also has syncronization problem, OK to make it per-core. Do >>>> you have any observed performance difference, if so how much is it? >>> >>> Huge difference, one example: 8 core flowgen -> rxonly results: 43 >>> Mpps (per-core) vs. 9.3 Mpps (shared), of course the numbers "varies >>> depending on system configuration". >>> >> >> Thanks for clarification. >> >>>> >>>> And can you please separate this to its own patch? This can be before ip/udp update. >>> >>> Will do. >>> >>>> >>>>> v2: fix assigning ip header cksum >>>>> >>>> >>>> +1 to update, can you please make it as seperate patch? >>> >>> Sure. >>> >>>> >>>> So overall this can be a patchset with 4 patches: >>>> 1- Fix retry logic (nb_rx -> nb_pkt) >>>> 2- Use 'rte_ipv4_cksum()' API (instead of static 'ip_sum()') >>>> 3- User per-core varible (for 'next_flow') >>>> 4- Support ip/udp src/dst variaty of packets >>>> >>> >>> Great summary. Thanks a lot. >>> >>>>> Signed-off-by: Zhihong Wang >>>>> --- >>>>> app/test-pmd/flowgen.c | 137 +++++++++++++++++++++++++++++++------------------ >>>>> 1 file changed, 86 insertions(+), 51 deletions(-) >>>>> >>>> >>>> <...> >>>> >>>>> @@ -185,30 +193,57 @@ pkt_burst_flow_gen(struct fwd_stream *fs) >>>>> } >>>>> pkts_burst[nb_pkt] = pkt; >>>>> >>>>> - next_flow = (next_flow + 1) % cfg_n_flows; >>>>> + if (++next_udp_dst < cfg_n_udp_dst) >>>>> + continue; >>>>> + next_udp_dst = 0; >>>>> + if (++next_udp_src < cfg_n_udp_src) >>>>> + continue; >>>>> + next_udp_src = 0; >>>>> + if (++next_ip_dst < cfg_n_ip_dst) >>>>> + continue; >>>>> + next_ip_dst = 0; >>>>> + if (++next_ip_src < cfg_n_ip_src) >>>>> + continue; >>>>> + next_ip_src = 0; >>>> >>>> What is the logic here, can you please clarifiy the packet generation logic both >>>> in a comment here and in the commit log? >>> >>> It's round-robin field by field. Will add the comments. >>> >> >> Thanks. If the receiving end is doing RSS based on IP address, dst address will >> change in every 100 packets and src will change in every 10000 packets. This is >> a slight behavior change. >> >> When it was only dst ip, it was simple to just increment it, not sure about it >> in this case. I wonder if we should set all randomly for each packet. I don't >> know what is the better logic here, we can discuss it more in the next version. > > A more sophisticated pkt generator provides various options among > "step-by-step" / "random" / etc. > > But supporting multiple fields naturally brings this implicitly. It > won't be a problem as it can be configured by setting the cfg_n_* as > we discussed above. > > I think rte_rand() is a good option, anyway this can be tweaked easily > once the framework becomes shaped. > Can be done, but do we really want to add more packet generator capability to testpmd? >> >>>> >>>>> } >>>>> >>>>> nb_tx = rte_eth_tx_burst(fs->tx_port, fs->tx_queue, pkts_burst, nb_pkt); >>>>> /* >>>>> * Retry if necessary >>>>> */ >>>>> - if (unlikely(nb_tx < nb_rx) && fs->retry_enabled) { >>>>> + if (unlikely(nb_tx < nb_pkt) && fs->retry_enabled) { >>>>> retry = 0; >>>>> - while (nb_tx < nb_rx && retry++ < burst_tx_retry_num) { >>>>> + while (nb_tx < nb_pkt && retry++ < burst_tx_retry_num) { >>>>> rte_delay_us(burst_tx_delay_time); >>>>> nb_tx += rte_eth_tx_burst(fs->tx_port, fs->tx_queue, >>>>> - &pkts_burst[nb_tx], nb_rx - nb_tx); >>>>> + &pkts_burst[nb_tx], nb_pkt - nb_tx); >>>>> } >>>> >>>> +1 to this fix, thanks for it. But can you please make a seperate patch for >>>> this, with proper 'Fixes:' tag etc.. >>> >>> Ok. >>> >>>> >>>>> } >>>>> - fs->tx_packets += nb_tx; >>>>> >>>>> inc_tx_burst_stats(fs, nb_tx); >>>>> - if (unlikely(nb_tx < nb_pkt)) { >>>>> - /* Back out the flow counter. */ >>>>> - next_flow -= (nb_pkt - nb_tx); >>>>> - while (next_flow < 0) >>>>> - next_flow += cfg_n_flows; >>>>> + fs->tx_packets += nb_tx; >>>>> + /* Catch up flow idx by actual sent. */ >>>>> + for (i = 0; i < nb_tx; ++i) { >>>>> + RTE_PER_LCORE(_next_udp_dst) = RTE_PER_LCORE(_next_udp_dst) + 1; >>>>> + if (RTE_PER_LCORE(_next_udp_dst) < cfg_n_udp_dst) >>>>> + continue; >>>>> + RTE_PER_LCORE(_next_udp_dst) = 0; >>>>> + RTE_PER_LCORE(_next_udp_src) = RTE_PER_LCORE(_next_udp_src) + 1; >>>>> + if (RTE_PER_LCORE(_next_udp_src) < cfg_n_udp_src) >>>>> + continue; >>>>> + RTE_PER_LCORE(_next_udp_src) = 0; >>>>> + RTE_PER_LCORE(_next_ip_dst) = RTE_PER_LCORE(_next_ip_dst) + 1; >>>>> + if (RTE_PER_LCORE(_next_ip_dst) < cfg_n_ip_dst) >>>>> + continue; >>>>> + RTE_PER_LCORE(_next_ip_dst) = 0; >>>>> + RTE_PER_LCORE(_next_ip_src) = RTE_PER_LCORE(_next_ip_src) + 1; >>>>> + if (RTE_PER_LCORE(_next_ip_src) < cfg_n_ip_src) >>>>> + continue; >>>>> + RTE_PER_LCORE(_next_ip_src) = 0; >>>>> + } >>>> >>>> Why per-core variables are not used in forward function, but local variables >>>> (like 'next_ip_src' etc..) used? Is it for the performance, if so what is the >>>> impact? >>>> >>>> And why not directly assign from local variables to per-core variables, but have >>>> above catch up loop? >>>> >>>> >>> >>> Local vars are for generating pkts, global ones catch up finally when >>> nb_tx is clear. >> >> Why you are not using global ones to generate packets? This removes the need for >> catch up? > > When there are multiple fields, back out the overran index caused by > dropped packets is not that straightforward -- It's the "carry" issue > in adding. > >> >>> So flow indexes only increase by actual sent pkt number. >>> It serves the same purpose of the original "/* backout the flow counter */". >>> My math isn't good enough to make it look more intelligent though. >>> >> >> Maybe I am missing something, for this case why not just assign back from locals >> to globals? > > As above. > > However, this can be simplified if we discard the "back out" > mechanism: generate 32 pkts and send 20 of them while the rest 12 are > dropped, the difference is that is the idx gonna start from 21 or 33 > next time? > I am not sure point of "back out", I think we can remove it unless there is no objection, so receiving end can recognize failed packets.