DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Coyle, David" <david.coyle@intel.com>,
	"O'loingsigh, Mairtin" <mairtin.oloingsigh@intel.com>,
	"Singh, Jasvinder" <jasvinder.singh@intel.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"Ryan, Brendan" <brendan.ryan@intel.com>,
	"O'loingsigh, Mairtin" <mairtin.oloingsigh@intel.com>
Subject: Re: [dpdk-dev] [PATCH v4 1/2] net: add run-time architecture specific	CRC selection
Date: Sat, 10 Oct 2020 12:42:30 +0000	[thread overview]
Message-ID: <BYAPR11MB3301F47B4E9C72DE37B4C1BF9A090@BYAPR11MB3301.namprd11.prod.outlook.com> (raw)
In-Reply-To: <MN2PR11MB3550D1E9A4AD47F26F1E6DA1E3080@MN2PR11MB3550.namprd11.prod.outlook.com>



Hi David,

> > > This patch adds support for run-time selection of the optimal
> > > architecture-specific CRC path, based on the supported instruction
> > > set(s) of the CPU.
> > >
> > > The compiler option checks have been moved from the C files to the
> > > meson script. The rte_cpu_get_flag_enabled function is called
> > > automatically by the library at process initialization time to
> > > determine which instructions the CPU supports, with the most optimal
> > > supported CRC path ultimately selected.
> > >
> > > Signed-off-by: Mairtin o Loingsigh <mairtin.oloingsigh@intel.com>
> > > Signed-off-by: David Coyle <david.coyle@intel.com>
> >
> > LGTM, just one nit see below.
> > With that:
> > Series acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> >
> > > ---
> > >  doc/guides/rel_notes/release_20_11.rst            |  4 ++
> > >  lib/librte_net/meson.build                        | 34 +++++++++++-
> > >  lib/librte_net/net_crc.h                          | 34 ++++++++++++
> > >  lib/librte_net/{net_crc_neon.h => net_crc_neon.c} | 26 +++------
> > >  lib/librte_net/{net_crc_sse.h => net_crc_sse.c}   | 34 ++++--------
> > >  lib/librte_net/rte_net_crc.c                      | 67 ++++++++++++++---------
> > >  6 files changed, 131 insertions(+), 68 deletions(-)  create mode
> > > 100644 lib/librte_net/net_crc.h  rename lib/librte_net/{net_crc_neon.h
> > > => net_crc_neon.c} (95%)  rename lib/librte_net/{net_crc_sse.h =>
> > > net_crc_sse.c} (94%)
> > >
> > >
> 
> <snip>
> 
> > > +#ifdef CC_X86_64_SSE42_PCLMULQDQ_SUPPORT static uint8_t
> > > +sse42_pclmulqdq_cpu_supported(void)
> > > +{
> > > +	return rte_cpu_get_flag_enabled(RTE_CPUFLAG_PCLMULQDQ);
> > > +}
> >
> > As a nit, I think it would be better to hide #fidef inside the function, and
> > return an 0 when define is not set.
> > Something like:
> >
> > static int
> > sse42_pclmulqdq_cpu_supported(void)
> > {
> > #ifdef CC_X86_64_SSE42_PCLMULQDQ_SUPPORT
> > 	return rte_cpu_get_flag_enabled(RTE_CPUFLAG_PCLMULQDQ);
> > #else
> > 	return 0;
> > }
> >
> > Same for other cpu_supported functions.
> > And then you can remove these ifdefs in set_alg and other palces, i.e.:
> >
> > void
> > rte_net_crc_set_alg(enum rte_net_crc_alg alg) {
> >         switch (alg) {
> > #ifdef RTE_ARCH_X86_64
> >         case RTE_NET_CRC_AVX512:
> >                 if (avx512_vpclmulqdq_cpu_supported()) {
> >                         handlers = handlers_avx512;
> >                         break;
> >                 }
> >                 /* fall-through */
> >         case RTE_NET_CRC_SSE42:
> >                 if (sse42_pclmulqdq_cpu_supported()) {
> >                         handlers = handlers_sse42;
> >                         break;
> >                 }
> > #endif
> > ...
> >
> > Same for rte_net_crc_init()
> 
> [DC] I have reworked the ifdefs in this file based on your comments here and off-list discussions.
> These are available now in the v5.
> 
> All ifdef's have been removed out the API function definitions and moved down into 'helper' type
> functions - looks much cleaner now.
>
> Your Ack has been carried through too to v5 as you mentioned

LGTM, thanks.
Konstantin

 

  reply	other threads:[~2020-10-10 12:42 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-29 15:35 [dpdk-dev] [PATCH v3 0/2] net: add CRC run-time checks and AVX512/VPCLMULQDQ based CRC Mairtin o Loingsigh
2020-09-29 15:36 ` [dpdk-dev] [PATCH v3 1/2] net: add run-time architecture specific CRC selection Mairtin o Loingsigh
2020-10-02 15:17   ` Singh, Jasvinder
2020-10-06 16:38     ` O'loingsigh, Mairtin
2020-09-29 15:36 ` [dpdk-dev] [PATCH v3 2/2] net: add support for AVX512/VPCLMULQDQ based CRC Mairtin o Loingsigh
2020-10-05 13:20   ` De Lara Guarch, Pablo
2020-10-05 13:38     ` O'loingsigh, Mairtin
2020-10-06 16:23 ` [dpdk-dev] [PATCH v4 0/2] net: add CRC run-time checks and " Mairtin o Loingsigh
2020-10-06 16:23   ` [dpdk-dev] [PATCH v4 1/2] net: add run-time architecture specific CRC selection Mairtin o Loingsigh
2020-10-07 14:59     ` Ananyev, Konstantin
2020-10-09 14:04       ` Coyle, David
2020-10-10 12:42         ` Ananyev, Konstantin [this message]
2020-10-06 16:23   ` [dpdk-dev] [PATCH v4 2/2] net: add support for AVX512/VPCLMULQDQ based CRC Mairtin o Loingsigh
2020-10-07  9:26   ` [dpdk-dev] [PATCH v4 0/2] net: add CRC run-time checks and " David Marchand
2020-10-09 13:50   ` [dpdk-dev] [PATCH v5 " Mairtin o Loingsigh
2020-10-09 13:50     ` [dpdk-dev] [PATCH v5 1/2] net: add run-time architecture specific CRC selection Mairtin o Loingsigh
2020-10-09 16:22       ` Singh, Jasvinder
2020-10-10  9:34       ` Ruifeng Wang
2020-10-13  9:07       ` Bruce Richardson
2020-10-09 13:50     ` [dpdk-dev] [PATCH v5 2/2] net: add support for AVX512/VPCLMULQDQ based CRC Mairtin o Loingsigh
2020-10-09 16:24       ` Singh, Jasvinder
2020-10-09 18:35     ` [dpdk-dev] [PATCH v5 0/2] net: add CRC run-time checks and " De Lara Guarch, Pablo
2020-10-13 18: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=BYAPR11MB3301F47B4E9C72DE37B4C1BF9A090@BYAPR11MB3301.namprd11.prod.outlook.com \
    --to=konstantin.ananyev@intel.com \
    --cc=brendan.ryan@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.coyle@intel.com \
    --cc=dev@dpdk.org \
    --cc=jasvinder.singh@intel.com \
    --cc=mairtin.oloingsigh@intel.com \
    --cc=pablo.de.lara.guarch@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).