From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 1E4E04CE4 for ; Thu, 13 Dec 2018 16:13:36 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2018 07:13:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,349,1539673200"; d="scan'208";a="118308124" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.46]) ([10.237.221.46]) by FMSMGA003.fm.intel.com with ESMTP; 13 Dec 2018 07:13:33 -0800 To: "Lu, Wenzhuo" , "dev@dpdk.org" Cc: "Yang, Qiming" , "Li, Xiaoyun" , "Wu, Jingjing" References: <1542956179-80951-1-git-send-email-wenzhuo.lu@intel.com> <1544598004-27099-1-git-send-email-wenzhuo.lu@intel.com> <1544598004-27099-17-git-send-email-wenzhuo.lu@intel.com> <6A0DE07E22DDAD4C9103DF62FEBC09093FE13982@shsmsx102.ccr.corp.intel.com> From: Ferruh Yigit Openpgp: preference=signencrypt Autocrypt: addr=ferruh.yigit@intel.com; prefer-encrypt=mutual; keydata= mQINBFXZCFABEADCujshBOAaqPZpwShdkzkyGpJ15lmxiSr3jVMqOtQS/sB3FYLT0/d3+bvy qbL9YnlbPyRvZfnP3pXiKwkRoR1RJwEo2BOf6hxdzTmLRtGtwWzI9MwrUPj6n/ldiD58VAGQ +iR1I/z9UBUN/ZMksElA2D7Jgg7vZ78iKwNnd+vLBD6I61kVrZ45Vjo3r+pPOByUBXOUlxp9 GWEKKIrJ4eogqkVNSixN16VYK7xR+5OUkBYUO+sE6etSxCr7BahMPKxH+XPlZZjKrxciaWQb +dElz3Ab4Opl+ZT/bK2huX+W+NJBEBVzjTkhjSTjcyRdxvS1gwWRuXqAml/sh+KQjPV1PPHF YK5LcqLkle+OKTCa82OvUb7cr+ALxATIZXQkgmn+zFT8UzSS3aiBBohg3BtbTIWy51jNlYdy ezUZ4UxKSsFuUTPt+JjHQBvF7WKbmNGS3fCid5Iag4tWOfZoqiCNzxApkVugltxoc6rG2TyX CmI2rP0mQ0GOsGXA3+3c1MCdQFzdIn/5tLBZyKy4F54UFo35eOX8/g7OaE+xrgY/4bZjpxC1 1pd66AAtKb3aNXpHvIfkVV6NYloo52H+FUE5ZDPNCGD0/btFGPWmWRmkPybzColTy7fmPaGz cBcEEqHK4T0aY4UJmE7Ylvg255Kz7s6wGZe6IR3N0cKNv++O7QARAQABtCVGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBpbnRlbC5jb20+iQJVBBMBAgA/AhsDBgsJCAcDAgYVCAIJCgsE FgIDAQIeAQIXgBYhBNI2U4dCLsKE45mBx/kz60PfE2EfBQJbughWBQkHwjOGAAoJEPkz60Pf E2Eft84QAIbKWqhgqRfoiw/BbXbA1+qm2o4UgkCRQ0yJgt9QsnbpOmPKydHH0ixCliNz1J8e mRXCkMini1bTpnzp7spOjQGLeAFkNFz6BMq8YF2mVWbGEDE9WgnAxZdi0eLY7ZQnHbE6AxKL SXmpe9INb6z3ztseFt7mqje/W/6DWYIMnH3Yz9KzxujFWDcq8UCAvPkxVQXLTMpauhFgYeEx Nub5HbvhxTfUkapLwRQsSd/HbywzqZ3s/bbYMjj5JO3tgMiM9g9HOjv1G2f1dQjHi5YQiTZl 1eIIqQ3pTic6ROaiZqNmQFXPsoOOFfXF8nN2zg8kl/sSdoXWHhama5hbwwtl1vdaygQYlmdK H2ueiFh/UvT3WG3waNv2eZiEbHV8Rk52Xyn2w1G90lV0fYC6Ket1Xjoch7kjwbx793Kz/RfQ rmBY8/S4DTGn3oq3dMdQY+b6+7VMUeLMMh2CXYO9ErkOq+qNTD1IY+cBAkXnaDbQfz0zbste ZGWH74FAZ9nCpDOqbRTrBL42aMGhfOWEyeA1x7+hl6JZfabBWAuf4nnCXuorKHzBXTrf7u7p fXsKQClWRW77PF1VmzrtKNVSytQAmlCWApQIw20AarFipXmVdIjHmJPU611WoyxZPb4JTOxx 5cv9B+nr/RIB+v5dcStyHCCwO1be7nBDdCgd4F6kTQPLuQINBFfWTL4BEACnNA29e8TarUsB L5n6eLZHXcFvVwNLVlirWOClHXf44o2KnN3ww+eBEmKVfEFo9MSuGDNHS8Zw1NiGMYxLIUgd U6gGrVVs/VrQWL82pbMk6jCj98N+BXIri+6K1z+AImz7ax7iF1kDgRAnFWU0znWWBgM2mM8Y gDjcxfXk4sCKnvf6Gjo08Ey5zmqx7dekAKU2EEp8Q1EJY3jbymLdZWRP4AFFMTS1rGMk0/tt v71NBg1GobCcbNfn9chK/jhqxYhAJqq86RdJQkt3/9x1U1Oq0vXCt4JVVHmkxePtUiuWTTt+ aYlUAsKYZsWvncExvw77x2ArYDmaK0yfjh37wp0lY7DOJHFxoyT8tyWZlLci/VMRG2Ja33xj 0CN4C1yBg+QDeV3QFxQo42iA/ykdXPUR3ezmsND3XKvVLTC4DNb3V/EZQ7jBj64+bEK0VW4G B31VP00ApNQvSoczsIOAKdk97RNbpmPw6q10ILIB+9T1xbnFYzshzGF17oC0/GENIHATx8vZ masOZoDiOZQpeneLgnFE9JfzhLTxv6wNZcc/HLXRQVTkDsQr8ERtkAoHCf1E5+b5Yr7pfnE4 YuhET746o25S53ELUYPIs49qoJsEJL34/oexMfPGyPIlrbufiNyty5jc/1MRwUlhJlJ5IOHy ZUa+6CLR7GdImusFkPJUJwARAQABiQI8BBgBAgAmAhsMFiEE0jZTh0IuwoTjmYHH+TPrQ98T YR8FAlu6CHAFCQXE7zIACgkQ+TPrQ98TYR9nXxAAqNBgkYNyGuWUuy0GwDQCbu3iiMyH1+D7 llafPcK4NYy1Z4AYuVwC9nmLaoj+ozdqS3ncRo57ncRsKEJC46nDJJZYZ5LSJVn63Y3NBF86 lxQAgjj2oyZEwaLKtKbAFsXL43jv1pUGgSvWwYtDwHITXXFQto9rZEuUDRFSx4sg9OR+Q6/6 LY+nQQ3OdHlBkflzYMPcWgDcvcTAO6yasLEUf7UcYoSWTyMYjLB4QuNlXzTswzGVMssJF/vo V8lD1eqqaSUWG3STF6GVLQOr1NLvN5+kUBiEStHFxBpgSCvYY9sNV8FS6N24CAWMBl+10W+D 2h1yiiP5dOdPcBDYKsgqDD91/sP0WdyMJkwdQJtD49f9f+lYloxHnSAxMleOpyscg1pldw+i mPaUY1bmIknLhhkqfMmjywQOXpac5LRMibAAYkcB8v7y3kwELnt8mhqqZy6LUsqcWygNbH/W K3GGt5tRpeIXeJ25x8gg5EBQ0Jnvp/IbBYQfPLtXH0Myq2QuAhk/1q2yEIbVjS+7iowEZNyE 56K63WBJxsJPB2mvmLgn98GqB4G6GufP1ndS0XDti/2K0o8rep9xoY/JDGi0n0L0tk9BHyoP Y7kaEpu7UyY3nVdRLe5H1/MnFG8hdJ97WqnPS0buYZlrbTV0nRFL/NI2VABl18vEEXvNQiO+ vM8= Message-ID: <30780e06-bcfc-17c7-a057-e860b7d04937@intel.com> Date: Thu, 13 Dec 2018 15:13:32 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09093FE13982@shsmsx102.ccr.corp.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v3 16/34] net/ice: support device initialization 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: Thu, 13 Dec 2018 15:13:37 -0000 On 12/13/2018 2:39 AM, Lu, Wenzhuo wrote: > Hi Ferruh, > >> -----Original Message----- >> From: Yigit, Ferruh >> Sent: Thursday, December 13, 2018 2:18 AM >> To: Lu, Wenzhuo ; dev@dpdk.org >> Cc: Yang, Qiming ; Li, Xiaoyun >> ; Wu, Jingjing >> Subject: Re: [dpdk-dev] [PATCH v3 16/34] net/ice: support device >> initialization >> >> On 12/12/2018 6:59 AM, Wenzhuo Lu wrote: >>> Signed-off-by: Wenzhuo Lu >>> Signed-off-by: Qiming Yang >>> Signed-off-by: Xiaoyun Li >>> Signed-off-by: Jingjing Wu >> >> <...> >> >>> @@ -297,6 +297,15 @@ >> CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y >>> CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y >>> >>> # >>> +# Compile burst-oriented ICE PMD driver # >> CONFIG_RTE_LIBRTE_ICE_PMD=y >>> +CONFIG_RTE_LIBRTE_ICE_DEBUG_RX=n >> CONFIG_RTE_LIBRTE_ICE_DEBUG_TX=n >>> +CONFIG_RTE_LIBRTE_ICE_DEBUG_TX_FREE=n >>> +CONFIG_RTE_LIBRTE_ICE_RX_ALLOW_BULK_ALLOC=y >> >> Is there a way to convert this into runtime config? Does it needs to be >> compile time config? > If only considering the functionality, we can totally remove this macro. That's why it's set to 'y' by default. > We introduce this macro for the users to improve performance for some specific cases. For example, if the MTU is small enough, we can totally remove the code wrapped by this macro. So the performance is better. Considering the purpose, to achieve the best performance, it's hard to make it a runtime configure. Thanks for clarification. >> >>> + >>> +include $(RTE_SDK)/mk/rte.lib.mk >>> diff --git a/drivers/net/ice/ice_ethdev.c >>> b/drivers/net/ice/ice_ethdev.c new file mode 100644 index >>> 0000000..e0bf15c >>> --- /dev/null >>> +++ b/drivers/net/ice/ice_ethdev.c >>> @@ -0,0 +1,640 @@ >>> +/* SPDX-License-Identifier: BSD-3-Clause >>> + * Copyright(c) 2018 Intel Corporation */ >>> + >>> +#include >>> + >>> +#include "base/ice_sched.h" >>> +#include "ice_ethdev.h" >>> +#include "ice_rxtx.h" >>> + >>> +#define ICE_MAX_QP_NUM "max_queue_pair_num" >> >> When documentation is added into this patch, can you also add this runtime >> config to that please? > The macro? It's not a configuration. It’s a string used internally. It is used as devargs string: + const char *queue_num_key = ICE_MAX_QP_NUM; <...> + if (!rte_kvargs_count(kvlist, queue_num_key)) { + rte_kvargs_free(kvlist); + return 0; + } And briefly what I am suggesting is to document runtime devargs in ice documentation. > >> >> <...> >> >>> +static int >>> +ice_dev_init(struct rte_eth_dev *dev) { >>> + struct rte_pci_device *pci_dev; >>> + struct ice_hw *hw = ICE_DEV_PRIVATE_TO_HW(dev->data- >>> dev_private); >>> + struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data- >>> dev_private); >>> + int ret; >>> + >>> + dev->dev_ops = &ice_eth_dev_ops; >>> + >>> + pci_dev = RTE_DEV_TO_PCI(dev->device); >>> + >>> + rte_eth_copy_pci_info(dev, pci_dev); >> >> This is done by rte_eth_dev_pci_generic_probe(), do we need here? > No, we only need the info, don’t want to probe. Sorry, I didn't get it, let me rephrase: rte_eth_copy_pci_info() called as following with existing code: ice_pci_probe() rte_eth_dev_pci_generic_probe() rte_eth_dev_pci_allocate() <---- (1) rte_eth_copy_pci_info() ice_dev_init() rte_eth_copy_pci_info() <---- (2) I am asking can we remove (2) one, since (1) does the copy already? > >> >> <...> >> >>> +RTE_INIT(ice_init_log); >>> +static void >>> +ice_init_log(void) >> >> Can merge these lines, please check other samples. > Will change it in v4. > >> >>> +{ >>> + ice_logtype_init = rte_log_register("pmd.ice.init"); >> >> pmd.net.ice.init > Will change it in v4. > >> >>> + if (ice_logtype_init >= 0) >>> + rte_log_set_level(ice_logtype_init, RTE_LOG_NOTICE); >>> + ice_logtype_driver = rte_log_register("pmd.ice.driver"); >> >> pmd.net.ice.driver > Will change it in v4. > >> >> <...> >> >>> +static void >>> +ice_dev_close(struct rte_eth_dev *dev) { >>> + struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data- >>> dev_private); >>> + struct ice_hw *hw = ICE_DEV_PRIVATE_TO_HW(dev->data- >>> dev_private); >>> + >>> + ice_res_pool_destroy(&pf->msix_pool); >>> + ice_release_vsi(pf->main_vsi); >>> + >>> + ice_shutdown_all_ctrlq(hw); >>> +} >> >> I am mostly for ordering functions in a way that it doesn't require the >> forward declaration, which is mostly helps reading the code since the >> function order is close the call order. > I just want to align the order with ice_eth_dev_ops. But anyway I can move it forward. I think it make sense to align the order with ice_eth_dev_ops, again improves readability, and both can be done at same time: static dev_ops1() {} static dev_ops2() {} static dev_ops3() {} static const struct eth_dev_ops ice_eth_dev_ops = { ops1 = dev_ops1, ops2 = dev_ops2, ops3 = dev_ops3, }; ice_dev_init() { dev->dev_ops = &ice_eth_dev_ops; } ice_pci_probe() { rte_eth_dev_pci_generic_probe(..., ice_dev_init); } rte_pci_driver rte_ice_pmd = { .probe = ice_pci_probe, .remove = ice_pci_remove, }; RTE_PMD_REGISTER_PCI(net_ice, rte_ice_pmd); > >> >> It is up to you but also for sake of consistancy I think better to move this >> function up, and leave probe/remove/init_log functions as last functions in >> file. > So, it's a bad try to show the strong connection of probe/remove with dev_init/uninit :) No it is good to show that relation and keep them close, sorry perhaps I missed your point but I wasn't suggesting to separate probe/remove & dev_init/uninit. It looks me better to keep file entry/exit points at the bottom and develop through upwards as call-stack moves deeper, instead of functions jump within the file against call-stack. This improves readability because you only scroll one way as you advance through code also you expose to code from more abstract to detailed order. That order also has benefit of removing forward declarations. I am aware it is already complex to develop a new PMD and you are already dealing with lots of hardware details, I have no intention to make it more complex for you, please take this only as an input.