From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id 7807E201 for ; Fri, 23 Dec 2016 13:47:45 +0100 (CET) Received: by mail-wm0-f42.google.com with SMTP id m1so3566567wme.0 for ; Fri, 23 Dec 2016 04:47:45 -0800 (PST) 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=6/nlGRuTjotQmCR3N7AsqONoVGtTigc8PtQX6hMtQPs=; b=TGCgkFysVtC+kmGB8Q9ULxdxUM7YnsTnTN9gUX0fz38XN7Toc+zRBBN9aWqWXOZnil 6GSihhVj/vBzpHmHDjZVPoQBoix5OdN5ECT9y8a4Y+hb2vmBOOSCUGFypZFJ+FntaRdz Fe9+QgDnLqOnpabN1+ujiwepxcKO6lBNJ3zS4Qd8d0ccOsVIRkh4lqJ/vB8p6lrtmzjN AofaEBn2TNYh7NIhz9n/Z8hkXzVLqqYtYCoJsEhgssZU774vK7Wndpd+zpM/X8x/REjH qWkOIDfGMUvbZniOcwZZYilL25AnK5lbATauplG1B04wgYcR7uA6ebZy2x0U9wklKy3S eFIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=6/nlGRuTjotQmCR3N7AsqONoVGtTigc8PtQX6hMtQPs=; b=ujfjDdUbBKl/YLSUjhXvO8csAHdV1oah5WoQdQOX05wBwT3rBC3m6IQJYmrFaGQSQN XYsttGfND2ihZGqZnsWa6mX7SjPmpNrPXXZ+yVybj5WVZ2TEKsroh6pyFG0nRURxiqQs zK/Fsu4RTTsj3gm7QTj4LzzqvQraMYAHNbhv/l2kReoIGRTjWD9KDMLCgpyABBdczAOp EWtM6ybWnFv78dcMy+LZ4sxzIZUUyhnSiunUmOYBLpi4i7MODLVA5SJnXst+OF+Jwmgs vjTmIeDJnSr1CJLceEUOyaD+GTeZ0Q4493FT8ctET6d/I1Wr8SYYIFebj7uhKXMK9/Nc Tu8A== X-Gm-Message-State: AIkVDXL2pPfxAD7z4OxjW21tV6uAIKpZmsqEGL29b4rmoyn8rrlfc5s7zcYvpKfCbWSDpFmS X-Received: by 10.28.35.205 with SMTP id j196mr14226720wmj.62.1482497264888; Fri, 23 Dec 2016 04:47:44 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id l6sm37007435wmd.5.2016.12.23.04.47.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Dec 2016 04:47:43 -0800 (PST) From: Thomas Monjalon To: Jan Blunck Cc: dev@dpdk.org, Shreyansh Jain , David Marchand , Stephen Hemminger Date: Fri, 23 Dec 2016 13:47:42 +0100 Message-ID: <1921808.Bo5Y97VPPb@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <1482332986-7599-1-git-send-email-jblunck@infradead.org> <4070328.Wvu0M6jAFZ@xps13> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v4 18/23] ethdev: Helper to map to struct rte_pci_device 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: , X-List-Received-Date: Fri, 23 Dec 2016 12:47:45 -0000 2016-12-23 11:27, Jan Blunck: > On Fri, Dec 23, 2016 at 9:30 AM, Thomas Monjalon > wrote: > > 2016-12-22 19:13, Jan Blunck: > >> On Thu, Dec 22, 2016 at 4:21 PM, Thomas Monjalon > >> wrote: > >> > 2016-12-21 16:09, Jan Blunck: > >> >> PCI drivers could use this helper instead of directly accessing fields of > >> >> rte_eth_dev to map to rte_pci_device. > >> > [...] > >> >> +/** > >> >> + * @internal > >> >> + * Helper for drivers that need to convert from rte_eth_dev to rte_pci_device. > >> >> + */ > >> >> +static inline struct rte_pci_device *__attribute__((always_inline)) > >> >> +rte_eth_dev_to_pci(struct rte_eth_dev *eth_dev) > >> >> +{ > >> >> + return eth_dev->pci_dev; > >> >> +} > >> > > >> > Why adding this function instead of just using DEV_PCI_DEV(eth_dev->device)? > >> > > >> > I think we must try to avoid any PCI (or other bus) reference inside ethdev.h. > >> > >> David requested to move it from rte_pci.h to rte_ethdev.h. > >> > >> It could get forward declared here if one doesn't use it. On the other > >> hand the rte_pci.h would be required to include rte_ethdev.h if we > >> move it. > > > > I think there is a misunderstanding. > > I was just suggesting to drop this function. > > But that would undo the whole purpose of adding a helper. The purpose > of the helper is to map from ethdev to the low-level rte_pci_device. > If we remove this helper all users still need to know how to map to > the embedded device structure. What you ask for also means that the > patch "ethdev: Decouple struct rte_eth_dev from struct rte_pci_device" > needs to change all users of the DEV_PCI_DEV() instead of changing the > helper introduced in this patch. Yes, using RTE_PCI_DEV(eth_dev->device) instead of rte_eth_dev_to_pci(eth_dev). Is it a problem to know that the field name is "device" to access the underlying device characteristics? > Let me summarize the workable options from my perspective: > 1. helper macro to map from eth_dev to pci_dev in rte_pci.h > 2. helper inline function to map from eth_dev to pci_dev in rte_ethdev.h > 3. put helpers into new header file rte_ethdrv.h > > I'm still in favor of the first option but David suggested to remove > it from eal. I could also counter the type-safety argument from > Stephen by adding a type check to it. My proposal is: 4. no helper, use eth_dev->device