From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas.monjalon@6wind.com> Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id DDBC99619 for <dev@dpdk.org>; Fri, 13 May 2016 15:49:25 +0200 (CEST) Received: by mail-wm0-f45.google.com with SMTP id g17so3626696wme.0 for <dev@dpdk.org>; Fri, 13 May 2016 06:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=gbidYL8989H3rZeKP0ZPQjQ9rdudOEjWam6OpfeK7ug=; b=CvTBEOginK67iq5hoSHOq8DyrwglKhWa0Kc/Yx565erdrwpydw5x/f8by9ew5turfk CZzUB/p7oYRZY0ltlWMYQ0WbgwOVVkLFui0CHw1acUbIb/z4kEo+i1+K2bv3+CIxuKJE 3OKg7qgT/4OsDmx74fa2IuM6Y+7kZ8Oe1S23RjpInKwQQePWHCbg8gIm/YvAvWWVLXjq AsfkuJ1fCwxp92g7EuANGvWTfv1NLwVm+zqQb95xhy/fiv/FroRc66zb/LuJpThZl4uj 3mDly6wKSQf1vZcSSypTtC7xPC2nRf/DmqQ7T/no3yh/TqHdd72hLb+qQp6gf/IBJT5h NrOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=gbidYL8989H3rZeKP0ZPQjQ9rdudOEjWam6OpfeK7ug=; b=XrwbKgspNxbOyFHQ1SO4gyMRG2Ii5tkhaCX9Lba6iMwE5e0uddl7u8QKUDLJKJIOLa 1bbF18soQcoiKIA6AuDeqigGiQoBoBUjcShILu+lx3exQMNRRhBNsp4x44rNiWCRBqy7 FFmwdErsKi+sWXQQjCgGCo6Hq8eQYNGtq4jE98u/5ZDSSmQHXbW+n6+j0K5xx5C9XoRl xg9gswRHgh0IC3Zdmb3yMlfTHMfGqdhR82sn79f8M6P96SrtfqxDyAYOuDDnjxNcTZyM Qi1JFnWuDoV8H3gvMxOed62Mz/fwBPLfG6jRd+GyR8jaoP5H89IQ7CONuNag6SSsUYLv z5fg== X-Gm-Message-State: AOPr4FUXEFhrmnrJuy+lXPixK5C9brjCSsrIw364MAUGA72NAaIvqVhRquUjKR1Qn9gAl6Q/ X-Received: by 10.28.126.145 with SMTP id z139mr3746522wmc.81.1463147365567; Fri, 13 May 2016 06:49:25 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id ck9sm18797977wjc.22.2016.05.13.06.49.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 May 2016 06:49:24 -0700 (PDT) From: Thomas Monjalon <thomas.monjalon@6wind.com> To: Alejandro Lucero <alejandro.lucero@netronome.com> Cc: Jan Viktorin <viktorin@rehivetech.com>, dev@dpdk.org Date: Fri, 13 May 2016 15:49:23 +0200 Message-ID: <1564181.pBqibqOBc3@xps13> User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <CAD+H993xy7EBE8SyzFNEbp0Eb3L1BZra9cSCZJtSPD79fX3RjA@mail.gmail.com> References: <1463063640-30715-3-git-send-email-alejandro.lucero@netronome.com> <20160512174110.5f0b3551@pcviktorin.fit.vutbr.cz> <CAD+H993xy7EBE8SyzFNEbp0Eb3L1BZra9cSCZJtSPD79fX3RjA@mail.gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [dpdk-dev, 2/3] eth_dev: add support for device dma mask X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <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, 13 May 2016 13:49:26 -0000 2016-05-13 09:38, Alejandro Lucero: > On Thu, May 12, 2016 at 4:41 PM, Jan Viktorin <viktorin@rehivetech.com> > > Alejandro Lucero <alejandro.lucero@netronome.com> wrote: > > > On Thu, May 12, 2016 at 3:52 PM, Jan Viktorin <viktorin@rehivetech.com> > > > > "Alejandro.Lucero" <alejandro.lucero@netronome.com> wrote: > > > > > - New dma_mask field in rte_eth_dev_data. > > > > > - If PMD sets device dma_mask, call to check hugepages within > > > > > > > > I think that one of the purposes of DPDK is to support DMA transfers > > > > in userspace. In other words, I can see no reason to support dma_mask > > > > at the ethdev level only. > > > > > > > > The limitation is a device limitation so I can not see a better place > > for > > > adding the device dma mask. > > > > That's what I've meant. It is a _device_ limitation. The ethdev is a > > wrapper > > around the rte_pci_device. The ethdev just extends semantics of the > > generic device. > > However, all DPDK devices are expected to be DMA-capable. > > > > If you get a pointer to the ethdev, you get a pointer to the > > rte_pci_device as well > > (1 more level of dereference but we are not on the fast path here, so it's > > unimportant). > > > > Consider the cryptodev. If cryptodev has some DMA mask requirements we can > > support it > > in the generic place, i.e. rte_pci_device and not rte_ethdev because the > > cryptodev > > is not an ethdev. > > > Ok. I was wrongly assuming we had just ethdevs, with the ethdev being the > generic and rte_pci_device being a type of ethdev. > > I can add the dma mask to the rte_pci_dev. The extra level of dereference > is not a problem as long as we do not use that dma mask for a more complex > allocation API (more about this later). > > If I understand it right, work is in progress for adding a rte_device. I > can not see a problem with adding dma mask to the rte_device struct either. > > > > > We should consider adding this to the generic struct rte_device > > > > (currently rte_pci_device). Thomas? Yes This patchset could be split in 2 discussions: - ability to restrict the physical address range of requested memory, see the memory allocation rework discussion: http://dpdk.org/ml/archives/dev/2016-April/037444.html - DMA range capability in a device, to be done on top of the EAL/device rework in progress. This feature is a good candidate for the roadmap of 16.11.