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 0DBB245679; Sun, 21 Jul 2024 23:51:37 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9C1AD402B0; Sun, 21 Jul 2024 23:51:36 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id F371240270 for ; Sun, 21 Jul 2024 23:51:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1721598694; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5FaQCZg306qH18esRk3L7hLnBDT6zrBonWRwfxNsV9s=; b=AWFZxeXakhe6yxw8C2/OpFr8PnKT+XtT5k4tHn6bIgLWV18UyZqqka1b0wgZhzuPaVf+Tm UnWE3vH9sTYLgslSyL/e4cqFiz50c59O/G19CgYRl3DLnopxQNVw6s3GveGIgJKf9GU9W8 ht0j1wlEJiy6QUC5IVa7LQN15s/aBuI= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-601-ovUFJMcGO2GncdFDdzBzPA-1; Sun, 21 Jul 2024 17:51:32 -0400 X-MC-Unique: ovUFJMcGO2GncdFDdzBzPA-1 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-42726545762so25928445e9.3 for ; Sun, 21 Jul 2024 14:51:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721598691; x=1722203491; h=in-reply-to:references:user-agent:subject:to:from:cc:message-id :date:content-transfer-encoding:mime-version:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=5FaQCZg306qH18esRk3L7hLnBDT6zrBonWRwfxNsV9s=; b=X2K341akq887D3305p1m4+vk3mc0qZRJ7ivxAbktM5olv8ni2H2017T5q5svk5ojsN OWfUVYj/utU/wNBYZQZAyVtgNoIXvi55Aq81qpOnUZzMaLLs13LKBoe4fM+CSi9UCEQm 6NjE0jzH6xqTbK8orb87DKWDFCmTP8m7Nqkoz6fPYA19yS5lmMd1JMNhNtQdPxY+secu vnqsNi38knWuW4APd7fa6cFMks9VYv3kwUkGN1PqHJ8XoAfxgqQoQQ7UQy5FlncADO8i ea5/HIer0eZVjiS2oNGOUhJPZ50qaTmI86qk9ekzBzaYwzXfsHTlE1u3yeA3rrl13M1W yA/w== X-Forwarded-Encrypted: i=1; AJvYcCWoeVfuQDeNSXWNun/M4guPgRGIGxcATxBZh72RiBsPmJRXqITJZCcPatnRn7zXWx96KgYvAoVpgG171iQ= X-Gm-Message-State: AOJu0YxJ/zXFxS1R1pR0n9uwR7CTTsMlUtum2BsuIC2PvcAc984BB/Ct q9R6WimJkoaFdIqeZaJsuOmXJrhYRWhVMeA1fFtX4PJAtA0NRoK+4b8oKPYHGq3b6o727c6DYW3 1LMVoFNCraRiOWRkPIllTAl/gJyS3btPq81p9U6CA X-Received: by 2002:a5d:4652:0:b0:367:9960:d4dc with SMTP id ffacd0b85a97d-368317bc4a0mr9959785f8f.65.1721598691390; Sun, 21 Jul 2024 14:51:31 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGxWjY0fqCbE++nKXCNjMB9jV52cZxyY07vXKOl8VYZ0jOFhac8IuKuZpSY3DFs6JbDjMHZRQ== X-Received: by 2002:a5d:4652:0:b0:367:9960:d4dc with SMTP id ffacd0b85a97d-368317bc4a0mr9959747f8f.65.1721598690941; Sun, 21 Jul 2024 14:51:30 -0700 (PDT) Received: from localhost (2a01cb0003516600d9d313ed6b23ad48.ipv6.abo.wanadoo.fr. [2a01:cb00:351:6600:d9d3:13ed:6b23:ad48]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3687868490fsm6848904f8f.6.2024.07.21.14.51.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 21 Jul 2024 14:51:30 -0700 (PDT) Mime-Version: 1.0 Date: Sun, 21 Jul 2024 23:51:29 +0200 Message-Id: Cc: "Vladimir Medvedkin" , , "Konstantin Ananyev" , , "Sunil Kumar Kori" , "Rakesh Kudurumalla" , "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" , "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" From: "Robin Jarry" To: =?utf-8?q?Morten_Br=C3=B8rup?= , "Stephen Hemminger" Subject: Re: IPv6 APIs rework User-Agent: aerc/0.18.0-5-gd32d93015ed7 References: <98CBD80474FA8B44BF855DF32C47DC35E9F5AB@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F5AC@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F5AE@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F5AF@smartserver.smartshare.dk> <20240719100701.7e7dfc7f@hermes.local> <20240720132619.4ed7a53a@hermes.local> <98CBD80474FA8B44BF855DF32C47DC35E9F5B0@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F5B0@smartserver.smartshare.dk> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8; format=Flowed 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 Morten, Stephen, Morten Br=C3=B8rup, Jul 21, 2024 at 18:12: > If the IPv6 address type you tested with was a struct containing=20 > a union of different types (other than an array of 16 bytes), then=20 > those sub-types made your IPv6 address type non-byte aligned, and=20 > caused padding when used in other structures. > > Please try again with the simple array type: > struct rte_ipv6_addr { unsigned char addr_bytes[16]; }; > > This should not cause any padding when used in other structures,=20 > except if used with alignas(). Indeed removing the sub-types in the union removes the need for strict=20 alignment and packing. Too bad, I found these intermediate integers made the code a bit nicer=20 but I can understand that it brings a lot of trouble down the line. NB: I tried uint8_t vs unsigned char, it makes no difference with=20 implicit casting to (uint16_t *) or (uint32_t *). Explicit casting is=20 required anyway. > If you are introducing an official IPv6 address type into DPDK, its=20 > scope it not just the FIB6 API. > > Both Stephen and I can see that - in a broader perspective - the=20 > packed and unaligned constraints are unacceptable for performance. > > It might not be a problem for the current FIB6 implementation, but it=20 > *will* be a problem in many other places, if converted to using the=20 > new IPv6 address type. > > PS: > I do consider adding a dedicated IPv6 address type to DPDK an=20 > improvement over the current convention of using an uint8_t[16] array. > But we need to agree on the type, which must work optimally for=20 > a broad spectrum of use cases. Otherwise, the new type is not an=20 > improvement, but a deterioration of DPDK. OK, I understand the stakes. I will comply and propose a simple struct=20 without any packing nor explicit alignment. struct rte_ipv6_addr { union { unsigned char a[RTE_IPV6_ADDR_SIZE]; }; }; I have left the door open in order to ease adding sub-types in the=20 future. Indeed, lpm6/fib6 tests rely on literal definitions of IPv6=20 addresses and union types need an extra set of curly braces for literal=20 definitions. If you think we will never need to add sub-types, I can get=20 rid of this. It makes no difference at runtime. About the timing: when should I send a patch to announce IPv6 API=20 breakage for 24.11? Thanks for taking the time. Cheers.