From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 73761A046B for ; Fri, 28 Jun 2019 15:15:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 05E363798; Fri, 28 Jun 2019 15:15:08 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id EAD6134F0 for ; Fri, 28 Jun 2019 15:15:06 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jun 2019 06:15:05 -0700 X-IronPort-AV: E=Sophos;i="5.63,427,1557212400"; d="scan'208";a="337904297" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.21.39]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jun 2019 06:15:03 -0700 Date: Fri, 28 Jun 2019 14:15:00 +0100 From: Bruce Richardson To: "Burakov, Anatoly" Cc: dev@dpdk.org, thomas@monjalon.net, jerinj@marvell.com Message-ID: <20190628131500.GE347@bricha3-MOBL.ger.corp.intel.com> References: <20190530212525.40370-1-bruce.richardson@intel.com> <20190627104055.8244-1-bruce.richardson@intel.com> <20190627104055.8244-5-bruce.richardson@intel.com> <20190628124641.GD347@bricha3-MOBL.ger.corp.intel.com> <387fee66-aa62-e8ed-3f3b-4bdbf033f7fa@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <387fee66-aa62-e8ed-3f3b-4bdbf033f7fa@intel.com> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH v3 4/8] raw/ioat: create device on probe and destroy on release X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list 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 Fri, Jun 28, 2019 at 01:59:26PM +0100, Burakov, Anatoly wrote: > On 28-Jun-19 1:46 PM, Bruce Richardson wrote: > > On Thu, Jun 27, 2019 at 01:28:04PM +0100, Burakov, Anatoly wrote: > > > On 27-Jun-19 11:40 AM, Bruce Richardson wrote: > > > > Add the create/destroy driver functions so that we can actually allocate > > > > a rawdev and destroy it when done. No rawdev API functions are actually > > > > implemented at this point. > > > > > > > > Signed-off-by: Bruce Richardson > > > > --- > > > > > > > > > > > > > + rawdev->driver_name = dev->device.driver->name; > > > > + > > > > + ioat = rawdev->dev_private; > > > > + ioat->rawdev = rawdev; > > > > + ioat->regs = dev->mem_resource[0].addr; > > > > + ioat->ring_size = 0; > > > > + ioat->desc_ring = NULL; > > > > + ioat->status_addr = rte_malloc_virt2iova(ioat) + > > > > + offsetof(struct rte_ioat_rawdev, status); > > > > > > While reviewing other patch, i remembered that i've seen this here. You > > > can't make any guarantees about IOVA addresses in rte_malloc-allocated > > > memory. Are you sure you don't require IOVA-contiguous memory here? > > > > > Presumably we can guarantee that for structures less than 1 page in size, > > this will work? I believe the device structure should be within that page > > limit. > > > > No, we can't. That would only be true if you were allocating IOVA-contiguous > memory. Otherwise there's nothing stopping the allocator to allocate even a > few kilobytes across page boundary. > > You can only ever guarantee that *one cache line* will not cross the page > boundary with rte_malloc. With rte_memzone and IOVA_CONTIG flag, you'll be > able to guarantee IOVA-contiguousness in all cases (or allocation failure). > Ok, so I either need to move this field to the start of the structure, i.e. have offset zero, or else use contiguous allocation. Will fix in next version. /Bruce