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 6A66A4564F; Fri, 19 Jul 2024 13:09:47 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 59622427E6; Fri, 19 Jul 2024 13:09:47 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 54B4840E12 for ; Fri, 19 Jul 2024 13:09:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1721387374; 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=8ElKxDQ1woaaTVPZ0ZTZnaKm6t22BOcZaflDCuNFvCM=; b=RXWQUSxF+hc18dOXPHVaYg3gY/9tes1ioEefvY4J8tB1Qw/MkLGPiA6VMIq88IuHcS5kt2 vlxSJ5SBfB0AjcJXG7Zq9Zktv7KFHUOZFKAUjPhTj8qHpnTxrpxW0wcLePJhbSs5SyfIW0 Keec8lEKXaJvUGoIS5vyKAx1mL7SmQA= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-328-z0mYalRQM06_X3TGzm73ZQ-1; Fri, 19 Jul 2024 07:09:33 -0400 X-MC-Unique: z0mYalRQM06_X3TGzm73ZQ-1 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-36871eb0a8eso631280f8f.3 for ; Fri, 19 Jul 2024 04:09:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721387372; x=1721992172; h=in-reply-to:references:user-agent:to:from:cc:subject:message-id :date:content-transfer-encoding:mime-version:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=SFv74Xob6betkhD53i2jO1pOzBZ4rc1IlLlu2Aw0XEY=; b=RZPaLQfsT9DMTzhVYsjEOJE2bxUpzLS/UyvbSK2ivI527gDJ9X35USCBxkIh2O24TH pMO3nzCNH4HnQhuCuFkwIflceLy7hOEXyBpt6rzoy7k5hNYT+/KpqUD1NUWhlXm1AR+T TX0p0P3KhJk7ERhAtHmvhT+ZtLthoZbcjkYAVNxreVEyik//XHCUeSf2lXA0Wx9LQpDV nrEBQCJSB+xdoE3rskCMxqtGsTpKi5tIHK4MaKqwzOxOrZqbFP6HJ9asoM00ihJ+lDv3 obpd20X8dlFqgyI4/uuxImzcFNJisAUVEbkXi4iUsG8VtcAzfEYeIbgQAawYZXflHxBL n73w== X-Gm-Message-State: AOJu0Ywl2OMGCADDacV6JTHZbir6Aq+sNLp+SyL0yQexZ0aE62h6A0Gz aEPsNFcgtADUarhb/AO7dpQr4dCUHiPV3O7jVEkgDMZysTs4u9GNHV8K9GmaVjCi7Ol7BHn0i+8 qLlasOxoJN7ce3CQmjGVdW7A0HdPXG9MC9JqhLSkf X-Received: by 2002:adf:e58c:0:b0:367:8a2f:a6dc with SMTP id ffacd0b85a97d-368316f9cc7mr5383089f8f.44.1721387372508; Fri, 19 Jul 2024 04:09:32 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFj/SFbIQuZp7E8LPQkrWjtOAnIVe+GyvSvQ9AfV4l58pVfv1FRgD+iUTb7HYlhiYSmbDpMbw== X-Received: by 2002:adf:e58c:0:b0:367:8a2f:a6dc with SMTP id ffacd0b85a97d-368316f9cc7mr5383043f8f.44.1721387372083; Fri, 19 Jul 2024 04:09:32 -0700 (PDT) Received: from localhost (2a01cb0003516600b51f9b4ded302b00.ipv6.abo.wanadoo.fr. [2a01:cb00:351:6600:b51f:9b4d:ed30:2b00]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-368787eced0sm1279123f8f.98.2024.07.19.04.09.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jul 2024 04:09:31 -0700 (PDT) Mime-Version: 1.0 Date: Fri, 19 Jul 2024 13:09:30 +0200 Message-Id: Subject: Re: IPv6 APIs rework Cc: , "Sunil Kumar Kori" , "Rakesh Kudurumalla" , "Vladimir Medvedkin" , "Wisam Jaddo" , "Cristian Dumitrescu" , "Konstantin Ananyev" , "Akhil Goyal" , "Fan Zhang" , "Bruce Richardson" , "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" From: "Robin Jarry" To: =?utf-8?q?Morten_Br=C3=B8rup?= , "Vladimir Medvedkin" , User-Agent: aerc/0.18.0-5-gd32d93015ed7 References: <98CBD80474FA8B44BF855DF32C47DC35E9F5AB@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F5AC@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F5AE@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F5AE@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 Morten Br=C3=B8rup, Jul 19, 2024 at 12:46: > When passing an IPv4 address as a value, alignment does matter; it=20 > must be 4 byte aligned. I was expecting the compiler to do what is necessary to copy the data to=20 an aligned register before jumping to the function. > On a CPU with 128 bit registers, I would probably also pass an IPv6=20 > address as a value. With such a CPU, the parameter type should be=20 > uint128_t or rte_be128_t, depending on byte order. I don't think there is a portable/standard uint128_t yet. Everything=20 I could find is either GCC or linux specific. > There's a 3rd option: > Have an IPv6 type that is simply an array of 16 bytes with no explicitly = specified alignment: > > struct rte_ipv6_addr { > =09unsigned char addr_bytes[RTE_IPV6_ADDR_LEN]; > }; > > Or: > > typedef struct rte_ipv6_addr { > =09unsigned char addr_bytes[RTE_IPV6_ADDR_LEN]; > } rte_ipv6_addr_t; > > If used as is, it will be unaligned. > > And if alignment offers improved performance for some use cases,=20 > explicit alignment attributes can be added to the type in those use=20 > cases. > > Not using an uint128_t type (or a union of other types than unsigned=20 > char) will also avoid byte order issues. > > I guess Stephen was right to begin with. :-) Having the type as a union (as is the POSIX type) makes casting to=20 integers a lot less tedious and makes the structure overall more=20 flexible. We could completely add an unaligned be128 member to the union by the=20 way. I don't see what is wrong with having sub union members. About your concern with byte order, since the union members have=20 explicit rte_be*_t types, I don't think confusion can happen. I have=20 also renamed the members, replacing the "u" prefix with "a" so that it=20 does not indicate that it should be used as a host integer. struct __rte_aligned(1) rte_ipv6_addr { union { unsigned char a[16]; unaligned_be16_t a16[8]; unaligned_be32_t a32[4]; unaligned_be64_t a64[2]; unaligned_be128_t a128[1]; }; } __rte_packed;