From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <thomas@monjalon.net>
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
[66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 8171C1B254
for <dev@dpdk.org>; Fri, 6 Oct 2017 09:24:26 +0200 (CEST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
by mailout.nyi.internal (Postfix) with ESMTP id 0933B20E35;
Fri, 6 Oct 2017 03:24:26 -0400 (EDT)
Received: from frontend2 ([10.202.2.161])
by compute1.internal (MEProxy); Fri, 06 Oct 2017 03:24:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
cc:content-transfer-encoding:content-type:date:from:in-reply-to
:message-id:mime-version:references:subject:to:x-me-sender
:x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=1edbrL8f7rUlwQc
uASYTrmlOcMNtYWUCSV+munmUXsg=; b=LGWOvNv+1FRU/UW4Tcg2AAuKqau+5Hk
ptrBpMTsBPgZ+0og0wVnQ6hlnjCX/C4as+SBtpp3aFe1VBOyu0wLe9T/WTp/1Asj
cL1Gpq2+n+hqTAcOBeMu64f8L5qiZYvJf0TLMd2rJNhd4o6IR3LrtoZ0GukPVF+L
cJsrW3sYmXCI=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:content-transfer-encoding:content-type
:date:from:in-reply-to:message-id:mime-version:references
:subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s=
fm1; bh=1edbrL8f7rUlwQcuASYTrmlOcMNtYWUCSV+munmUXsg=; b=fB2YwmiM
OzpqGQ1r5eUG8yfsxkPHyygTSnriFkBZNYEGqZTjr3lq22IpklN+GnZ+eNv2/s1l
IU0bQOvelzO8c/+3jo39qJu5CtpgsShERDnBWY0F1iL8HqX9QJUe9uY7Qd93uLuI
vSxjvBRHBCUmDKjiwlatnRPq/jwbFbSvJ4cCQW4x9cdj87YdEo1iFgzwqAr12P4g
xd6frTroMfawUhykZ5WWVLF+GGK3K8+xE3HcEM11J42yGyV36KSXuSvFgI0SItM6
VH8FDdRfmG4F92wJRmXi//fy9o/XOTx2/3cLY4ZCqvybGdybh5PO9t1h0nqvBAdT
yu1JTK8WXpMYmg==
X-ME-Sender: <xms:qS_XWc5d2gc3xn_mKg3bCpD6sFUbjYjEW7opn6BjX1j54exMutXybg>
X-Sasl-enc: RZEWJYe+bsiMtbLjcNSSac5H7IQwMztLf7IRnH8JH+qL 1507274665
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
by mail.messagingengine.com (Postfix) with ESMTPA id AD36124009;
Fri, 6 Oct 2017 03:24:25 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: santosh <santosh.shukla@caviumnetworks.com>
Cc: dev@dpdk.org, olivier.matz@6wind.com, jerin.jacob@caviumnetworks.com,
hemant.agrawal@nxp.com, aconole@redhat.com, stephen@networkplumber.org,
anatoly.burakov@intel.com, gaetan.rivet@6wind.com, shreyansh.jain@nxp.com,
bruce.richardson@intel.com, sergio.gonzalez.monroy@intel.com,
maxime.coquelin@redhat.com
Date: Fri, 06 Oct 2017 09:24:24 +0200
Message-ID: <2281320.59S7KcHRhB@xps>
In-Reply-To: <ba993794-98c0-688a-a266-c33836d355ad@caviumnetworks.com>
References: <20170918104234.9149-1-santosh.shukla@caviumnetworks.com>
<5989047.qJ3B3g597f@xps>
<ba993794-98c0-688a-a266-c33836d355ad@caviumnetworks.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-dev] [PATCH v9 2/9] eal/pci: get iommu class
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Oct 2017 07:24:26 -0000
06/10/2017 05:04, santosh:
> Thomas,
>
> You comment is annoying and infuriating both.
> Patch is their for more than 4month, had enough time for you to comment
> and understand the topic. Thorough review and testing has happened both.
>
> NOTE: You have already delayed this series by one release and
> I'm guessing that you intent to push by one more, if you had such
> mundane question then why not ask before? Make me think that you are
> wasting my time and effort both.
You misunderstand me.
My intent is to push this patch.
A lot of people have reviewed it during this cycle.
I was just looking for wording details in order to ease people
when they will see this abstraction in the code base.
> On Friday 06 October 2017 05:28 AM, Thomas Monjalon wrote:
>
> > This patch is introducing a new abstraction.
> > It is important to explain it for future readers of this code.
>
> If you don't know - What is iova? How to program iova?
> purpose of iova then should read and educate your know - how first.
>
> Yes, its is introducing new abstraction, because dpdk from
> ancient days does only one programming mode aka iova=pa.
>
> note:You were still using iova mode as _pa (and didn't care to ask yourself about IOVA!)
> which is one of iova mode too!.
>
> However, IOMMU can also generate _va address too called iova=_va mode..
> which is also correct/viable/applicable/Okiesh programming mode
> for iommu capable HW like dma for example(Note again,.. AGNOSTIC behavior of iommu).
>
> Now Why dpdk needs to understand IOVA programming philosophy:
>
> Though DPDK was _silenty_ using iova as pa mode but then there
> is a need arise to make mapping mode explicit and for that we need
> abstraction since there wasn't one existed.
>
> Reason:
> Because From last few years,.ONA participants like Cavium, nxp
> added ARM arch support in dpdk and included drivers for their HW..
> and their hw has use-case (example external mempool), such a way that
> programming those HW in iova as va mode would save cycle in fast path
> (this part, we explained so many-1000 time in series and same understood by reviewer)
> thus its vital to introduce iova infra in dpdk.
>
> Same applicable for intel HW blocks too. Its works for intel too!
I know all of that!
I was just thinking that you could add more explanations somewhere
in the code or the doc.
> > 20/09/2017 13:23, Santosh Shukla:
> >> +/**
> >> + * IOVA mapping mode.
> >> + */
> > Please explain what IOVA means and what is the purpose of
> > distinguish the different modes.
> >
> IOVA mapping mode is device aka iommu programming mode by which
> HW(iommu) will generate _pa or _va address accordingly.
In this doxygen block, it would be the right place to explain how the
IOVA mode will impact the rest of DPDK.
> >> +enum rte_iova_mode {
> >> + RTE_IOVA_DC = 0, /* Don't care mode */
> >> + RTE_IOVA_PA = (1 << 0),
> >> + RTE_IOVA_VA = (1 << 1)
> >> +};
> > You should explain each value of the enum.
>
> Aren't naming choice for each member of enum is self-explanatory?
> I don't find logic anymore in your question? are you asking about side commenting?
> if not then IFAIU, you question is basically about what is _pa and _va? if so then
> reader should have little know-how before they intent to do fast-path programming.
> Author can't write whole IOMMU spec for reader sake. Those are minute and mundate info
> incase any user want to program device in _pa or _va. I'm at loss with you question,
> I don;t see logic and it is frustrating to me. You had enough time for all this
> in case you had really cared,, we have series for external PMD and drivers waiting
> for iova infra, I see it a your move nothing bu blocking ONA series progress
> Don;t you trust Reviewer in case you have hard time understaing topic and that
> makese me to ask - Are you willing to accept this feature or not? if not then
> I'm wasting my energy on it.
Santosh, I'm sorry if you don't understand that I was just asking for
a bit more doc.
You could just add something like
/* DMA using physical address */
/* DMA using virtual address */
Anyway, if you don't want to add any explanation, it won't prevent
pushing this patch.