All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Marchand <david.marchand@redhat.com>
To: David Christensen <drc@linux.vnet.ibm.com>
Cc: "Burakov, Anatoly" <anatoly.burakov@intel.com>, dev <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] eal:ppc: fix incorrect ifdef for ppc_64
Date: Thu, 24 Oct 2019 09:40:45 +0200	[thread overview]
Message-ID: <CAJFAV8yau524MC+kaAdMwdvXYV9ho3wFbORcng2YzNfmBZw7oA@mail.gmail.com> (raw)
In-Reply-To: <a96c06fe-edd5-d89d-7f48-6683a0652352@linux.vnet.ibm.com>

On Thu, Oct 17, 2019 at 6:56 PM David Christensen
<drc@linux.vnet.ibm.com> wrote:
>
> >>>> The change itself is not that scary, but just reading this commitlog I
> >>>> fail to see the impact for an application.
> >>>> Can you share some light?
> >>>>
> >>>
> >>> As far as I can tell there is no impact on any applications.  The old
> >>> code, which walked through the list in a forward direction, worked
> >>> perfectly well with testpmd and DPDK pktgen applications on Power systems.
> >>>
> >>> With the ifdef fixed, the core walks the list in the reverse direction
> >>> as intended, the code still worked (i.e. no errors or problems were
> >>> observed in the same test applications).
> >>>
> >>> I'm not completely familiar with why memseg lists must be traversed in
> >>> the reverse direction for Power systems.  It might be something specific
> >>> to Power 8 systems which I'm not actually supporting on DPDK, only the
> >>> Power 9 systems that I use for for development and testing.
> >>>
> >> If the code makes no difference anyway, should we just take it out so?
> >
> > +1 :-)
>
> I think there's a need for a larger review of Power8 vs. Power9 support.
>   You currently need to specify Power8 as the DPDK build target (e.g.
> ppc_64-power8-linux-gcc) but all of our internal development and testing
> efforts are targeting Power9 systems.  My preference would be to drop
> Power8 support all together but I'm reluctant to make such a potentially
> large change so close to an LTS release target, and not without
> soliciting some community comment on the idea.  As a result, I'd prefer
> to keep the change "as is" for this release.

Ok, I will take it as is, but please do investigate this.
The lesser special cases like these, the better.


-- 
David Marchand


      reply	other threads:[~2019-10-24  7:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-25 21:42 [dpdk-dev] [PATCH] eal:ppc: fix incorrect ifdef for ppc_64 David Christensen
2019-09-26  7:43 ` Ferruh Yigit
2019-10-24  9:36   ` David Marchand
2019-10-16 15:16 ` David Marchand
2019-10-16 20:45   ` David Christensen
2019-10-17 16:18     ` Burakov, Anatoly
2019-10-17 16:35       ` David Marchand
2019-10-17 16:55         ` David Christensen
2019-10-24  7:40           ` David Marchand [this message]

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=CAJFAV8yau524MC+kaAdMwdvXYV9ho3wFbORcng2YzNfmBZw7oA@mail.gmail.com \
    --to=david.marchand@redhat.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=drc@linux.vnet.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.