DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Phil Yang" <phil.yang@arm.com>, <honnappa.nagarahalli@arm.com>,
	"Ruifeng Wang" <ruifeng.wang@arm.com>, <dev@dpdk.org>
Cc: <david.marchand@redhat.com>, <olivier.matz@6wind.com>,
	<dharmik.thakkar@arm.com>, <gavin.hu@arm.com>, <nd@arm.com>,
	<andrew.rybchenko@oktetlabs.ru>
Subject: RE: [dpdk-dev] [PATCH] ring: fix unaligned memory access on aarch32
Date: Sat, 4 Nov 2023 01:04:10 +0100	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9EFD1@smartserver.smartshare.dk> (raw)
In-Reply-To: <1583774395-10233-1-git-send-email-phil.yang@arm.com>

I have for a long time now wondered why the ring functions for enqueue/dequeue of 64-bit objects supports unaligned addresses, and now I finally found the patch introducing it.

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Phil Yang
> Sent: Monday, 9 March 2020 18.20
> 
> The 32-bit arm machine doesn't support unaligned memory access. It
> will cause a bus error on aarch32 with the custom element size ring.
> 
> Thread 1 "test" received signal SIGBUS, Bus error.
> __rte_ring_enqueue_elems_64 (n=1, obj_table=0xf5edfe41, prod_head=0, \
> r=0xf5edfb80) at /build/dpdk/build/include/rte_ring_elem.h:177
> 177                             ring[idx++] = obj[i++];

Which test is this? Why is it using an unaligned array of 64-bit objects? (Notice that obj_table=0xf5edfe41.)

Nobody in their right mind would use an unaligned array of 64-bit objects. You can only create such an array if you force the compiler to prevent automatic alignment! And all the functions in your application using this array would also need to support unaligned addressing of these objects.

This seems extremely exotic, and not something any real application would do!

I would like to revert this patch for performance reasons.

> 
> Fixes: cc4b218790f6 ("ring: support configurable element size")
> 
> Signed-off-by: Phil Yang <phil.yang@arm.com>
> Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> ---
>  lib/librte_ring/rte_ring_elem.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/librte_ring/rte_ring_elem.h
> b/lib/librte_ring/rte_ring_elem.h
> index 3976757..663addc 100644
> --- a/lib/librte_ring/rte_ring_elem.h
> +++ b/lib/librte_ring/rte_ring_elem.h
> @@ -160,7 +160,7 @@ __rte_ring_enqueue_elems_64(struct rte_ring *r,
> uint32_t prod_head,
>  	const uint32_t size = r->size;
>  	uint32_t idx = prod_head & r->mask;
>  	uint64_t *ring = (uint64_t *)&r[1];
> -	const uint64_t *obj = (const uint64_t *)obj_table;
> +	const unaligned_uint64_t *obj = (const unaligned_uint64_t
> *)obj_table;
>  	if (likely(idx + n < size)) {
>  		for (i = 0; i < (n & ~0x3); i += 4, idx += 4) {
>  			ring[idx] = obj[i];
> @@ -294,7 +294,7 @@ __rte_ring_dequeue_elems_64(struct rte_ring *r,
> uint32_t prod_head,
>  	const uint32_t size = r->size;
>  	uint32_t idx = prod_head & r->mask;
>  	uint64_t *ring = (uint64_t *)&r[1];
> -	uint64_t *obj = (uint64_t *)obj_table;
> +	unaligned_uint64_t *obj = (unaligned_uint64_t *)obj_table;
>  	if (likely(idx + n < size)) {
>  		for (i = 0; i < (n & ~0x3); i += 4, idx += 4) {
>  			obj[i] = ring[idx];
> --
> 2.7.4
> 

References:
https://git.dpdk.org/dpdk/commit/lib/librte_ring/rte_ring_elem.h?id=3ba51478a3ab3132c33effc8b132641233275b36
https://patchwork.dpdk.org/project/dpdk/patch/1583774395-10233-1-git-send-email-phil.yang@arm.com/


  parent reply	other threads:[~2023-11-04  0:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-09 17:19 Phil Yang
2020-03-19 15:56 ` David Marchand
2023-11-04  0:04 ` Morten Brørup [this message]
2023-11-04 16:32   ` Honnappa Nagarahalli
2023-11-04 16:54     ` Morten Brørup
2023-11-10  8:39   ` Ruifeng Wang
2023-11-10  9:34     ` Morten Brørup
2023-11-10  9:44       ` Konstantin Ananyev
2023-11-10 10:43         ` Morten Brørup
2023-11-10 13:18           ` Morten Brørup
2023-11-13  6:39             ` Ruifeng Wang
2023-11-10 19:05           ` Konstantin Ananyev
2023-11-13  1:53           ` Honnappa Nagarahalli

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=98CBD80474FA8B44BF855DF32C47DC35E9EFD1@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=dharmik.thakkar@arm.com \
    --cc=gavin.hu@arm.com \
    --cc=honnappa.nagarahalli@arm.com \
    --cc=nd@arm.com \
    --cc=olivier.matz@6wind.com \
    --cc=phil.yang@arm.com \
    --cc=ruifeng.wang@arm.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).