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 438244564F; Fri, 19 Jul 2024 12:11:15 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6C1CD42F4D; Fri, 19 Jul 2024 12:11:14 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) by mails.dpdk.org (Postfix) with ESMTP id 8FBED42E7B for ; Fri, 19 Jul 2024 12:10:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1721383850; x=1752919850; h=date:from:to:cc:subject:message-id:references: content-transfer-encoding:in-reply-to:mime-version; bh=WwU8VO+ctegtwlS33HS/Ltc8CLwt74d5P3a2fy/LTFg=; b=eGc8JoxxpiDRkQSciK9v35Qggpfm7LgL6wW5aEa/FB6M5eTZCUOsg7BC n1MEW281wg+NSDXvyP8Z8uUw9cQaKhbVt2sz2Ap/Z8IAszVBcvxJ38mKA 8b9lTl5IgTVAis72ecjPHo/YK6PXRrHDw5hTu8xeM3C6W5rjXin/An9l6 hrQxof473JSOFyXLk5w5ehNgGThTtXDi4Z1EMgndDO/XJmWMNTPuFfqaB HiodaRmp441vsnP13nVPXpL+EloGia500LRrBkX/RpbxDZNCFWYX11U7W CUo13GOB7mYCif/QGoQkl64In6eMUrUSSt940XjQ8me2N6C/7DZ43TwMc A==; X-CSE-ConnectionGUID: 1O+6E04OQbeD2277L0iscA== X-CSE-MsgGUID: 2DS90sOVRgemwdocu3C+rg== X-IronPort-AV: E=McAfee;i="6700,10204,11137"; a="22799353" X-IronPort-AV: E=Sophos;i="6.09,220,1716274800"; d="scan'208";a="22799353" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jul 2024 03:10:49 -0700 X-CSE-ConnectionGUID: ACPbXzJYSjCiARZiPyqZBw== X-CSE-MsgGUID: ipST8t11Q0Gh4uQh6L4b+w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,220,1716274800"; d="scan'208";a="51086033" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by orviesa009.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 19 Jul 2024 03:10:49 -0700 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) 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; Fri, 19 Jul 2024 03:10:48 -0700 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) 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 via Frontend Transport; Fri, 19 Jul 2024 03:10:48 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.169) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Fri, 19 Jul 2024 03:10:45 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nsnFTRT0Z8Rq2WJ2fNwg81Ygn0EwfVid3VQhD29RfSPnnbJAwr3O5wbOjQSLljwowNU50Qjj2FVqByVnB9BUqCld/sUERkR4XzEI4sZD1muDHdwSwCfUjOJZHePGLOEnL9yyR1ecAEEAeV5eqyzHXx0/kLeDylGRN2yJfDjrxSr8Z78in0KjZzq9S7Uyo6JOVoI1s/V6Bqd6jXQv970u8e2WyxtBynpbqAgQJChCX3m/UlDRKxFUhLBoK6o0Kddo7cUtmQzngAtqoqokTbQZgvCc+NqLteul4KkAICX8I0+WFZ0On5+lMrZkBY4HDZNJA9TU4OMUBCOgcchJJ145Zg== 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=xIKq5ZRUaHaSkPkBP/AOQhiqY0aFI4bBPwT7Cx1tRV8=; b=YJzfR6hBxsg+Da5YwIrXwy4V71O4E8asfke6Sjdm0Ec4IbROhBFVxVwlyP+93pCgQVH/bSglYYWfAb1o1mN0m294kJNeEcAAayVxIg5zGA2koZ95/+i2fa0MkEMgSyN9DEoNGtXZleYuQACAv7xOSGCA+DpG9wpT+yExNz+n5AX92S5/3N0SM06dCCuF5SqArMhrYWPBtC02UX8z190Sd+OEQ8zY5FjIuS1sDdpDE4JgVX8w9vkm7qMcDdE2rT+FkM60DJmGhA+KhM5ZEEIJXCvpGv6xjZNuiDaoF7g5ze3V/uTW/EhqBSp0IfesCEBFiPQ5eDSfUW0OI90X6KAsEw== 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 DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) by PH7PR11MB7432.namprd11.prod.outlook.com (2603:10b6:510:272::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7784.17; Fri, 19 Jul 2024 10:10:11 +0000 Received: from DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::f120:cc1f:d78d:ae9b]) by DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::f120:cc1f:d78d:ae9b%7]) with mapi id 15.20.7784.016; Fri, 19 Jul 2024 10:10:10 +0000 Date: Fri, 19 Jul 2024 11:09:59 +0100 From: Bruce Richardson To: Robin Jarry CC: Morten =?iso-8859-1?Q?Br=F8rup?= , "Vladimir Medvedkin" , , , Sunil Kumar Kori , Rakesh Kudurumalla , Vladimir Medvedkin , Wisam Jaddo , "Cristian Dumitrescu" , Konstantin Ananyev , Akhil Goyal , Fan Zhang , Yipeng Wang , Sameh Gobriel , Nithin Dabilpuram , "Kiran Kumar K" , Satha Rao , "Harman Kalra" , Ankur Dwivedi , "Anoob Joseph" , Tejasree Kondoj , Gagandeep Singh , Hemant Agrawal , Ajit Khaparde , Somnath Kotur , Chas Williams , "Min Hu (Connor)" , Potnuri Bharat Teja , Sachin Saxena , Ziyang Xuan , Xiaoyun Wang , Jie Hai , Yisen Zhuang , Jingjing Wu , Dariusz Sosnowski , Viacheslav Ovsiienko , Bing Zhao , Ori Kam , Suanming Mou , Matan Azrad , Chaoyong He , "Devendra Singh Rawat" , Alok Prasad , "Andrew Rybchenko" , Jiawen Wu , Jian Wang , "Thomas Monjalon" , Ferruh Yigit , Jiayu Hu , Pavan Nikhilesh , "Maxime Coquelin" , Chenbo Xia Subject: Re: IPv6 APIs rework Message-ID: References: <98CBD80474FA8B44BF855DF32C47DC35E9F5AB@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F5AC@smartserver.smartshare.dk> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: DBBPR09CA0037.eurprd09.prod.outlook.com (2603:10a6:10:d4::25) To DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7309:EE_|PH7PR11MB7432:EE_ X-MS-Office365-Filtering-Correlation-Id: 6dda22d3-9f6e-4ec1-5b36-08dca7daf8fa X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|7416014|376014|1800799024; X-Microsoft-Antispam-Message-Info: =?iso-8859-1?Q?IA5Mrk6p7/tWfOPWVMOwWcSPxChClJrArG52RaWWqye1/Gxz0HgoGYCR6n?= =?iso-8859-1?Q?01plKagVjUH4mvHKhZWsloms7mwjS2ZZVkuOwjg2ZyoJPCLmc6SejrS+4A?= =?iso-8859-1?Q?BqmXTF2UUrydTGhB5BolF2PMYbfGCLFWXQy1YbOrQEFoeJ3cS3dUDY2HWC?= =?iso-8859-1?Q?KnM2KEcKrQ54/+lCiOGW9dR3bSMX3XJ+aFGZ8Ka3GOYkuG73GhmRskrlLB?= =?iso-8859-1?Q?jjfNUQwKZM8u6MfP+J/sY17n+sKRrejHJ0nqgFWbtQFAibsl0BLJbOz2sX?= =?iso-8859-1?Q?x2qprC68zlcKDwhnJdX35zZv9G6wjBRgR4JTvJaUYQrkeMKzBCzWlrNgZd?= =?iso-8859-1?Q?Lpl9LwkWZE4CZXKYTHJ8dnCy8tGlhpxv87JWCqt0cL+OpOTCb8eJJyFYDr?= =?iso-8859-1?Q?pWy9C6F/aTFE9AQApIEq/BETpYHwVmbGXjofB2TOV4gSGuJBI4vSrBD5mX?= =?iso-8859-1?Q?noLMcD9JJawekprEqHM9l0yh9bjzEyR4jTS/Dxe8c5URXsGISLn9CVz0Z8?= =?iso-8859-1?Q?a9QRkkVrtEGImFrSumCqjrRAINfLDu6bSBhGrmLUFbfMnLrXV0HG7gNJfo?= =?iso-8859-1?Q?bmpZkDZTSydNkyuzSnrP1SpezRo+MnrqvTtTEzphAc1EJOQeej7QXgdMpk?= =?iso-8859-1?Q?159frKfL2gBo96HiiNnFJh+BqBEnNMFdKh9z5tjt/JlvapXEnCeO8d9F2/?= =?iso-8859-1?Q?Eqnb5Ss2feJSv6s9nfUgibuVbo9KxudMuP7qG5PybSNHwzlygvXeAnB5xH?= =?iso-8859-1?Q?gyDKVdjbHvs0aEva63EWGnvoY4suFMrS9HvbQuuttUPgFvxJyGr1s9xUAz?= =?iso-8859-1?Q?R99itEQZGGMGKrg8o4hZg78dADrazCQjCwSbZJL7l0Y+Dc6ZX1BZY1YwIi?= =?iso-8859-1?Q?yFZQdZrJWznrMH9x+mNvSnxdYMCVLu+rB+5B2rmalRdBKl4Z0nT/wScznN?= =?iso-8859-1?Q?tmoX1HbVU1UGb3Idx0Er9GThtEZAMAn7mduLI4TOu/Y4JWdOawk8zd5+1I?= =?iso-8859-1?Q?XiSREpThqo5pF4hR1aN22BYBIBlF5toLj0ooBP6ei3pmBfj/4xz+VzwMgq?= =?iso-8859-1?Q?t+RsznQsQB4EQV8SWP6ktukBRYoTscIbxDKKfLTSJuIS5tBQCUkVTcaupM?= =?iso-8859-1?Q?XfbqvbmODktePAbTM8ni/JU2JHj/ueUI7XYdF4+2YGGkgb2f4RFp8Zkz1T?= =?iso-8859-1?Q?jw6nL2U+y98Pw32bSIBSTQJ7ZuM4YaFI8SnSfw1dJ3RxxCGd1zB8xtMoAp?= =?iso-8859-1?Q?AdlFbUHS4yPGgxPkNhN7l4fWaOdKvyLFEhtpYFnKnvYEGoNoWD7/U6JZR2?= =?iso-8859-1?Q?g77v4Qv9/soBM1begRSF+wgP4QqzkoBKT+/PGVj/6ba8AGUvS/ZGuajYRN?= =?iso-8859-1?Q?Gu9xxfxDgt5HWuArleZo2L6zHED3CVNQ=3D=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS0PR11MB7309.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(366016)(7416014)(376014)(1800799024); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?AsZe+S9XLjDtCAt+oLVQOkk5BLS4JQ/lpQT1FBMJQ8q1oR3jnJR02gAAHP?= =?iso-8859-1?Q?MxakILexZjoLjp7C4qT/oAE4FVdPg+0gMRcKZ0MWLgvo5/8MPTzSQhL9pS?= =?iso-8859-1?Q?Y5W+y1KNgnA19oHYN7AYgQVgcXKQpszl0MH+02QXN83Ee5G9G1c3mE3hAa?= =?iso-8859-1?Q?kOR/9SMWb+by4Z/yfL8oeiRSN/vgvUHzYymUxnQoiO1VbUdKXgOfqFTnbx?= =?iso-8859-1?Q?AmQ3xZ6vvCLm80vrY5Aa7Ieq2XFHTT9xS8CGYM/MKr3ejhq9UMozCK480r?= =?iso-8859-1?Q?SAhsTBWJXpBZ1jmr7uJkQnYry5zf1OUvDvxls//VFsqNqQIRSZtTrUPsCK?= =?iso-8859-1?Q?kA7pOxQM9oGhfgnDrSK9SVaSMFAjCw3k43lpRBI7+KeZVkEwuJrm/f6jDP?= =?iso-8859-1?Q?VJP74SKJ2rc1IztHsyhFUu1LGSsPKhXH/peX7Aym00LSMQbC9T5ExFOzLi?= =?iso-8859-1?Q?bt8oQoww+AJhWHxx03UHg03tLWYVfiYVrNd66eFVDOMn29lS9RatfxCwKO?= =?iso-8859-1?Q?MokziJGIckWe9ajmWRHoe0FcVr4SSGoYRzRvJuEwGWqo0V9XWPpY+ElHYB?= =?iso-8859-1?Q?TGKZnPfJo/Afd/JVfgYhiqpijPSAW8HFHnWox70GUYQU7g8I65lVr9GWcH?= =?iso-8859-1?Q?OeMcPs1/Vwa0MeWqI+6zcRkXc9ZWzEqxBFDYeISWKSG4upgRFaxb8U2sAo?= =?iso-8859-1?Q?Rjr05RFHa+x7jIOp9V9F+U1TJo6vv/QDGBkyaqg3nON9LbVamklVCbLKwP?= =?iso-8859-1?Q?DxKohn/ykrsGS53hsyL2CPq7fhd36bTDz4RjHqKl1zH37iA/gLPof/5V0X?= =?iso-8859-1?Q?Ao9gXQWu+NkcIh60utkFUGPXh5byDszXmyEbo9cHWLcC38fwMcy0sjEnlS?= =?iso-8859-1?Q?9g46DI/tshOiMqwBhc84TD4fcCnKb1hL5+bUaWM3M1uJObDtJXraCSR11I?= =?iso-8859-1?Q?5ha2Bh8bvOtf7zl/vpohXdZmCZpG6LDhef1/WRGxpahDMjqUmgGh9FoKKV?= =?iso-8859-1?Q?cVyBUJGo/NLddH0UNMgiWoP3iO3t82expoB6r/s1BniswaiiOOmFms4gch?= =?iso-8859-1?Q?J/LCvobzQk5omrh4SWo2a3wDt41V546WTDDBlzV804FWRNpxBEd/tqK5Qb?= =?iso-8859-1?Q?BbosAP5yNnwQ1FcibzM4n8GY25L5+5mnQB8+wtjL/J9ePuhE0ifJSWqB9J?= =?iso-8859-1?Q?0LwAuIjVfaWBAD/C71NUoQQgiSF+AOAw5NUdsh3AbgGQRxndapCj7xrmJz?= =?iso-8859-1?Q?l0KDJfhrXLkXA9Frcdme75XC+SbLVSnebF6/Ocaup2Cee5ddjs2tusNWFv?= =?iso-8859-1?Q?zDGPX2Q6Qy1n4Oszrg3/qi1PEmFtPFBzsYESRVJp5fOa1G+CjEMIS4O2pq?= =?iso-8859-1?Q?IiQA4tJzPUdHGeahJi6urbyarYCSOF6FyCZjSwnpjpr47tOlgq1On4vQtd?= =?iso-8859-1?Q?XTbW791XBB8XdNTupabSpbaFKReJsoNNImF2y2GWhmyk9UrwWYuG0YPNos?= =?iso-8859-1?Q?ICRz7N5MOQ19UUpi+TN4MmjeHKQIKY33WDEjHGdLHevbKTmrdpD9ztrEar?= =?iso-8859-1?Q?XOSyIUP13o3kxXIhoSRWSeoRxBVL91E64j4Z847jNaxz5m5QyYhBC+DOYI?= =?iso-8859-1?Q?3olGeS1jDfvINyVV1L5ScdpDY9kIuBqKepJ5+bnAxM1ur8+UQk7cycvA?= =?iso-8859-1?Q?=3D=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 6dda22d3-9f6e-4ec1-5b36-08dca7daf8fa X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7309.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jul 2024 10:10:10.3658 (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: EKdxKz83NmMNje7EKIgxPLTxrwm39VkyO1ZdWZjRi+mo5X8WzX2ZVHAnrZAv/sReApaQsInJvk/85PM8EDWBVmqN8hn+3OBtdOMppfWC3IY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB7432 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 On Fri, Jul 19, 2024 at 12:02:38PM +0200, Robin Jarry wrote: > Morten Brørup, Jul 19, 2024 at 11:12: > > > Vladimir Medvedkin, Jul 18, 2024 at 23:25: > > > > I think alignment should be 1 since in FIB6 users usually don't > > > > copy IPv6 address and just provide a pointer to the memory inside > > > > the packet. > > > > How can they do that? The bulk lookup function takes an array of IPv6 > > addresses, not an array of pointers to IPv6 addresses. > > > > What you are suggesting only works with single lookup, not bulk lookup. > > Indeed for bulk lookup, you need to copy addresses on the stack. > > > > Yes, my intention was exactly that, being able to map that structure > > > directly in packets without copying them on the stack. > > > > This would require changing the bulk lookup API to take an array of > > pointers instead of an array of IPv6 addresses. > > > > It would be acceptable to introduce a new single address lookup > > function, taking a pointer to an unaligned (or 2 byte aligned) IPv6 > > address for the single lookup use cases mentioned above. > > That would require two different IPv6 structures. I would prefer it we could > avoid that. Or the unaligned lookup API needs to take a simple `const > uint8_t *` parameter. > > > I'm not worried about the IPv6 FIB functions. This proposal introduces a > > generic IPv6 address type for *all of DPDK*, so you need to consider > > *all* aspects, not just one library! > > > > There may be current or future CPUs, where alignment makes a performance > > difference. Do all architectures support unaligned 128 bit access at 100 > > % similar performance to aligned 128 bit access? I think not! > > E.g. on X86 architecture, load/store across a cache boundary has a > > performance impact. If the type is explicitly unaligned, an instance on > > the stack (i.e. a local variable holding an IPv6 address) might cross a > > cache boundary, whereas an 128 bit aligned instance on the stack is > > guaranteed not to cross a cache boundary. > > > > The generic IPv4 address type is natively aligned (i.e. 4 byte). When > > accessing an IPv4 address in an IPv4 header following an Ethernet > > header, it is not 4 byte aligned, so this is an *exception* from the > > general case, and must be treated as such. You don't want to make the > > general type unaligned (and thus inefficient) everywhere it is being > > used, only because a few use cases require the unaligned form. > > I think the main difference is that you almost never pass IPv4 addresses as > reference but always as values. So alignment does not matter. > > > The same principle must apply to the IPv6 address type. Let's make the > > generic type natively aligned (16 byte). And you might also offer an > > explicitly unaligned type for the exception use cases requiring > > unaligned access. > > The main issue with this is that you would not be able to use that type in > the IPv6 header structure to map it to mbuf data. That leaves us with two > options: > > 1) Keep a single unaligned IPv6 type and hope for the best with > performance. It will not be different from the current state of things > where every IPv6 is a uint8_t pointer. > > 2) Have two IPv6 types, one 16 bytes aligned, and another one 1 byte > aligned. The main issue with that second approach is that users may get > confused about which one to use and when. > > I would prefer to keep it simple at first and go with option 1). We can > always revisit that later and introduce an aligned IPv6 type for certain use > cases. > > What do you think? > +1 for option 1 - keep minimally aligned type. Having two types would be confusing. /Bruce