DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Robin Jarry" <rjarry@redhat.com>,
	"Vladimir Medvedkin" <medvedkinv@gmail.com>,
	<stephen@networkplumber.org>
Cc: <dev@dpdk.org>, "Sunil Kumar Kori" <skori@marvell.com>,
	"Rakesh Kudurumalla" <rkudurumalla@marvell.com>,
	"Vladimir Medvedkin" <vladimir.medvedkin@intel.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>,
	"Bruce Richardson" <bruce.richardson@intel.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>,
	"Ziyang Xuan" <xuanziyang2@huawei.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>,
	"Stephen Hemminger" <stephen@networkplumber.org>,
	"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: Fri, 19 Jul 2024 11:12:54 +0200	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F5AC@smartserver.smartshare.dk> (raw)
In-Reply-To: <D2SZK17E8CKJ.2ISL9TQI3ST40@redhat.com>

> From: Robin Jarry [mailto:rjarry@redhat.com]
> 
> 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.

> Current
> > vector implementation loads IPv6 addresses using unaligned access (
> > _mm512_loadu_si512) so it doesn't rely on alignment.
> 
> 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.

> 
> > > 2. In the IPv6 packet header, the IPv6 addresses are not 16 byte
> aligned,
> > > they are 8 byte aligned. So we cannot make the IPv6 address type 16
> byte
> > > aligned.
> 
> > Not necessary, if Ethernet frame in mbuf starts on 8b aligned address,
> then
> > IPv6 is aligned only by 2 bytes.
> 
> We probably could safely say that aligning on 2 bytes would be OK. But
> is there any benefit, performance wise, in doing so? Keeping the same
> alignment as before the change would at least make it ABI compatible.

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.

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.


  parent reply	other threads:[~2024-07-19  9:15 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 [this message]
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
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=98CBD80474FA8B44BF855DF32C47DC35E9F5AC@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.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.v.ananyev@yandex.ru \
    --cc=ktejasree@marvell.com \
    --cc=matan@nvidia.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=medvedkinv@gmail.com \
    --cc=ndabilpuram@marvell.com \
    --cc=orika@nvidia.com \
    --cc=palok@marvell.com \
    --cc=pbhagavatula@marvell.com \
    --cc=rjarry@redhat.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=vladimir.medvedkin@intel.com \
    --cc=wisamm@nvidia.com \
    --cc=xuanziyang2@huawei.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).