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 7383F456AC; Thu, 25 Jul 2024 19:30:35 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 23D0F427A9; Thu, 25 Jul 2024 19:30:35 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) by mails.dpdk.org (Postfix) with ESMTP id E4D46402C6 for ; Thu, 25 Jul 2024 19:23:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1721928183; x=1753464183; h=message-id:date:subject:to:cc:references:from: in-reply-to:mime-version; bh=Rj1CCw4bDfdrkyPj78rZtPa+MOkBn66RGkEJnfOlVnM=; b=TZMYKaGMXpn7RzQeu5Umx3ByhK39dBLNq4NIU5XRDsibLNwK0L5kMCXU 5QzOX5BADmFKnboUjSF1tt/ovtylxiBqkVgfWNLXe8GrOocF9LTHXHZFg 1vacE2kMO0/5/2WaSfC3hC06fbJxRN8TDofXX0jo8TcMrWe3qaGxJtxob LFwjFWQBhcaEnTuZuaDtqiRUamzVIkOXPCalAVKxwoTyyWLhhNqeJmQBk pp2077KD86+v3EkQrCV4+BPKAza4fKpH+39Fgv4qUR5NDYxN7/Ye6LLTY 5Lbqk8eQVV1ZpoDIZMuP2NKFh90b7dzaBHrolu53GTgS5fHBICABI+oHi w==; X-CSE-ConnectionGUID: hyNm0Y0UQ2i3b5ShZV2qiw== X-CSE-MsgGUID: mfxa+GbbSaS9KEMASSThdA== X-IronPort-AV: E=McAfee;i="6700,10204,11144"; a="19825631" X-IronPort-AV: E=Sophos;i="6.09,236,1716274800"; d="scan'208,217";a="19825631" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jul 2024 10:23:02 -0700 X-CSE-ConnectionGUID: xsuw5vu0TcikQ8Wyh6emuQ== X-CSE-MsgGUID: ZZLbwQu9RlmRH9NcXofHhQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,236,1716274800"; d="scan'208,217";a="52883624" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by fmviesa008.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 25 Jul 2024 10:23:01 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 25 Jul 2024 10:23:01 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) 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.2507.39; Thu, 25 Jul 2024 10:23:00 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39 via Frontend Transport; Thu, 25 Jul 2024 10:23:00 -0700 Received: from NAM04-BN8-obe.outbound.protection.outlook.com (104.47.74.48) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 25 Jul 2024 10:23:00 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=D5Q+JRacygGxKo0itHJEY7FVnzbMZWX3H2VhyULtoy6pWdYmlN1++yOBXl8rjXoxAgXlwy9So2UtQ00rbc0pwgeMELZwoDZnlXjnJQRJpxZwjakir5PoxO+24dxkdTybWx4cvBh3WHktTB+yqSC1LoBmro0CzBMDm1A5hKiyDDnbiZKpC/9mB9iupICm6oMAVzqnEVxoeYbahEq4ZsPDrlsIK+YR6iJ4ruAkkKeOFpKIu/TAJFygrpLrjxcL+K7QEpJVGm6HieVVvPZBqDMROLXK0JB1I1Rfn7PnbfTtqbD3kA1XqRSeOdllfPXG4aOZBCWRUkaOacCZqaZuI7VUMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wcnZKQoBI/3wT6/pB47bE+oHCrK9zGTpuNVNlIbv4Rg=; b=Ccsu3sB0qzCyqUmn/lVEKN7lJIwsMtb4uUvPjc5YW2BHeA/S/VLtwr9Rdujl9Zg7PDjjXLYa9EJ0T9n1Y0d6cYJhrBHI7BtJdIJsNBLccNh8UppSN4XVIlVnCfzpSdK35ubGH2EOmkHdY7rBviGBw+tm5uReb6Huwh05+Jlc0nh8ZJCvQRfNzsIKSWBLPpwvlzSlekpyDVfDXNy2mz4+miD7MrG/t4DNN4dI8/pUbJNNQQxZ+3/5shBxaC0/rCqXOCxVdxqYiOuqt2SIGRML+W9aCIfuw/NGS1WMOXt0nHpjdQVNmdsGjkcTvHyEhDiRiQ9FPH47Q6R9akjL0APNNg== 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 Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from SJ0PR11MB5772.namprd11.prod.outlook.com (2603:10b6:a03:422::8) by CH3PR11MB8660.namprd11.prod.outlook.com (2603:10b6:610:1ce::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7784.16; Thu, 25 Jul 2024 17:22:58 +0000 Received: from SJ0PR11MB5772.namprd11.prod.outlook.com ([fe80::5851:319:3da6:850b]) by SJ0PR11MB5772.namprd11.prod.outlook.com ([fe80::5851:319:3da6:850b%4]) with mapi id 15.20.7762.020; Thu, 25 Jul 2024 17:22:58 +0000 Content-Type: multipart/alternative; boundary="------------XNPCp1HDYETxgbjzSU3F0TI0" Message-ID: <19982b29-b51e-43dc-a6b1-a4bfb26647a4@intel.com> Date: Thu, 25 Jul 2024 18:22:52 +0100 User-Agent: Mozilla Thunderbird Subject: Re: fib{,6}: questions and proposals To: Robin Jarry CC: , Bruce Richardson References: Content-Language: en-US From: "Medvedkin, Vladimir" In-Reply-To: X-ClientProxiedBy: DB7PR05CA0047.eurprd05.prod.outlook.com (2603:10a6:10:2e::24) To SJ0PR11MB5772.namprd11.prod.outlook.com (2603:10b6:a03:422::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ0PR11MB5772:EE_|CH3PR11MB8660:EE_ X-MS-Office365-Filtering-Correlation-Id: 526a6b15-a601-41b7-2a77-08dcacce6d73 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|3613699012; X-Microsoft-Antispam-Message-Info: =?utf-8?B?SXRtc1JSMEM5dHB5Y3htWllYSHl5Q1l3c0tJUmJSZDVLS2ZrdjJ3d0VHNUM4?= =?utf-8?B?N2dnV2VaSkxrK3NkeW5pcmcxMysyVG9SL0pXaEtydzlWVE1IQUk0Q0VjV3o3?= =?utf-8?B?YU5MbllpckttelhsYWtLeXVvakZlOFpaczRKbVpqSWd2WXpDL2x4QTlvZ2Y5?= =?utf-8?B?VVdrK2ZBbzIySUEwMTQ3aWpxTUpaU01IejBtbzVkZGc5bVVtL0RPRGVDZ1hW?= =?utf-8?B?bzhGb0t3b2NjQW04TlROaHZmQlZ4U3NORk5aS1F1R0tNanN5dGRpQ2UyTGZi?= =?utf-8?B?SHMxQWpZQmtXWG5uV3BaTlIvL0p2Zm1yc1BTcUFOTDA1TlU5Zk55T2U2Vm5x?= =?utf-8?B?akQ4T3lxTVc0WGZ5eDNNdHlyQUI3dHJTS2p6bkVKTlpjUTRUNC82UlpqTUl1?= =?utf-8?B?eGdINExId0xwbkJWRUpXYnE1L1k2bXlRRXpXR1NZR1RPMndNVWpsMTVpQXBn?= =?utf-8?B?QmhvandFaExnS1Z2TE1WYjBSOUwyaXg2ZDJVRDE4dXlmWGNlZ2FuUHgyc3c0?= =?utf-8?B?TlVmR1JMbzNLRUNOMkh4WDY5ZjFWT05QRmxtMGJISnhEZEU0c2kySGpvZkZh?= =?utf-8?B?aGpsTDg3TCtQMTFOL2NjQ2xaRjQ2bFRmM05aZ1hpaGkvaXN5SzQ4a3dmT1Qy?= =?utf-8?B?amxUNjZCKys5S0RlNEhUcHZVdEtHbFB4aHJSc0hKVUUraXBiZ2ZXektCYlJK?= =?utf-8?B?dUZHZHpjaHBhREVCRit1UXpJYWxXT0lmQzV3S295Wno2bzhEZ25ET0Z5bWRx?= =?utf-8?B?UGRKeTRVZEV5Q2hPV29DN0FlUWFXblhHZ2xhaFp4ZjhwTXg1QWRwTEdXZTJL?= =?utf-8?B?RnZtR3ZrcFEwZ0ZsbEdmYkhjMHovZnUzTy9STnFrSTRzdTdUaW5GeUl2NnNS?= =?utf-8?B?b1U1SmpiS2RRNk1iME5SL1NqTFZOdFk3d2doaVBsZHVyL1pOdW5ZM1kxNFZ5?= =?utf-8?B?MHg3ZWFzMnpTbmlZaGFNeTYzWEtmTGxBMUpVN09SSHBmUFpMeUpFOTlHaldT?= =?utf-8?B?RmU5NisxR3B4b3V5bTV1YXF2b05BSVh6ZWEwdHdpWTVtOWdqTVcyYncyNXQ5?= =?utf-8?B?ZU84NFRMVXFpSVluQThuZlpCSmJZTno5NjBUN3EvalNpOFRtYmhkMm1nbmRY?= =?utf-8?B?L0JyRjdtOUE5N3ArM3JONW91WENQYldoQzFvVDBaNGpFZW0wMDR5MFhmSUZs?= =?utf-8?B?ZUhKUy9kZU1za3VjSjBrNzZqL1B1TTg1TVkzS0x3UlZaeEY1cG5WcllFdXlj?= =?utf-8?B?ZVFXNEpFRUlOY3grcUkvUkFrNVVtRS9uOXN5NlRyb01pZzZ2ZWtuOFA0T2FV?= =?utf-8?B?dm9DVFdvZVhrbTVEMEhmTmdLVDdvaTJ1QktDUW9US1VjcTVVTkF5YjBMSjhh?= =?utf-8?B?TjI1aHQ1MVlnUEtYVVZNV2VON0VpQmNTYSttQlNoSWc2Ni9XYXQxalozKzF6?= =?utf-8?B?Y3dyZnozMjFaRitEWGNOV1E1Q0NUUXgzL3poUHRtYjIzQWkwaHpJcTlWVjNv?= =?utf-8?B?TFA1M3RBM0lvSC9VWVZOV0xjTjdBZHA5bTZZT2ttdmswV2NEMzljOUtOQ28y?= =?utf-8?B?a0k2eEdNd2w4RmoweGxiQlJRR3JzckIvTkM2Y0I2LzkxUVI1NW5ZYzN6SUI4?= =?utf-8?B?am0wNkRPV2IwVDNSdVBvRm1hcENjc1M1VHBHWW02bmVldjk0dXlxSEtPTmVV?= =?utf-8?B?bWZyYk1nSytuUEFiRFRia0VtUSt4QVVROUFzWSszTE50UmFtcXRYRlBieGJv?= =?utf-8?B?WllaNUFGc2xwZXpmeXpuanp0U1VZdVFNMDVUbkJYVzcwUHVFZnR0cUhETEd2?= =?utf-8?B?VjloMkhCVGZ5VnZlZ0tza1JIS3lwKzZ0eS9GTmJHMzNROTZkZWxXWE9uV1I2?= =?utf-8?B?ekdyc2E4eHhZVUZCcWE2a29OSUV4MXEwc0tUbUtKRURIMmc9PQ==?= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR11MB5772.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(376014)(1800799024)(366016)(3613699012); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YkwyWVZyRDlGSXpYUUhVMXkybWxDSUM2NnRLT3F2RzJSY21La3I4ajd4ODl1?= =?utf-8?B?UEF6WlNRWWswaGZubmJXOUo2STI2ZE1UMnFCUjdIcllFSHVGQUJabmI3TXps?= =?utf-8?B?aU1Rdk8zTGE5R2srV2dkZ1BwSEU0Y3RZVVlaeCt2UVBrbzQwQTRQcmpTR29W?= =?utf-8?B?ekpJMGFQMVIvS2s0cmdlZ1hkMWpJQ2VXdkRabWlYT3IxTm1HeFd4bEZRR2RM?= =?utf-8?B?WVU1UU4zQk1FcGhMaEllMy9EMDYrd25XZWlUWElHVE9sOVpPYlpkR01jZHk0?= =?utf-8?B?WllYLzR5MXNxWkhjcTJMd0ExeGFlZ1hpcVd2cERmMHRBSk5MT09BWHVTaFJ6?= =?utf-8?B?S3U3WnRuTXZFQWljQytmb081NVUyTHNBVFhheFA3Tm16NTFkUzk5alRoRld6?= =?utf-8?B?aHVZWDFSR1U5K3krbUFZeEplRVJJamxQQlZIOGk4cy9ZSVJIdWdPcGJ6WGFD?= =?utf-8?B?ODhUMXlOcy9EdVBvNUE4YndlY08xY2NTWS9ZQUhBUkptSldGNW9ML2dXeHBp?= =?utf-8?B?eDlzYkdsaExTUHdSYnp1Sjllbnd6T0ttVXB6SVVESS9DUVNFd2M5YWlWa25V?= =?utf-8?B?R1E0ZkZjS0crTzcxazZsbFF4Q1lzRGRrN011Qit1R3E0WWlsVUN1OHhHOHpi?= =?utf-8?B?UkJiWlBVNC9KQ0FwS21IYmYzeTNJZFc4MlNrSG1nN25OSCtGRU5XRlUvSkln?= =?utf-8?B?ckVibnRPWFNWeGlCdXMvNUUxTGt3K0Z5S0J2UkZ3WDR3d3lXc3lkVGMxQllx?= =?utf-8?B?cXVuM1BjcGJhNEpxZXlpamlDSzlqU2oyOE9EK0RtOVlqYmpSQmpNMWZmT0FB?= =?utf-8?B?SnBiZkZhQUhPUVBXMlg4K21rS0szZXhXczlrYW50cUs1WGVYVkxMMzFyZUs1?= =?utf-8?B?MXVHOU9oQ2RoUFVmcFk0Q08ranVKMG8zY3pDODlzVmwzdzJ4WGVHU1NDam1z?= =?utf-8?B?OEEwQmR0dmdzYVdTSGRPTk41a1JZWjE5ZUFyMWxZclp3ZVRrdVU2dE51c2lD?= =?utf-8?B?QVBrNm1JVHhxSmF0Ukh3UUVQVFVqbDZwRlFGMDhzeDdrSzlGZU0zQVZXc0lY?= =?utf-8?B?QktDRDVhY2MwWWFob3ZuM0RhT3c5SHVpMzd2c0RZeW9vZ1dlVzY0elFicGZS?= =?utf-8?B?YUFMK2dNT1UwREgyR2JVdHYySlQ2Z1c4amFpRXZ2VnpGQmV3czUwcnVuYlV4?= =?utf-8?B?UERwV1B6cUZCUzE4dmp6b2tDVlY3Ny94MDBZRGduNkNpR1lKaWk5Y1FRZStw?= =?utf-8?B?aUJ5eSswTWxTYU9qTVgyTG94cFZNOEJsOHY3RlQ3dEF0Z3J1V080alZLSEcx?= =?utf-8?B?YkYrR1RIQVdFM05WdGFqNkxWdkpFU1pjSTdmek9kMEIxVnN0ZmNpZTRBWmdz?= =?utf-8?B?N0s2WGxrQXRvRzVRWG83QXlxdjN1VSszVkhPZlAwS2xrU2J6OHMzanAxRUJZ?= =?utf-8?B?MTFWV2Fvb2FpamFJMzBtTFFnN216NGJnSTNHSnlYN1FNM3p2OHY5djlnS2FU?= =?utf-8?B?NStVWDZUeS84a1RYazVJWk9OT2JwVEJjYmhmckRiOUsxUGZGK2hDOHFCWW9h?= =?utf-8?B?cXpYU3JtTGpUU0ttTGJSTDYzTHRScS9wME5hajFKKzM1d2txTW04d2RuS0gz?= =?utf-8?B?T0dPOXZvRHNsTjZUbktyVng1dm43OWxaazM5dmtmS21SWGM4NUd4MHlKNXNU?= =?utf-8?B?RGI4a05tZ0lyeEM4VFdZQ2xBTkZFVWxjQzJOa2hCeFkwTFkzVlZuKzUyVXly?= =?utf-8?B?TzgzUE13eE9LWHJnREJ4Yitncjg3YlpIc0RJMjZtd3AwSlNrYmNWYXJZL3Mz?= =?utf-8?B?RWsvaEYyZllrNUhpd0dZa2hZSzZRSThJOC9aWU4wV1ovUjJXL095QlJHQW5K?= =?utf-8?B?SGgyWHg4WEhidU5YMDVQV24wSEFJNG5FdEcvYjBiaEppM3VyY1AvTDB0Nnp4?= =?utf-8?B?U2I0ejBpeDl0L3lxN3RWVEkxQmcyaWF6RHhSaTQ2RCtPL0ZxbGJab2VaWW1X?= =?utf-8?B?VWZmajBYR3M2dHdhcUl2WUcwUnAzVndmUVp3MmRWUFlKaXA0UUNDV3liNUhs?= =?utf-8?B?WDVUT2N5U1RvMUpjaCs1ekk0Wm9EWjN5SDRlMjYvZDJjTXBXMnRRc1lWcEtp?= =?utf-8?B?TnRYckhLVzNROXdhdkluRnhNa3ZlQmtFczdydjJYUW9lNjN3dm1JMlFYcFMx?= =?utf-8?B?cFE9PQ==?= X-MS-Exchange-CrossTenant-Network-Message-Id: 526a6b15-a601-41b7-2a77-08dcacce6d73 X-MS-Exchange-CrossTenant-AuthSource: SJ0PR11MB5772.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jul 2024 17:22:58.1593 (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: ZIP+OMoOPL4c8s0iIijNzBghz20D+kVv6t7E3kkCk0oiXK3ooFp5b6Mf8MqCVLc7ptkMlDu+3jsKjnTXH8FZ0KZELJsD+jCg/ybDcJ7gvh0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR11MB8660 X-OriginatorOrg: intel.com 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 --------------XNPCp1HDYETxgbjzSU3F0TI0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Robin, Apologies for the delayed response On 19/03/2024 20:38, Robin Jarry wrote: > Hi Vladimir, > > Medvedkin, Vladimir, Mar 19, 2024 at 18:16: >> > 2) Is it OK/safe to modify a fib from a control thread (read/write) >> >    while it is used by data path threads (read only)? >> >> This part is a bit more complicated. In practice, I would say yes, >> however, there is a possibility that if the lookup thread is >> preempted in the middle of the lookup process, and at the same time >> the control thread deletes the corresponding route, then the lookup >> result may return outdated data. This problem is solved in LPM with >> RCU enabled. I have plans to implement it in the near future in the FIB. > > OK that's good to know, thanks. > >> > 3) There is no public API to list/walk all configured routes in >> >    a fib. Would that be possible/easy to implement? >> >> Yes, it already there. FIB under the hood uses rte_rib to hold >> existing routes. So walking through can be implemented like: > > I had tried it and got confusing results out of this. This must have > been before I had realized that all addresses needed to be in host > order... > > I tried again and it works as advertised with a small missing detail: > after configuring a default route, e.g.: > >    rte_fib_add(fib, RTE_IPV4(2, 2, 0, 0), 16, RTE_IPV4(1, 2, 3, 4)); >    rte_fib_add(fib, RTE_IPV4(3, 3, 3, 0), 24, RTE_IPV4(4, 3, 2, 1)); >    rte_fib_add(fib, RTE_IPV4(0, 0, 0, 0), 0, RTE_IPV4(9, 9, 9, 9)); > > It is not returned by rte_rib_get_nxt() successive calls. I only see > the other two routes: > >    2.2.0.0/16 via 1.2.3.4 >    3.3.3.0/24 via 4.3.2.1 > > Is this expected? Yes, it is expected. It is also reflected in API: "Retrieve next more specific prefix ...". So, in your case you should explicitly lookup 0/0 route. IfindthismoreconvenientfordataplanestructureslikeDIR24-8,whereIneedto findgaps forsomegivensuperprefix. > >> > 4) In rte_fib, every IPv4 address (route *and* next hop) needs to >> be >    in host order. This is not consistent with fib6 where >> addresses >    are stored in network order. It took me quite a while >> to figure >    out what was wrong with my code. >> This API behavior was created in such a way that it is the same as LPM. >> >> As for LPM, I think it was done this way for performance reasons >> because in some scenarios you only working with the host order ipv4 >> addresses. > > This should really be advertised in strong capital letters in the API > docs. Or (preferably) hidden to the user. I don't see any valid > scenario where you would work with host order IPv4 addresses. I just implemented lookup the same way as LPM. As for valid scenario, years ago I used an LPM/FIB lookup on a huge text log file(it was nginx logs if I remember correctly) with hundreds of million lines with IP addresses to resolve corresponding AS numbers for some statistics. The macro I used converted substrings with IPv4 into unsigned integers in host byte order. So, it is not always true that IPv4 are in network byte order. > > Do you think we could change that API or at least add a flag at > FIB/RIB creation to make it transparent to the user and consistent > between IPv4 and IPv6? Yes, I will add FIB configuration option to allow BE IPv4 as an input for lookup function. > > Thanks! > -- Regards, Vladimir --------------XNPCp1HDYETxgbjzSU3F0TI0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Robin,

