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 626A2A046B for ; Fri, 28 Jun 2019 15:28:05 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0103234F0; Fri, 28 Jun 2019 15:28:04 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id DEFDBF04 for ; Fri, 28 Jun 2019 15:28:02 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jun 2019 06:28:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,427,1557212400"; d="scan'208";a="164660187" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.252.3.102]) ([10.252.3.102]) by fmsmga007.fm.intel.com with ESMTP; 28 Jun 2019 06:28:00 -0700 To: Bruce Richardson Cc: dev@dpdk.org, thomas@monjalon.net, jerinj@marvell.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> <20190628131500.GE347@bricha3-MOBL.ger.corp.intel.com> From: "Burakov, Anatoly" Message-ID: Date: Fri, 28 Jun 2019 14:28:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190628131500.GE347@bricha3-MOBL.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 28-Jun-19 2:15 PM, Bruce Richardson wrote: > 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 > The latter is probably more explicit in intention, i'd rather the code not rely on details of rte_malloc implementation :) -- Thanks, Anatoly