DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Stanislaw Kardach <kda@semihalf.com>
Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	Jerin Jacob <jerinjacobk@gmail.com>,
	Kathleen Capella <Kathleen.Capella@arm.com>,
	"thomas@monjalon.net" <thomas@monjalon.net>,
	"dev@dpdk.org" <dev@dpdk.org>,
	Dharmik Thakkar <Dharmik.Thakkar@arm.com>,
	Ruifeng Wang <Ruifeng.Wang@arm.com>,
	"david.marchand@redhat.com" <david.marchand@redhat.com>,
	"jerinj@marvell.com" <jerinj@marvell.com>,
	"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
	Stephen Hemminger <sthemmin@microsoft.com>, nd <nd@arm.com>
Subject: Re: [dpdk-dev] L3fwd mode in testpmd
Date: Fri, 30 Apr 2021 11:28:07 +0000	[thread overview]
Message-ID: <DM6PR11MB44918043924CDF96BBACA1469A5E9@DM6PR11MB4491.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20210429115329.a2zek6rkmna6qhs3@toster>


> 
> On Thu, Apr 29, 2021 at 11:47:30AM +0000, Ananyev, Konstantin wrote:
> <snip>
> > >
> > > It looks as if implementing em_mask_key() is enough to get l3fwd
> > > working. However to me this ifdef seems tricky. How should a scalar
> > > implementation handle the xmm_t type? rte_xmm_t looks like an API
> > > type/union, but both are not mentioned in documentation and are in
> > > platform dependent rte_vect.h only.
> > > So either I add another case for RISC-V or (what seems more proper) add
> > > an else clause implementation. However then should I change this function
> > > to take rte_xmm_t? If not is casting xmm_t to i.e. int32_t[] always
> > > valid? Even if I change to rte_xmm_t, it's not a stable API type, is it?
> > > So what guarantee do I have that it maps to int32_t bit-wise on every
> > > platform?
> > >
> > > I think the semantic requirements of xmm_t typedef are a bit undefined as
> > > well as the vector handling across the architectures (being something
> > > rather arch specific). I don't have a clear idea on how to solve this
> > > yet and I would not like to hijack this discussion with vector stuff.
> > >
> > > Though I may be missing some obvious solution here. Any idea is welcome.
> > > :)
> >
> > I think it should be possible to replace xmm_t with rte_xmm_t in ipv(4|6)_5tuple_host
> > and make em_mask_key to take 'rte_xmm_t *' as a parameter/return value instead of xmm_t.
> > With that in place scalar version seems straightforward.
> > Of course perf regression test would be needed after such changes,
> > but I think with '-O3' it should be no difference.
> >
> I did that and it works in practice. I'm more asking about the lack of
> definition in rte_xmm_t semantics. Because once it's in an example,
> people may start assuming it's OK to use it this way.
> If it is OK, then I'll just post a patch, otherwise we need a separate
> discussion.

From my perspective: rte_xmm_t is a union used to simplify SIMD-related
code development. It contains HW specific field (xmm_t) and common ones.
It is not used in public DPDK API, but it is used quite extensively inside various libs.
As a public structure - so it can be used by examples and user code
(as long as it is defined for the given architecture).
So I suppose it is up to you guys to decide do you want to define it for your architecture or not.
If not, but you would still like to run l3fwd, then probably l3fwd_em.c needs to be split
Into l3fwd_em_scalar.c and l3fwd_em_vect.c.  

Konstantin


  reply	other threads:[~2021-04-30 11:28 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-10 18:31 Honnappa Nagarahalli
2021-03-11  6:41 ` Jerin Jacob
2021-03-11 15:18   ` Honnappa Nagarahalli
2021-03-11 15:46     ` Thomas Monjalon
2021-03-11 16:00       ` Honnappa Nagarahalli
2021-03-31 20:35         ` Kathleen Capella
2021-03-31 21:17           ` Jerin Jacob
2021-04-01  0:20             ` Honnappa Nagarahalli
2021-04-01  4:38               ` Jerin Jacob
2021-04-24  0:26                 ` Honnappa Nagarahalli
2021-04-26  9:44                   ` Jerin Jacob
2021-04-26 17:47                     ` Stephen Hemminger
2021-04-26 20:46                       ` Honnappa Nagarahalli
2021-04-27  9:39                         ` Andrew Rybchenko
2021-04-27  9:50                         ` Ferruh Yigit
2021-04-27  9:57                           ` Ananyev, Konstantin
2021-04-27 11:11                             ` Thomas Monjalon
2021-04-27 11:32                               ` Bruce Richardson
2021-04-27 23:26                                 ` Honnappa Nagarahalli
2021-04-27 23:17                             ` Honnappa Nagarahalli
2021-04-28 10:48                               ` Bruce Richardson
2021-04-28 11:04                                 ` Stanisław Kardach
2021-04-28 11:19                                   ` Thomas Monjalon
2021-04-28 21:44                                   ` Honnappa Nagarahalli
2021-04-29  7:49                                     ` Stanislaw Kardach
2021-04-29  8:31                                       ` Ananyev, Konstantin
2021-04-29 10:39                                         ` Stanislaw Kardach
2021-04-29 11:47                                           ` Ananyev, Konstantin
2021-04-29 11:53                                             ` Stanislaw Kardach
2021-04-30 11:28                                               ` Ananyev, Konstantin [this message]
2021-08-02 15:07                                                 ` Dharmik Thakkar
2021-04-28 11:17                                 ` Thomas Monjalon
2021-04-28 10:59                               ` Ananyev, Konstantin
2021-04-28 22:10                                 ` Honnappa Nagarahalli
2021-04-27 16:01                           ` Stephen Hemminger
2021-04-27 20:20                             ` Honnappa Nagarahalli
2021-04-27 22:23                               ` Ananyev, Konstantin
2021-04-27 23:11                                 ` Honnappa Nagarahalli
2021-04-28 11:00                                   ` Ananyev, Konstantin
2021-04-26 20:32                     ` 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=DM6PR11MB44918043924CDF96BBACA1469A5E9@DM6PR11MB4491.namprd11.prod.outlook.com \
    --to=konstantin.ananyev@intel.com \
    --cc=Dharmik.Thakkar@arm.com \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=Kathleen.Capella@arm.com \
    --cc=Ruifeng.Wang@arm.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerinj@marvell.com \
    --cc=jerinjacobk@gmail.com \
    --cc=kda@semihalf.com \
    --cc=nd@arm.com \
    --cc=stephen@networkplumber.org \
    --cc=sthemmin@microsoft.com \
    --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).