Apologies for the delayed response

On 19/03/2024 20:38, Robin Jarry wrote:<= br>
Hi Vladimir,

Medvedkin, Vladimir, Mar 19, 2024 at 18:16:
> 2) Is it OK/safe to modify a fib from a control thread (read/write) >    while it is us= ed by data path threads (read only)?

This part is a bit more complicated. In practice, I would say yes, however, there is a possibility that if the lookup thread is preempted in the middle of the lookup process, and at the same time the control thread deletes the corresponding route, then the lookup result may return outdated data. This problem is solved in LPM with RCU enabled. I have plans to implement it in the near future in the FIB.

OK that's good to know, thanks.

> 3) There is no public API to list/walk all configured routes in >    a fib. Wo= uld that be possible/easy to implement?

Yes, it already there. FIB under the hood uses rte_rib to hold existing routes. So walking through can be implemented like:

I had tried it and got confusing results out of this. This must have been before I had realized that all addresses needed to be in host order...

I tried again and it works as advertised with a small missing detail: after configuring a default route, e.g.:

   rte_fib_add(fib, RTE_IPV4(2, 2, 0, 0), 16, RTE_IPV4(1, 2= , 3, 4));
   rte_fib_add(fib, RTE_IPV4(3, 3, 3, 0), 24, RTE_IPV4(4, 3= , 2, 1));
   rte_fib_add(fib, RTE_IPV4(0, 0, 0, 0), 0, RTE_IPV4(9, 9,= 9, 9));

