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 9DCFC45DEB; Tue, 3 Dec 2024 15:37:35 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6C05740272; Tue, 3 Dec 2024 15:37:34 +0100 (CET) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) by mails.dpdk.org (Postfix) with ESMTP id EB16840264 for ; Tue, 3 Dec 2024 15:37:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1733236652; x=1764772652; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jRvizGw2rrAq/kQiNk9lt0ZlLEz1Su9z2yF7MRv6DzE=; b=QdmA20ORgjk7CtPZ5l+98grFD+PuQt3IBltpH0XJCHfJeF5VKVZBnuou 0Pw1jSnAgy2vZVLWjSgbpcPT8sHEzk3gyEX+t0JeELvpjgFgK3iLkuUkW shnVicdQlN0XoCCa7S9Fih8m0Dz7y3xcJwC7PwTe6hNhOwqWnuiHnhyyD Wc7U6yeleFtAQjpYARbu47mG9GJA1JeMvnGk9VfMU11J1T1slikkBbijX BbDb6UHG71DhfMDvC6b6Iwm8GckknYQdK0pL93TYK7rTij0wZTV0pcU1o eZNbGdin51nM3qJzuiT2dFuEyKat4j/mclVfg0GXQT3JUBKMH2i92BVbT A==; X-CSE-ConnectionGUID: T6Dh0eQIQQ+Toc4wUiTYsg== X-CSE-MsgGUID: gKYuD+bNQ9uWfes7fVLHiQ== X-IronPort-AV: E=McAfee;i="6700,10204,11275"; a="37224266" X-IronPort-AV: E=Sophos;i="6.12,205,1728975600"; d="scan'208";a="37224266" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Dec 2024 06:37:31 -0800 X-CSE-ConnectionGUID: Bcxg0ykmTtS9vZXFrsyKDg== X-CSE-MsgGUID: OCyWkLEsTXi6TsAcDS90RA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,205,1728975600"; d="scan'208";a="124282299" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by orviesa002.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 03 Dec 2024 06:37:31 -0800 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 3 Dec 2024 06:37:30 -0800 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39 via Frontend Transport; Tue, 3 Dec 2024 06:37:30 -0800 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.45) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Tue, 3 Dec 2024 06:37:30 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qJMHsCZzNoFlgbNL/lvI7GJo4qTaEmW/So37TQ2WJTKexvhfQL8Ym9J5i3CON6oxepR//zqXlcWfNPBgbp+rajrs8x0eLRmp8zBySPo2MaqFQRHyGV2K3NmEuTHML5Eea9FEK84vlQXuejVh1tYzjh31pyfIIjFV0Z62xwqcuMNcsHvS9w2shXFsXyjV6xQdsaObkmIxmR7TCdxSYViGRUn/z+qhf3ZkROIniiM8nIbBaJfuGtoS9+eijmVPYQBq8mq8vsCe6AtJKlknPtV0UmdC9T9G3alWMtLBAuTTD/iwTKFUNOVjRZqOC9yNog6E2yMCCWBhQPmbf3wzlxcZqw== 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=jRvizGw2rrAq/kQiNk9lt0ZlLEz1Su9z2yF7MRv6DzE=; b=olT7BsfE4dp1PINYhKZuf7bPh2H8ej7r+FSNZEA+Xuneg/0CIjlM6bOm1YmMDuN4JpkRCS8TfLINpp+ixY9B3/bn13Rk6tA+hdzjSol6fDfPuxasygoVhVRxy+O8WMU13bkt95w5S2x96ZY+pVFi4oioBPwKqT+/q2t+xy6iOyCnyatKmGUOY9Pw8y5jRXDkSsrLlMLpexWRS1ZdGBRZVdpVljH+Up//E4hLCq0XOqzqgao1Qg1CXl0mIbzVFlxYCKLew6d3ILdipZaFMOeDSQZD1+YE7clcmqfLCwBuozLkX6mj+uBV8hI+Vjf2YjsipxLZSsNYokODRmMRuJzQ+Q== 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 Received: from SJ0PR11MB5772.namprd11.prod.outlook.com (2603:10b6:a03:422::8) by DS0PR11MB8114.namprd11.prod.outlook.com (2603:10b6:8:129::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8207.19; Tue, 3 Dec 2024 14:37:19 +0000 Received: from SJ0PR11MB5772.namprd11.prod.outlook.com ([fe80::5851:319:3da6:850b]) by SJ0PR11MB5772.namprd11.prod.outlook.com ([fe80::5851:319:3da6:850b%6]) with mapi id 15.20.8207.017; Tue, 3 Dec 2024 14:37:18 +0000 From: "Medvedkin, Vladimir" To: Robin Jarry , Vladimir Medvedkin , Stephen Hemminger CC: =?iso-8859-1?Q?Morten_Br=F8rup?= , "dev@dpdk.org" , "Richardson, Bruce" , "Marchand, David" , Thomas Monjalon , Konstantin Ananyev Subject: RE: rte_fib network order bug Thread-Topic: rte_fib network order bug Thread-Index: AQHbNOW49LnxaTmyXEa7N7B1+RwFLbK1B5+AgAAuDACAAGQZIIAAyBSAgAAxewCAAEfGgIABeDQAgAAOQYCAAAnygIAAH2GAgAMPMACAB+9iAIARKbeg Date: Tue, 3 Dec 2024 14:37:18 +0000 Message-ID: References: <98CBD80474FA8B44BF855DF32C47DC35E9F8CB@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F8CC@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F8CD@smartserver.smartshare.dk> <20241115082046.46af52d5@hermes.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SJ0PR11MB5772:EE_|DS0PR11MB8114:EE_ x-ms-office365-filtering-correlation-id: f491c339-e4cc-496d-f26f-08dd13a7fd56 x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|366016|376014|1800799024|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?vYQTWNh+WO9oBmN1Q8hrgyL+v8hCDfZ5u23F/Dw59+b/C8Zp3sAeYwLVIX?= =?iso-8859-1?Q?aijBWXss+5nn41TZAwb7ySxNpFeHdjP3uy3uDZ8dppgbonLSs2mxeIQOMI?= =?iso-8859-1?Q?h0jYkpeyaeM7pSoT0jGo6Oo6ycUr/VMCankKbxf2pvgGqfuh3Y2Ggdnhrp?= =?iso-8859-1?Q?45IBhULEFhJjLi8mHm8UaKjJq/Fwqk0MqBBDJ+65VC+gvG1huRIh4E9qIL?= =?iso-8859-1?Q?gKWhHl20RxnOc2a0J3xdBljZnM31rLObPTxz/ktuv5b8Jyjlkd3TXMhGub?= =?iso-8859-1?Q?lt6xUGQLA5J2PM40xDZHTdct61z8qKjpdRSgNZsQdBBfSE63FQJJbmp5gs?= =?iso-8859-1?Q?IOj1jUNXoj0q376lS3CGRAUYcq5h9tsrL0Y+GFQYSuiCsc0w7qZAABx5ix?= =?iso-8859-1?Q?KwIxe+VWUatMYYhk9zp6zPQBk0MRcEfY7WjZFCRhNe/sj42rFkkO1qLyBO?= =?iso-8859-1?Q?+X28MU/5gNidX/0B0Hd87ne2+EbDdIUdya6VnCxPtM5QtO1llm/h4b/vwK?= =?iso-8859-1?Q?u4GgljJyEpDTrLxnuaqWlsi+p7nBE/iEiS9LL52CxrqIko4vVsxdNU4mng?= =?iso-8859-1?Q?brf09jqG3K2AEOye1NfEXfenmgSCfqsnJzQcx7WHGSTk2h3uvTEY+D+qGP?= =?iso-8859-1?Q?u8r/xQabsR0BOS4sbiTh4ekOPwc+8KSKMZdSOuhISxyoNiS8NaJg62uFbZ?= =?iso-8859-1?Q?22WALhrFDSsWD6SKxF7siQ04PZeO3fon/IBqoIh7JVv+nDTG6dI0JECVlB?= =?iso-8859-1?Q?CorCLDDmtMtF60zxIlSpOww7yheCTo17nxEiElIjJRPQ6yma+ptSQCwGpE?= =?iso-8859-1?Q?XbD/2ST2NGc+Y5C2oI6y1cOZzUeiQx++z/MbLvk9+7kJW2U/vncAmSjfdu?= =?iso-8859-1?Q?S2bjvwu1FBBd2/5gHZvWvXV/sq5JWQ4fWcFoB0Vr4tbTBlzwIML3dL8Bqa?= =?iso-8859-1?Q?T3jpnw9o8IlyAmHnMKrux/SJBvyeX3+gyCosbmNJ7Bs5rF2SFFGXpXjPm0?= =?iso-8859-1?Q?lt8eFB3GUCQXLkXI8d99iIlt5+QvHOeYq2tja2HUSFhTWWKse3GzPQEw2J?= =?iso-8859-1?Q?jZ4RepKkPRUcInvXH+kQEAHgVT04YvWRRk+2T3zIiR56Ebk0RduRKGJrmN?= =?iso-8859-1?Q?u2wwnPJHYAk5fqlG29Tdp/wdO/wSx+0oNnFXnEBzCzgI/dJXRF7ME4yz63?= =?iso-8859-1?Q?qEbbJNzgY4R+U5k5KwCfleqdGqTtOhgq/bnSwQoFGFL2/nER6ciXmihpQ3?= =?iso-8859-1?Q?70vmY+dAmm9OGJWd0wXOV3tfxea6D0/IHvgGcwc/xVCtLI6ElvTmSBQSv1?= =?iso-8859-1?Q?Rulz6LxmPTBMT/Rz2UpRel+cRuCcix8h89UJ8BPztRjqtbihyhDFUZZNjg?= =?iso-8859-1?Q?ah3GGDhJ4A8PJzT34hG8e4TTAoZkvP9nnTw9UHkmxiRsLndzbMsoQ=3D?= 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)(366016)(376014)(1800799024)(38070700018); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?TM4dZ92E3yu9gdc//ukCg7YCEjKalu37Ugg2CWQGcrCQ6yJQTWI8ySdE+C?= =?iso-8859-1?Q?cwcl5c57uF4n3QV7a7cvdeuUSyVWsKE57OX/0FRfJJHpj1NxvtJnW2DjIY?= =?iso-8859-1?Q?bSdZ3KiaQ4tiFCmoaTibxUMG1CVxE411jVKOAuf3MfRBedsqK8UPyBYxDq?= =?iso-8859-1?Q?OvpkjuKVKFUVhzb3L0DPgCW0t+y/ePbkISSLyWryjySk4J0ZCGUPa9z5Me?= =?iso-8859-1?Q?Nso1a5sL672n/T0Vr2zdG0obZy7A66o5NbNkCi/cEmhx+9+2plVqJQgWJ6?= =?iso-8859-1?Q?ucKFHk8aD+gSctuDqUptd56rVUXwX9Vo9xA4s6jT2Jpj0lUH1/HMCQIwwO?= =?iso-8859-1?Q?GVa5PI0r+kVO4fcffJjyLL9gHUU8QfOy3+ykIjocnkpa66hSdzhTBtu3G2?= =?iso-8859-1?Q?GiltqSVVX+uxOTTfF3+WlDQ8CEfueGnZWcRyVHqHa1xAC01o4g0rQwcCGn?= =?iso-8859-1?Q?6aPmJTb8Ko9jjBd+4SfV6D50lUlWX2ZLwkmYzScJUoakrafUjhwtOZ0dLc?= =?iso-8859-1?Q?LZi4cJaiiRIXhAXcmyykbWP8Yb8A5nevE9CQ20iBne+0qU+rh2Ce+yAtMZ?= =?iso-8859-1?Q?FHLAxR112x6rfop5vk7lOiqXtO5KcUHSZPukzFbewOzyAzb3h9HM1tLDZ4?= =?iso-8859-1?Q?tp0MNCkUxP7pH8V9z+aPDzpDa+lRANLHc+jwINsYmjw5Li547qgNFK5qDy?= =?iso-8859-1?Q?bmttmJSW6R847L9K/YGDaocw3exsLK2K0jeEur3OlU1DX9k7JgQ6O0WWbB?= =?iso-8859-1?Q?TK1Ozccv1KVyHzLGEg84TzPYqWATGujyQJ5Sx7Ko14shVKh/4/T6Ob1cVf?= =?iso-8859-1?Q?Mv9J1HqGIFt38BjB0QrwLeO4zGFM2DdKvD9JbNY1L8aJR5BC8NzzfoTHiN?= =?iso-8859-1?Q?f4/OUtEa0g/kk8aN8/UDYLQBLtpbVlAx1SRkgfxAjgfhq1T/VJHaMYDLsh?= =?iso-8859-1?Q?v9DW2Gzg6hRwyS+L/P2XLIKfI7n2vflorkbQpmlKT7k2/9B+apNu4v0KGo?= =?iso-8859-1?Q?3bWicZ+LWt2S33Kpo06AblIM0VE3FgfmJPoR+ow3PP4IpuosW5AoPkTS5Z?= =?iso-8859-1?Q?GWXx2pTbbCXsmWrOk3mdoH+tMACxnSxZFX+pc+5bdrxBjR8zCLNa1+egFy?= =?iso-8859-1?Q?lG24Y8CCKe7Ix2Tt6KKE8M+KgBqv1xlzATs0MGxr9CXBNGTZ/D34jX/imd?= =?iso-8859-1?Q?1WieIjh+JVXRj6irdecHY8dxvkG8j9usSXt4VfM0yH3bhfkQhi1v2XIkfx?= =?iso-8859-1?Q?eCv0ZfAQQYO5yFfdyNjZusZ4lzZPl6uXKvjWwwb+41DjK1mWaAKL82mvdg?= =?iso-8859-1?Q?V7uGWgL0H92nQfNhu9j7LyPet5HP3uoWZd9xKJjiPjdmkO/Zwl3aypl9x5?= =?iso-8859-1?Q?m2xq6aWMPXLxEQI0bnn/yKZC7aCw6BQPhGSmILvhFg1gDhtZ2/5+cuisPK?= =?iso-8859-1?Q?hE/MmfP/7eMj/CMfvXR5Y+Jkg3xBqFfApDvB+pJL7pOu+9kfedcNz/MEIq?= =?iso-8859-1?Q?hTKX7JdS73oeMAb8UlgqrflirU8gVRl1vnHeK71aSGOfz6djbzHhyipzqI?= =?iso-8859-1?Q?FzYlGu3yL+5sa4kRSzqNvQsWSp02eo6nWkV/Rdm+MgTXqGj7paT2Nv+nPB?= =?iso-8859-1?Q?QJZgMgzhNTOHbgOd/8+5J0vmCKbZN4jn7G?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR11MB5772.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f491c339-e4cc-496d-f26f-08dd13a7fd56 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2024 14:37:18.7068 (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: Vzuhv6yJ/7Jjmm+8okHukQI+C12jPA57gZOptbMMTTxqzkEdkRTO8L4iWIUWpBDNRDjVRX89EVSMzJGs43u/tmMqDJLbYOesrcpAhXyMQJs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB8114 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 Hi Robin, I like the second approach with one more suggestion. It would be nice to ha= ve 2 different flags - an existing flag (RTE_FIB_F_LOOKUP_NETWORK_ORDER) fo= r the data plane bswap, and a new one for the control plane operations (smt= h like RTE_FIB/RIB_F_CP_NETWORK_ORDER). Also for user convenience RTE_FIB_F_NETWORK_ORDER may be introduced as (RTE= _FIB_F_LOOKUP_NETWORK_ORDER| RTE_FIB_F_CP_NETWORK_ORDER) > There would need to be an additional RTE_IPV4_BE() macro to declare IPv4 = addresses in network order. This may be useful as well Thanks! -----Original Message----- From: Robin Jarry =20 Sent: Friday, November 22, 2024 4:15 PM To: Vladimir Medvedkin ; Stephen Hemminger Cc: Morten Br=F8rup ; Medvedkin, Vladimir ; dev@dpdk.org; Richardson, Bruce ; Marchand, David ; Thomas Monjalon ; Konstantin Ananyev Subject: Re: rte_fib network order bug Vladimir Medvedkin, Nov 17, 2024 at 16:04: > [Robin] >> I had not understood that it was *only* the lookups that were network=20 >> order > > [Morten] >> When I saw the byte order flag the first time, it was not clear to me=20 >> either that it only affected lookups - I too thought it covered the=20 >> entire API of the library. This needs to be emphasized in the=20 >> description of the flag. And the flag's name should contain LOOKUP=20 >> [Morten] > And/or rename RTE_FIB_F_NETWORK_ORDER to=20 >> RTE_FIB_F_NETWORK_ORDER_LOOKUP or similar. > > There is a clear comment for this flag that it has effects on lookup.=20 > Repeating the statement with an exclamation mark seems too much.=20 > Moreover, at first this flag was named "RTE_FIB_FLAG_LOOKUP_BE" and it=20 > was suggested for renaming here: > https://inbox.dpdk.org/dev/D4SWPKOPRD5Z.87YIET3Y4AW@redhat.com/ This is my bad then. I had misunderstood what this flag was for.=20 I should have been more careful. You had clearly stated that it was only af= fecting the lookup. > So, feel free to submit patches adding this feature to the control=20 > plane API, but let's consider: I can commit to working on that topic if we can get a consensus. In my opin= ion there are two different approaches: 1) Change all IPv4 routing *APIs* to only use network order addresses =3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This would make them consistent with all networking stacks (linux, vpp, bsd= , etc.) and would avoid confusion from users (like me) who naively used the= se libraries with addresses generated with inet_pton() or addresses taken v= erbatim from IPv4 packet headers. More importantly, it would make them consistent on big-endian and little-en= dian architectures. Currently, the same code could work (without any byte s= wap) on aarch4, but would not work on x86_64. It would also make them consistent with their IPv6 counterparts which do no= t require any byteswap. This would be a drastic and breaking change but I think this would be the b= etter solution in the long run. To ensure that potential users of these libraries will not miss this change= , the uint32_t parameters should be changed to a rte_ipv4_addr structure th= at follows the same idea than rte_ipv6_addr. We could also simply use rte_be32_t types everywhere but it would expose po= tential users of these APIs with bugs that could not be found at compilatio= n. Internally, all these routing libraries would continue using host order int= egers, the changes I am suggesting only affect the public API. 2) Implement network order via opt-in flags =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D This would allow the same thing as solution 1) but would keep the default b= ehaviour which I find confusing and inconsistent with IPv6 and with all IPv= 4 networking stacks that I know. The other concern I have with that second solution is that the public APIs = would continue using uint32_t parameters which would be only correct when t= he network-order mode is not enabled. On the other hand, it does not break any API for users that do not use the = flags. There would need to be an additional RTE_IPV4_BE() macro to declare IPv4 ad= dresses in network order. Any thoughts?