DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: santosh <santosh.shukla@caviumnetworks.com>
Cc: dev@dpdk.org, Shreyansh Jain <shreyansh.jain@nxp.com>,
	ferruh.yigit@intel.com, hemant.agrawal@nxp.com
Subject: Re: [dpdk-dev] [PATCH] bus/dpaa: fix memory allocation during bus scan
Date: Tue, 10 Oct 2017 18:17:04 +0200	[thread overview]
Message-ID: <1821646.02OIGBtUFx@xps> (raw)
In-Reply-To: <7387c315-fd0f-a5a2-fdd9-1ae9aed69e9b@caviumnetworks.com>

10/10/2017 16:05, santosh:
> Hi Thomas,
> 
> On Tuesday 10 October 2017 01:09 PM, Thomas Monjalon wrote:
> > 10/10/2017 09:01, Shreyansh Jain:
> >> Fixes: 5b22cf744689 ("bus/dpaa: introducing FMan configurations")
> >> Fixes: 37f9b54bd3cf ("net/dpaa: support Tx and Rx queue setup")
> > These lines should appear after the explanation.
> >
> >> Cc: shreyansh.jain@nxp.com
> >>
> >> With the IOVA auto detection changes, bus scan is performed before
> >> memory initialization. DPAA bus scan must not use rte_malloc in
> >> its path.
> > If the scan has been broken by IOVA detection, you should reference
> > IOVA in Fixes line, not DPAA.
> >
> hmm.. IOVA not breaking scanning!, Refer this [1].

It is breaking. A break is a behaviour or interface change.
When moving init order, you break behaviour.
I don't say it is bad.
I say only it is the primary cause of this change.

The Fixes: line is also a help when backporting patches.
This patch needs to be backported only if IOVA patch is also backported.

> We(me/hemant) has discussed about same on thread[1] and agreed to
> do respective changes and remove rte_ memory dependency from code base
> at scan time..
> 
> Thanks.
> 
> [1] http://dpdk.org/dev/patchwork/patch/26764/

You already discussed about this issue, fine.

Santosh, as you insist to talk again about it, one more comment:

It is very good to have discussions on the mailing list.
It would be perfect if all these informations were explicitly given
in the commit messages.
For instance, saying that the scan cannot use rte_malloc anymore is
a valuable tip for other developpers.

  reply	other threads:[~2017-10-10 16:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-10  7:01 Shreyansh Jain
2017-10-10  7:39 ` Thomas Monjalon
2017-10-10  9:19   ` Shreyansh Jain
2017-10-10 14:05   ` santosh
2017-10-10 16:17     ` Thomas Monjalon [this message]
2017-10-10 16:55       ` santosh
2017-10-11  5:17         ` Shreyansh Jain
2017-10-11  5:23           ` santosh
2017-10-10  9:34 ` [dpdk-dev] [PATCH v2] " Shreyansh Jain
2017-10-10 13:13   ` Thomas Monjalon

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=1821646.02OIGBtUFx@xps \
    --to=thomas@monjalon.net \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=santosh.shukla@caviumnetworks.com \
    --cc=shreyansh.jain@nxp.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).