From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <aconole@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
 by dpdk.org (Postfix) with ESMTP id E7CC0917F
 for <dev@dpdk.org>; Thu, 17 Aug 2017 14:35:12 +0200 (CEST)
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com
 [10.5.11.12])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mx1.redhat.com (Postfix) with ESMTPS id 9CB362E95AE;
 Thu, 17 Aug 2017 12:35:11 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9CB362E95AE
Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com;
 dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com;
 spf=fail smtp.mailfrom=aconole@redhat.com
Received: from dhcp-25-97.bos.redhat.com (unknown [10.18.25.172])
 by smtp.corp.redhat.com (Postfix) with ESMTPS id E8FDB619EF;
 Thu, 17 Aug 2017 12:35:07 +0000 (UTC)
From: Aaron Conole <aconole@redhat.com>
To: Santosh Shukla <santosh.shukla@caviumnetworks.com>
Cc: dev@dpdk.org, olivier.matz@6wind.com, thomas@monjalon.net,
 jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com,
 maxime.coquelin@redhat.com, sergio.gonzalez.monroy@intel.com,
 bruce.richardson@intel.com, shreyansh.jain@nxp.com, gaetan.rivet@6wind.com,
 anatoly.burakov@intel.com, stephen@networkplumber.org
References: <20170724084004.25542-1-santosh.shukla@caviumnetworks.com>
 <20170814161059.6684-1-santosh.shukla@caviumnetworks.com>
 <20170814161059.6684-2-santosh.shukla@caviumnetworks.com>
Date: Thu, 17 Aug 2017 08:35:06 -0400
In-Reply-To: <20170814161059.6684-2-santosh.shukla@caviumnetworks.com>
 (Santosh Shukla's message of "Mon, 14 Aug 2017 21:40:48 +0530")
Message-ID: <f7t378qpe2t.fsf@dhcp-25-97.bos.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16
 (mx1.redhat.com [10.5.110.29]); Thu, 17 Aug 2017 12:35:12 +0000 (UTC)
Subject: Re: [dpdk-dev] [PATCH v6 01/12] eal/pci: introduce PCI driver iova
	as va flag
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: Thu, 17 Aug 2017 12:35:13 -0000

Santosh Shukla <santosh.shukla@caviumnetworks.com> writes:

> Introducing RTE_PCI_DRV_IOVA_AS_VA flag. Flag used when driver needs
> to operate in iova=va mode.
>
> Why driver need iova=va mapping?
>
> On NPU style co-processors like Octeontx, the buffer recycling has been
> done in HW, unlike SW model. Here is the data flow:
> 1) On control path, Fill the HW mempool with buffers(iova as pa address)
> 2) on rx_burst, HW gives you IOVA address(iova as pa address)
> 3) As application expects VA to operate on it, rx_burst() needs to
> convert to _va from _pa. Which is very expensive.
> Instead of that if iova as va mapping, we can avoid the cost of
> converting with help of IOMMU/SMMU.
>
> Signed-off-by: Santosh Shukla <santosh.shukla@caviumnetworks.com>
> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> ---

This should be folded into patch 5;  there's no clear need for it until
then.