DPDK patches and discussions
 help / color / mirror / Atom feed
From: David Marchand <david.marchand@redhat.com>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: dev@dpdk.org, Robin Jarry <rjarry@redhat.com>,
	 Stephen Hemminger <stephen@networkplumber.org>,
	Chengwen Feng <fengchengwen@huawei.com>,
	 Bruce Richardson <bruce.richardson@intel.com>,
	Andre Muezerie <andremue@linux.microsoft.com>,
	 Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH] net: fix IPv4 cksum simple function
Date: Tue, 5 Nov 2024 10:27:53 +0100	[thread overview]
Message-ID: <CAJFAV8yrJ_6wwp2XPX6y+Gg1M6j3_-U11-u8kU0_y0TgyrQ0dg@mail.gmail.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F877@smartserver.smartshare.dk>

On Tue, Nov 5, 2024 at 10:09 AM Morten Brørup <mb@smartsharesystems.com> wrote:
> > diff --git a/lib/net/rte_ip4.h b/lib/net/rte_ip4.h
> > index 4dd0058cc5..f9b8333332 100644
> > --- a/lib/net/rte_ip4.h
> > +++ b/lib/net/rte_ip4.h
> > @@ -39,7 +39,7 @@ extern "C" {
> >  /**
> >   * IPv4 Header
> >   */
> > -struct rte_ipv4_hdr {
> > +struct __rte_aligned(2) rte_ipv4_hdr {
>
> <unrelated>
> I wonder why we have a convention of putting __rte_packed after the struct, and not between the "struct" tag and the name of the struct.
> It would make the code much more readable having it here, like __rte_aligned().
> </unrelated>

I agree that the previous convention was not great, as it has resulted
in some funny jokes, like getting some __rte_XXX variables (in the
absence of the right header inclusion defining __rte_XXX attribute
macro).

__rte_aligned() "conventional" location has been changed recently by Tyler.
__rte_packed is still conventionnally placed in a "legacy" position
around the dpdk tree.
It could probably be moved in the same way.

But there is still the question of packed structures with MSVC.
Tyler proposal seemed to rely on the current __rte_packed conventional position.
https://patchwork.dpdk.org/project/dpdk/patch/1713225913-20792-2-git-send-email-roretzla@linux.microsoft.com/
Note that I am not a fan of this push/pop stuff.

Maybe Andre will find a better solution.

In any case, I prefer we keep __rte_packed position as is until this
question is resolved.


-- 
David Marchand


  reply	other threads:[~2024-11-05  9:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-05  8:59 David Marchand
2024-11-05  9:09 ` Morten Brørup
2024-11-05  9:27   ` David Marchand [this message]
2024-11-05 10:20     ` Morten Brørup
2024-11-05 10:49       ` David Marchand
2024-11-05 11:02         ` Bruce Richardson
2024-11-05 11:06           ` Morten Brørup
2024-11-05 13:12           ` David Marchand
2024-11-05  9:37   ` Robin Jarry
2024-11-05  9:53     ` Morten Brørup
2024-11-06 20:22   ` David Marchand
2024-11-05 10:18 ` Bruce Richardson

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=CAJFAV8yrJ_6wwp2XPX6y+Gg1M6j3_-U11-u8kU0_y0TgyrQ0dg@mail.gmail.com \
    --to=david.marchand@redhat.com \
    --cc=andremue@linux.microsoft.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=fengchengwen@huawei.com \
    --cc=mb@smartsharesystems.com \
    --cc=rjarry@redhat.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    /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).