DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Robin Jarry" <rjarry@redhat.com>
To: "Morten Brørup" <mb@smartsharesystems.com>,
	"Stephen Hemminger" <stephen@networkplumber.org>
Cc: "Vladimir Medvedkin" <medvedkinv@gmail.com>,
	<bruce.richardson@intel.com>,
	"Konstantin Ananyev" <konstantin.ananyev@huawei.com>,
	<dev@dpdk.org>, "Sunil Kumar Kori" <skori@marvell.com>,
	"Rakesh Kudurumalla" <rkudurumalla@marvell.com>,
	"Wisam Jaddo" <wisamm@nvidia.com>,
	"Cristian Dumitrescu" <cristian.dumitrescu@intel.com>,
	"Konstantin Ananyev" <konstantin.v.ananyev@yandex.ru>,
	"Akhil Goyal" <gakhil@marvell.com>,
	"Fan Zhang" <fanzhang.oss@gmail.com>,
	"Yipeng Wang" <yipeng1.wang@intel.com>,
	"Sameh Gobriel" <sameh.gobriel@intel.com>,
	"Nithin Dabilpuram" <ndabilpuram@marvell.com>,
	"Kiran Kumar K" <kirankumark@marvell.com>,
	"Satha Rao" <skoteshwar@marvell.com>,
	"Harman Kalra" <hkalra@marvell.com>,
	"Ankur Dwivedi" <adwivedi@marvell.com>,
	"Anoob Joseph" <anoobj@marvell.com>,
	"Tejasree Kondoj" <ktejasree@marvell.com>,
	"Gagandeep Singh" <g.singh@nxp.com>,
	"Hemant Agrawal" <hemant.agrawal@nxp.com>,
	"Ajit Khaparde" <ajit.khaparde@broadcom.com>,
	"Somnath Kotur" <somnath.kotur@broadcom.com>,
	"Chas Williams" <chas3@att.com>,
	"Min Hu (Connor)" <humin29@huawei.com>,
	"Potnuri Bharat Teja" <bharat@chelsio.com>,
	"Sachin Saxena" <sachin.saxena@nxp.com>,
	"Xiaoyun Wang" <cloud.wangxiaoyun@huawei.com>,
	"Jie Hai" <haijie1@huawei.com>,
	"Yisen Zhuang" <yisen.zhuang@huawei.com>,
	"Jingjing Wu" <jingjing.wu@intel.com>,
	"Dariusz Sosnowski" <dsosnowski@nvidia.com>,
	"Viacheslav Ovsiienko" <viacheslavo@nvidia.com>,
	"Bing Zhao" <bingz@nvidia.com>, "Ori Kam" <orika@nvidia.com>,
	"Suanming Mou" <suanmingm@nvidia.com>,
	"Matan Azrad" <matan@nvidia.com>,
	"Chaoyong He" <chaoyong.he@corigine.com>,
	"Devendra Singh Rawat" <dsinghrawat@marvell.com>,
	"Alok Prasad" <palok@marvell.com>,
	"Andrew Rybchenko" <andrew.rybchenko@oktetlabs.ru>,
	"Jiawen Wu" <jiawenwu@trustnetic.com>,
	"Jian Wang" <jianwang@trustnetic.com>,
	"Thomas Monjalon" <thomas@monjalon.net>,
	"Ferruh Yigit" <ferruh.yigit@amd.com>,
	"Jiayu Hu" <hujiayu.hu@foxmail.com>,
	"Pavan Nikhilesh" <pbhagavatula@marvell.com>,
	"Maxime Coquelin" <maxime.coquelin@redhat.com>,
	"Chenbo Xia" <chenbox@nvidia.com>
Subject: Re: IPv6 APIs rework
Date: Sun, 21 Jul 2024 23:51:29 +0200	[thread overview]
Message-ID: <D2VJSVJ8Y0TR.3U5PG3TVK3W5T@redhat.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F5B0@smartserver.smartshare.dk>

Hi Morten, Stephen,

Morten Brørup, Jul 21, 2024 at 18:12:
> If the IPv6 address type you tested with was a struct containing 
> a union of different types (other than an array of 16 bytes), then 
> those sub-types made your IPv6 address type non-byte aligned, and 
> 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, 
> except if used with alignas().

Indeed removing the sub-types in the union removes the need for strict 
alignment and packing.

Too bad, I found these intermediate integers made the code a bit nicer 
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 
implicit casting to (uint16_t *) or (uint32_t *). Explicit casting is 
required anyway.

