From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by dpdk.org (Postfix) with ESMTP id BBAF45954 for ; Tue, 25 Aug 2015 20:00:00 +0200 (CEST) Received: by obbwr7 with SMTP id wr7so149307831obb.2 for ; Tue, 25 Aug 2015 11:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UU4HVNP841HeybwB+SHyk4n9g0kBDD2cjbLjq5UTrzg=; b=wZvc1uHaKib+h02kur09GKcUakJrg7cXken0jT12hAu5R2zDm/47IGPZIYyvqctEDv AuJeKb8tcGFCOl8HRrUih2lwaYJNFJGtYaioMtx66K3vsqBZVmoW22PCv0Z77jyYiRpi 82uinJy9M1i7KkfOmliJD1qQt7j2UGlpyb/QbUb3aDyGEKezdfFCC/tODvbnmamosgIE yQRMJ7mmpy3mv/qsJUxPSvH8PcWXKsPex1hRlmG2ZzVOZTi43Vms5///TkfLV1v4X86+ 6rN3DatavsLudBA+UPkmYus7us/6hi76dLhyYGnV911IDpUo1eILFN6B0+VBws3XJ7uh wYWw== MIME-Version: 1.0 X-Received: by 10.60.124.35 with SMTP id mf3mr29270650oeb.15.1440525600058; Tue, 25 Aug 2015 11:00:00 -0700 (PDT) Received: by 10.202.65.197 with HTTP; Tue, 25 Aug 2015 10:59:59 -0700 (PDT) In-Reply-To: <55D69C00.2020609@igel.co.jp> References: <1440013341-29659-1-git-send-email-rkerur@gmail.com> <1440013376-29715-1-git-send-email-rkerur@gmail.com> <55D53655.1040808@igel.co.jp> <55D69C00.2020609@igel.co.jp> Date: Tue, 25 Aug 2015 10:59:59 -0700 Message-ID: From: Ravi Kerur To: Tetsuya Mukawa , Thomas Monjalon Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v2] Change rte_eal_vdev_init to update port_id X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 18:00:01 -0000 Hi Thomas, David Let us know how you want us to fix this? To fix rte_eal_vdev_init and rte_eal_pci_probe_one to return allocated port_id we had 2 approaches mentioned in earlier discussion. In addition to those we have another approach with changes isolated only to rte_ether component. I am attaching diffs (preliminary) with this email. Please let us know your inputs since it involves EAL component. Thanks, Ravi On Thu, Aug 20, 2015 at 8:33 PM, Tetsuya Mukawa wrote: > On 2015/08/21 4:16, Ravi Kerur wrote: > > > > > /** > > > * Uninitalize a driver specified by name. > > > @@ -125,6 +127,38 @@ int rte_eal_vdev_init(const char *name, > > const char *args); > > > */ > > > int rte_eal_vdev_uninit(const char *name); > > > > > > +/** > > > + * Given name, return port_id associated with the device. > > > + * > > > + * @param name > > > + * Name associated with device. > > > + * @param port_id > > > + * The port identifier of the device. > > > + * > > > + * @return > > > + * - 0: Success. > > > + * - -EINVAL: NULL string (name) > > > + * - -ENODEV failure > > > > Please define above in 'rte_ethdev.h.' > > > > > > Hi Tetsuya, > > > > I would like to take a step back and explain why function declarations > > are in rte_dev.h and not in rte_ethdev.h > > > > Approach 1: > > Initially I thought of modifying driver init routine to return/update > > port_id as the init routine is the place port_id gets allocated and it > > would have been clean approach. However, it required changes to all > > PMD_VDEV driver init routine to modify function signature for the > > changes which I thought may be an overkill. > > > > Approach 2: > > Instead I chose to define 2 functions in librte_ether/rte_ethdev.c and > > make use of it. In this approach new functions are invoked from > > librte_eal/common/.c to get port_id. If I had new function > > declarations in rte_ethdev.h and included that file in > > librte_eal/common/.c files it creates circular dependancy and > > compilation fails, hence I took hybrid approach of definitions in > > librte_ether and declarations in librte_eal. > > > > Please let me know if there is a better approach to take care of your > > comments. As it stands declarations cannot be moved to rte_ethdev.h > > for compilation reasons. > > > > Thanks, > > Ravi > > > > Hi Ravi, > (Adding David) > > I appreciate your description. I understand why you define the functions > in rte_dev.h. > > About Approach2, I don't know a way to implement cleanly. > I guess if we define the functions in rte_dev.h, the developers who want > to use the functions will be confused because the functions are > implemented in ethdev.c, but it is needed to include rte_dev.h. > > To avoid such a confusion, following implementation might be worked, but > I am not sure this cording style is allowed in eal library. > > ---------------------------- > Define the functions in rte_ethdev.h, then fix librte_eal/common/.c > files like below > > ex) lib/librte_eal/common/eal_common_dev.c > ---------------------------- > +#include > #include > #include > #include > > #include "eal_private.h" > > +extern int rte_eth_dev_get_port_by_name(const char *name, uint8_t > *port_id); > +extern int rte_eth_dev_get_port_by_addr(const struct rte_pci_addr > *addr, uint8_t *port_id); > ---------------------------- > > In this case, the developer might be able to notice that above usage in > eal library is some kind of exception. But I guess the DPDK code won't > be clean if we start having a exception. > So it might be good to choose Approach1, because apparently it is > straight forward. > Anyone won't be confused and complained about coding style. > > > Hi David, > > Could you please let us know what you think? > Do you have a good approach for this? > > Thanks, > Tetsuya > >