From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas.monjalon@6wind.com> Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 7124B6CA1 for <dev@dpdk.org>; Fri, 8 Jul 2016 16:03:43 +0200 (CEST) Received: by mail-wm0-f52.google.com with SMTP id f126so13941873wma.1 for <dev@dpdk.org>; Fri, 08 Jul 2016 07:03:43 -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=l5KupTRGV9Hdt6VaIAKhU8GyuTq0bEbVCStnPO+rt04=; b=WDfOo1Kf6srbaKD9EJFytzz0f+YLAveKAZOgVR5mTi6O4mol8Ok2ncs9ftM7zKcaoo aEoIH9r1go/tLgLqfYtvkzJRciu4z221XdfsN72CvjLmacJoeXS6CJ9gaYtsxOvgGNoy h6mmbSNiSCPktRVqfJ11tr4fv9lDt/c8LGAQ7AJuBsfCbMaNxCJokk/P7bgPdNJHWZCw XlC39QQ3nlBs1FLC9/WyiS+iauDijwI4k9MbrfUSx5xWrRabN9vsIeN3aTfGRkgOFLc+ DfF9zREbPlcxpsQGSYzz+PZPQbNeG+XnbZxCyr/KmDqfXv0dviIs+zSXRvhAVN3LWuV2 TpbQ== 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=l5KupTRGV9Hdt6VaIAKhU8GyuTq0bEbVCStnPO+rt04=; b=ZhJDq2bSmTTKfHrI9tu3ekXg+NIH9RKpjdxIR/KI+ulhab6YGPrCmDHECt/qlqXl1g VI+7c/5TTA9S1xsMR25i5Yq6TE23p8uoy9VT4Vv2tqqhRa83DBu/xATY7DP6Bn+QDv9i GFo7WUsA76/8ur/vsnzwu47POBsXMjWZO71bZd2UgX7pUBWK9A0MhYQggRk/nZbt53Gl y0PBKkXwtKmQTIJyn+aqcoKcZPQUconIASgHU/BSK/PHcBxs1kghKCGGFDYcl+4Omvp7 mhF7RWIb/Iob29h7xEhMtQixLOggFsgSb05O19VtTsbxem3LsiTqB+E0M1umv3D5OYH+ XBmg== X-Gm-Message-State: ALyK8tISfL+WenqyyannodFKjHXcyOXU1TZr5D4/l0B9DvcBFuhYo1XFTKsSaS0NVnKAUwC6 X-Received: by 10.28.66.148 with SMTP id k20mr3791480wmi.55.1467986622711; Fri, 08 Jul 2016 07:03:42 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id q203sm3187159wmd.24.2016.07.08.07.03.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jul 2016 07:03:41 -0700 (PDT) From: Thomas Monjalon <thomas.monjalon@6wind.com> To: Neil Horman <nhorman@tuxdriver.com> Cc: David Marchand <david.marchand@6wind.com>, dev@dpdk.org, Jan Viktorin <viktorin@rehivetech.com> Date: Fri, 08 Jul 2016 16:03:40 +0200 Message-ID: <1960485.iIdzW2D0ke@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160708135643.GC14917@hmsreliant.think-freely.org> References: <1467905790-10597-1-git-send-email-thomas.monjalon@6wind.com> <CALwxeUv_davrQO+wkTr8Ciqyt3LjgYooRaxN5aRzFLmE8vY6bg@mail.gmail.com> <20160708135643.GC14917@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 09/11] eal: move PCI table macro 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, 08 Jul 2016 14:03:43 -0000 2016-07-08 09:56, Neil Horman: > On Fri, Jul 08, 2016 at 10:49:25AM +0200, David Marchand wrote: > > Hello Thomas, Neil, > > > > (will be back in a couple of days, thanks Thomas for pointing this thread) > > > > > > On Thu, Jul 7, 2016 at 6:25 PM, Thomas Monjalon > > <thomas.monjalon@6wind.com> wrote: > > > 2016-07-07 12:11, Neil Horman: > > >> On Thu, Jul 07, 2016 at 05:36:28PM +0200, Thomas Monjalon wrote: > > >> > Remove include of rte_pci.h in the generic header rte_dev.h > > >> > and move the macro DRIVER_REGISTER_PCI_TABLE in rte_pci.h. > > > [...] > > >> > > >> This seems strange to me, in that its odd for the driver information export > > >> macros to be spread out in multiple locations. Specifically it enjoins the use > > >> of the DRV_EXP_TAG macro, which helps centralize tag naming. Perhaps the happy > > >> medium is to place all the export macros (includnig PMD_REGISTER_DRIVER) into > > >> its own pmd_register.h header? > > > > > > I don't know. > > > David, your opinion? > > > > - The suggestion I did offline to Thomas was to move pci stuff in pci headers. > > We are trying to move from the "all pci" code in eal to accomodate for > > other "buses" / architectures. > I get that, but I'm not sure that applies here. The macro in question is > specific to pci busses, and if there is additional bus information to export, it > will have its own macro (e.g. DRIVER_REGISTER_USB_TABLE or some such). While > I could see that being an argument for putting each macro in with its own bus > type, I think thats the wrong organization here, in that people writing drivers > will want to know what export macros are available and will expect to look in a > single place for it. > > > Having a pci macro in a generic header like rte_dev.h is wrong to me. > > Moving this to a new header like pmd_register.h sounds like a new > > generic header with pci specific stuff in it. > Well, yes, but I see that as no different than rte_ethdev.c or rte_pdump.c. > both of those files will need to know about all the different types of busses > you support and have to include those corresponding header files (i.e. they will > have to include rte_pci.h, rte_usb.h, rte_i2c.h, etc). This is really no > different in my mind. > > > So, I am not sure I follow you Neil. > > > > Can you elaborate ? > > > I suppose the best way to describe it is that while I understand and support the > desire to separate and abstract bus information away from device function, I > think theres a pragmatic descision here to prioritize functional domain over > header inclusion. That is to say, I think when people are writing a driver, it > will be helpful to have all the export macros in a single location so they know > what information they can export, and that includes registration of various bus > type identifiers. So a file like pmd_registration.h that includes rte_pci.h, > rte_usb.h, rte_i2c.h, etc is more useful to a developer, than spreading these > macros out to those various header files, for the sake of avoiding a potentially > unneeded include. > > > > > - Why do you want to centralise the tag naming ? > > To avoid collisions ? > Yes, and to centralize that information. Since the pmdinfogen tool needs to > know what those tag names are as well, its useful to keep them in the same area > to maintain co-ordination. Its also useful because it means we can use one > macro to define tag naming convention, instead of having to re-implement or > dead-reckon it in multiple files. > > > Well, adding those tags should not happen that often and I think we > > can maintain this with careful reviews. > I don't agree with that. This discussion is based on the fact that you expect > that we will be adding additional bus types in the future correct? Well, given > that we have a pci bus specific export macro, I would expect that to proliferate > to every other bus type as well, and so we can expect to at least have a new > tag added for every bus that is added, in addition to any other bus agnostic > information people wish to export (just off hand, looking at the linux modinfo > section, we might expect module author, module version, alias names, licensing > infomration, and others to be potential export candidates). So, depending on > how much this is adopted, I think we can potentially expect a great deal of > additional tagging to be needed. Anyway, this macro do not need rte_pci.h. So the minimal patch can be to just remove this include.