From: Andre Muezerie <andremue@linux.microsoft.com>
To: David Marchand <david.marchand@redhat.com>
Cc: Bruce Richardson <bruce.richardson@intel.com>,
Vladimir Medvedkin <vladimir.medvedkin@intel.com>,
dev@dpdk.org
Subject: Re: [PATCH] lib/lpm: use standard atomic_store_explicit
Date: Wed, 4 Dec 2024 08:20:19 -0800 [thread overview]
Message-ID: <20241204162019.GA28551@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> (raw)
In-Reply-To: <CAJFAV8yU9RvkyEXtDWqWUrM=FY928oJhKJ03SxZeWAgYncq+qQ@mail.gmail.com>
On Wed, Dec 04, 2024 at 08:56:35AM +0100, David Marchand wrote:
> Hello Andre,
>
> On Wed, Dec 4, 2024 at 3:20 AM Andre Muezerie
> <andremue@linux.microsoft.com> wrote:
> >
> > MSVC issues the warning below:
> >
> > ../lib/lpm/rte_lpm.c(297): warning C4013
> > '__atomic_store' undefined; assuming extern returning int
> > ../lib/lpm/rte_lpm.c(298): error C2065:
> > '__ATOMIC_RELAXED': undeclared identifier
> >
> > The fix is to use standard atomic_store_explicit() instead of
> > gcc specific __atomic_store().
> > atomic_store_explicit() was already being used in other parts
> > of DPDK and is compatible
> > with many compilers, including MSVC.
> >
> > Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com>
>
> With this change, is there anything remaining that blocks this library
> compilation with MSVC?
> If not, please update meson.build so that CI can test lpm compilation
> with MSVC on this patch (and that will detect regressions once
> merged).
>
>
> --
> David Marchand
Hi David,
I'm eager to enable lpm to be compiled with MSVC. Even though
this was the last issue I observed for this lib on my machine,
lpm depends on hash, which depends on net, which depends on mbuf and
mbuf is not enabled for MSVC yet.
I have several fixes affecting these pending review and would prefer
to not depend on lpm's dependencies for the system to start compiling
this code in case some critical fix gets completed later. I have not
analyzed all sequences in which patches can be completed, and it's
quite possible that some sequences would result in MSVC compilation
failures if the libs were enabled in meson.build.
However, this code would still get compiled on Linux as usual, and
hopefully we can enable all these libs once the patches get
completed. I am aware that regressions can happen before that point.
We will address them if that happens.
It is tricky to handle so many paches/dependencies. Let me know if
there's something that can be improved.
Andre
next prev parent reply other threads:[~2024-12-04 16:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-04 2:20 Andre Muezerie
2024-12-04 7:56 ` David Marchand
2024-12-04 16:20 ` Andre Muezerie [this message]
2024-12-04 16:52 ` Bruce Richardson
2024-12-04 19:09 ` Andre Muezerie
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=20241204162019.GA28551@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net \
--to=andremue@linux.microsoft.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=vladimir.medvedkin@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).