From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Richardson Subject: Re: [PATCH] pci/uio: enable prefetchable resources mapping Date: Thu, 5 Oct 2017 09:28:34 +0100 Message-ID: <20171005082834.GA20768@bricha3-MOBL3.ger.corp.intel.com> References: <1496530644-8393-1-git-send-email-changpeng.liu@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Changpeng Liu , dev@dpdk.org To: Ferruh Yigit Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 492B5199B0 for ; Thu, 5 Oct 2017 10:28:38 +0200 (CEST) Content-Disposition: inline In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Oct 05, 2017 at 01:06:41AM +0100, Ferruh Yigit wrote: > On 6/3/2017 11:57 PM, Changpeng Liu wrote: > > For PCI prefetchable resources, Linux will create a > > write combined file as well, the library will try > > to map resourceX_wc file first, if the file does > > not exist, then it will map resourceX as usual. > > Hi Changpeng, > > Code part looks OK, but can you please describe more why we should try > write combined resource file first, what is the benefit of using it _wc > file? > > Thanks, > ferruh > Also, if we use a write combining resource file, I believe we will use correct ordering of instructions within our drivers. Does applying this patch not also mean that we would need memory barriers inside all the drivers, so as to ensure that we don't have a queue doorbell write reordered with the descriptor writes? I don't think it's safe to apply this change on it's own, without driver changes, since all PMDs assume strong ordering on IA. Regards, /Bruce > > > > > Signed-off-by: Changpeng Liu > > --- > > lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 19 ++++++++++++++----- > > 1 file changed, 14 insertions(+), 5 deletions(-) > > > > diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c > > index fa10329..d9fc20a 100644 > > --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c > > +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c > > @@ -321,7 +321,7 @@ > > > > /* update devname for mmap */ > > snprintf(devname, sizeof(devname), > > - "%s/" PCI_PRI_FMT "/resource%d", > > + "%s/" PCI_PRI_FMT "/resource%d_wc", > > pci_get_sysfs_path(), > > loc->domain, loc->bus, loc->devid, > > loc->function, res_idx); > > @@ -335,13 +335,22 @@ > > } > > > > /* > > - * open resource file, to mmap it > > + * open prefetchable resource file first, try to mmap it > > */ > > fd = open(devname, O_RDWR); > > if (fd < 0) { > > - RTE_LOG(ERR, EAL, "Cannot open %s: %s\n", > > - devname, strerror(errno)); > > - goto error; > > + snprintf(devname, sizeof(devname), > > + "%s/" PCI_PRI_FMT "/resource%d", > > + pci_get_sysfs_path(), > > + loc->domain, loc->bus, loc->devid, > > + loc->function, res_idx); > > + /* then try to map resource file */ > > + fd = open(devname, O_RDWR); > > + if (fd < 0) { > > + RTE_LOG(ERR, EAL, "Cannot open %s: %s\n", > > + devname, strerror(errno)); > > + goto error; > > + } > > } > > > > /* try mapping somewhere close to the end of hugepages */ > > >