> If you are introducing an official IPv6 address type into DPDK, its 
> scope it not just the FIB6 API.
>
> Both Stephen and I can see that - in a broader perspective - the 
> packed and unaligned constraints are unacceptable for performance.
>
> It might not be a problem for the current FIB6 implementation, but it 
> *will* be a problem in many other places, if converted to using the 
> new IPv6 address type.
>
> PS:
> I do consider adding a dedicated IPv6 address type to DPDK an 
> 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 
> a broad spectrum of use cases. Otherwise, the new type is not an 
> improvement, but a deterioration of DPDK.

OK, I understand the stakes. I will comply and propose a simple struct 
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 
future. Indeed, lpm6/fib6 tests rely on literal definitions of IPv6 
addresses and union types need an extra set of curly braces for literal 
definitions. If you think we will never need to add sub-types, I can get 
rid of this. It makes no difference at runtime.

About the timing: when should I send a patch to announce IPv6 API 
breakage for 24.11?

Thanks for taking the time.
Cheers.


  reply	other threads:[~2024-07-21 21:51 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-18 15:03 Robin Jarry
2024-07-18 20:27 ` Morten Brørup
2024-07-18 21:15   ` Stephen Hemminger
2024-07-18 21:40     ` Robin Jarry
2024-07-18 21:25   ` Vladimir Medvedkin
2024-07-18 21:34     ` Robin Jarry
2024-07-19  8:25       ` Konstantin Ananyev
2024-07-19  9:12       ` Morten Brørup
2024-07-19 10:02         ` Robin Jarry
2024-07-19 10:09           ` Bruce Richardson
2024-07-19 10:46           ` Morten Brørup
2024-07-19 11:09             ` Robin Jarry
2024-07-19 15:47               ` Morten Brørup
2024-07-19 17:07                 ` Stephen Hemminger
2024-07-20 17:43                   ` Robin Jarry
2024-07-20 20:26                     ` Stephen Hemminger
2024-07-20 20:33                       ` Robin Jarry
2024-07-21 16:12                         ` Morten Brørup
2024-07-21 21:51                           ` Robin Jarry [this message]
2024-07-22  9:31                             ` Morten Brørup
2024-07-19 10:41         ` Medvedkin, Vladimir

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D2VJSVJ8Y0TR.3U5PG3TVK3W5T@redhat.com \
    --to=rjarry@redhat.com \
    --cc=adwivedi@marvell.com \
    --cc=ajit.khaparde@broadcom.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=anoobj@marvell.com \
    --cc=bharat@chelsio.com \
    --cc=bingz@nvidia.com \
    --cc=bruce.richardson@intel.com \
    --cc=chaoyong.he@corigine.com \
    --cc=chas3@att.com \
    --cc=chenbox@nvidia.com \
    --cc=cloud.wangxiaoyun@huawei.com \
    --cc=cristian.dumitrescu@intel.com \
    --cc=dev@dpdk.org \
    --cc=dsinghrawat@marvell.com \
    --cc=dsosnowski@nvidia.com \
    --cc=fanzhang.oss@gmail.com \
    --cc=ferruh.yigit@amd.com \
    --cc=g.singh@nxp.com \
    --cc=gakhil@marvell.com \
    --cc=haijie1@huawei.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=hkalra@marvell.com \
    --cc=hujiayu.hu@foxmail.com \
    --cc=humin29@huawei.com \
    --cc=jianwang@trustnetic.com \
    --cc=jiawenwu@trustnetic.com \
    --cc=jingjing.wu@intel.com \
    --cc=kirankumark@marvell.com \
    --cc=konstantin.ananyev@huawei.com \
    --cc=konstantin.v.ananyev@yandex.ru \
    --cc=ktejasree@marvell.com \
    --cc=matan@nvidia.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=mb@smartsharesystems.com \
    --cc=medvedkinv@gmail.com \
    --cc=ndabilpuram@marvell.com \
    --cc=orika@nvidia.com \
    --cc=palok@marvell.com \
    --cc=pbhagavatula@marvell.com \
    --cc=rkudurumalla@marvell.com \
    --cc=sachin.saxena@nxp.com \
    --cc=sameh.gobriel@intel.com \
    --cc=skori@marvell.com \
    --cc=skoteshwar@marvell.com \
    --cc=somnath.kotur@broadcom.com \
    --cc=stephen@networkplumber.org \
    --cc=suanmingm@nvidia.com \
    --cc=thomas@monjalon.net \
    --cc=viacheslavo@nvidia.com \
    --cc=wisamm@nvidia.com \
    --cc=yipeng1.wang@intel.com \
    --cc=yisen.zhuang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).