From: Luc Pelletier <lucp.at.work@gmail.com>
To: Georg Sauthoff <mail@gms.tf>
Cc: "Stephen Hemminger" <stephen@networkplumber.org>,
bruce.richardson@intel.com, konstantin.ananyev@intel.com,
dev <dev@dpdk.org>, "Xiaoyun Li" <xiaoyun.li@intel.com>,
"Morten Brørup" <mb@smartsharesystems.com>
Subject: Re: [PATCH v2] eal: fix unaligned loads/stores in rte_memcpy_generic
Date: Tue, 25 Jan 2022 14:57:40 -0500 [thread overview]
Message-ID: <CAFeRdtAwULnJbA3g=Dgs+AYD55N-XPci4BMbMDZbhomtQw-FGw@mail.gmail.com> (raw)
In-Reply-To: <Ye80hp+MufUhEoDD@dell12.lru.li>
Hi Georg,
> perhaps it's worth mentioning that the Linux Kernel is compiled with
> -fno-strict-aliasing, because it contains code which violates the C
> strict aliasing rules. Such code yields undefined behavior and is thus
> unsafe when compiling with optmizing compilers such as GCC and Clang, by
> default. But since the Linux supplies -fno-strict-aliasing its code is
> safe, in the Linux Kernel context.
>
> In contrast, DPDK isn't compiled with -fno-strict-aliasing, in general.
> Only a few drivers are built with -Wno-strict-aliasing.
>
> Thus, one has to be careful when importing (or being inspired) by the
> above mentioned kernel defines.
>
> Especially, it looks like version 5 of this patch yields undefined
> behavior because it violates strict-aliasing rules.
> It's possible that GCC makes some extra guarantees for the used
> constructs, even when compiling without -fno-strict-aliasing. But I'm
> not aware of any.
Thank you for pointing this out. That's an excellent comment and
something I had missed. Would adding the __may_alias__ attribute to
the unaligned_uint structs fix the issue?
I think it would, but I have to admit that documentation is a little
sparse and I don't have much experience with this attribute. If it
doesn't fix the problem, please let me know if you can think of
another solution that wouldn't involve going back to assembly (v4 of
this patch).
Also, I think the __may_alias__ attribute is supported by all
compilers that DPDK supports when targeting x86, but please let me
know if you don't think that's the case.
> BTW, are there still systems that DPDK supports but have a memcpy() which
> performs worse than rte_memcpy()?
I concur with Morten, that's an excellent question. Analyzing the
memcpy source code on every platform/architecture that DPDK supports
would be one way to answer the question. However, that seems like a
significant undertaking and I'm hoping someone who knows the answer
will chime in.
next prev parent reply other threads:[~2022-01-25 19:57 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-15 19:41 [PATCH] " Luc Pelletier
2022-01-15 21:39 ` [PATCH v2] " Luc Pelletier
2022-01-15 22:13 ` Stephen Hemminger
2022-01-16 14:09 ` Luc Pelletier
2022-01-16 16:32 ` Stephen Hemminger
2022-01-24 23:21 ` Georg Sauthoff
2022-01-25 7:59 ` Morten Brørup
2022-01-25 19:57 ` Luc Pelletier [this message]
2022-01-16 14:13 ` [PATCH v3] " Luc Pelletier
2022-01-16 14:33 ` Luc Pelletier
2022-01-16 16:34 ` Stephen Hemminger
2022-01-16 17:59 ` Morten Brørup
2022-01-16 20:33 ` [PATCH v4] " Luc Pelletier
2022-01-17 15:37 ` [PATCH v5] " Luc Pelletier
2022-02-04 16:42 ` Luc Pelletier
2022-02-04 17:16 ` Ananyev, Konstantin
2022-02-08 16:53 ` Thomas Monjalon
2022-02-09 15:05 ` Luc Pelletier
2022-02-10 14:04 ` Ananyev, Konstantin
2022-02-10 16:56 ` Luc Pelletier
2022-02-11 15:51 ` Ananyev, Konstantin
2022-02-13 22:31 ` Luc Pelletier
2022-02-14 13:41 ` Ananyev, Konstantin
2022-02-25 15:51 ` [PATCH v6] eal: fix rte_memcpy strict aliasing/alignment bugs Luc Pelletier
2022-02-25 16:38 ` [PATCH v7] " Luc Pelletier
2022-03-10 14:55 ` Ananyev, Konstantin
2022-04-07 15:24 ` David Marchand
2022-04-07 15:32 ` David Marchand
2022-04-07 15:40 ` David Marchand
2022-05-13 19:15 ` Luc Pelletier
2022-05-19 16:41 ` David Marchand
2022-04-08 13:47 ` Luc Pelletier
2022-05-19 16:47 ` David Marchand
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='CAFeRdtAwULnJbA3g=Dgs+AYD55N-XPci4BMbMDZbhomtQw-FGw@mail.gmail.com' \
--to=lucp.at.work@gmail.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@intel.com \
--cc=mail@gms.tf \
--cc=mb@smartsharesystems.com \
--cc=stephen@networkplumber.org \
--cc=xiaoyun.li@intel.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).