It is not returned by rte_rib_get_nxt() successive calls. I only see the other two routes:

   2.2.0.0/16 via 1.2.3.4
   3.3.3.0/24 via 4.3.2.1

Is this expected?

Yes, it is expected. It is also reflected in API: "Retrieve nex= t more specific prefix ...". So, in your case you should explicitl= y lookup 0/0 route.

I find <= /span>this = more convenient for data plane structures like DIR24-8,= where I need to fi= nd gaps for some given superprefix.


> 4) In rte_fib, every IPv4 address (route *and* next hop) needs to be >    in host o= rder. This is not consistent with fib6 where addresses >    = are stored in network order. It took me quite a while to figure > &nbs= p;  out what was wrong with my code.
This API behavior was created in such a way that it is the same as LPM.

As for LPM, I think it was done this way for performance reasons because in some scenarios you only working with the host order ipv4 addresses.

This should really be advertised in strong capital letters in the API docs. Or (preferably) hidden to the user. I don't see any valid scenario where you would work with host order IPv4 addresses.
I just implemented lookup the same way as LPM. As for valid scenario, years ago I used an LPM/FIB lookup on a huge text log file(it was nginx logs if I remember correctly) with hundreds of million lines with IP addresses to resolve corresponding AS numbers for some statistics. The macro I used converted substrings with IPv4 into unsigned integers in host byte order. So, it is not always true that IPv4 are in network byte order.

Do you think we could change that API or at least add a flag at FIB/RIB creation to make it transparent to the user and consistent between IPv4 and IPv6?

Yes, I will add FIB configuration option to allow BE IPv4 as an input for lookup function.


Thanks! 

--=20
Regards,
Vladimir
--------------XNPCp1HDYETxgbjzSU3F0TI0--