From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id AEEAAA0567; Wed, 10 Mar 2021 17:29:13 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6691F40F35; Wed, 10 Mar 2021 17:29:12 +0100 (CET) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 2D2164069F for ; Wed, 10 Mar 2021 17:29:10 +0100 (CET) IronPort-SDR: v6dCACHWCjuN4Cf77MIfQHl2GAX+fHSGqLEos4frD+ChVdgCW7PcZC3rK1Zw4bS/FaxXbt/K2l S9uDs9KfGGzw== X-IronPort-AV: E=McAfee;i="6000,8403,9919"; a="252522219" X-IronPort-AV: E=Sophos;i="5.81,237,1610438400"; d="scan'208";a="252522219" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Mar 2021 08:29:07 -0800 IronPort-SDR: 8ZR9lTQtcjJ8ySTTVCoRAGyU1B6wG9w+q2k4xxZja09BW1XQbfdSFXxqr/vP9cevjQraQpo1gi NVe/shMdyBzg== X-IronPort-AV: E=Sophos;i="5.81,237,1610438400"; d="scan'208";a="509724467" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.226.209]) ([10.213.226.209]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Mar 2021 08:29:06 -0800 To: Ed Czeck Cc: dev@dpdk.org, Shepard Siegel , John Miller References: <20210304165637.24658-1-ed.czeck@atomicrules.com> <20210309160818.3553-1-ed.czeck@atomicrules.com> <20210309160818.3553-4-ed.czeck@atomicrules.com> <415aa498-d3bd-ca76-77d1-c98816a6f34c@intel.com> From: Ferruh Yigit X-User: ferruhy Message-ID: Date: Wed, 10 Mar 2021 16:29:02 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v4 4/6] net/ark: cleanup ark dynamic extension interface X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 3/10/2021 3:11 PM, Ed Czeck wrote: > On Tue, Mar 9, 2021 at 12:50 PM Ferruh Yigit wrote: >> >> On 3/9/2021 4:08 PM, Ed Czeck wrote: >>> - Rename extension functions with rte_pmd_ark prefix >>> - Move extension prototype to rte_pmd_ark.h >>> - Update local function documentation >>> >>> Signed-off-by: Ed Czeck >>> --- >>> v3: >>> - split function rename from previous commit >>> v4: >>> - reorder patches renaming before adding >> >> <...> >> >>> diff --git a/drivers/net/ark/rte_pmd_ark.h b/drivers/net/ark/rte_pmd_ark.h >>> index 6f26d66b1..0f24a347d 100644 >>> --- a/drivers/net/ark/rte_pmd_ark.h >>> +++ b/drivers/net/ark/rte_pmd_ark.h >>> @@ -1,18 +1,24 @@ >>> /* SPDX-License-Identifier: BSD-3-Clause >>> - * Copyright (c) 2020 Atomic Rules LLC >>> + * Copyright (c) 2020-2021 Atomic Rules LLC >>> */ >>> >>> #ifndef RTE_PMD_ARK_H >>> #define RTE_PMD_ARK_H >>> >>> +#include >>> +#include >>> + >>> +#include >>> +struct rte_eth_dev; >>> +struct rte_mbuf; >>> +struct rte_ether_addr; >>> +struct rte_eth_stats; >>> + >> >> Is the declaring structures instead of including header preferred intentionally? >> >> I guess both works, and it may not differ for the PMD at all, but for the >> extension developer that is including this header, it may need to include >> required headers again, this header including all required headers and be a self >> contained may help extension code, up to you. > > My experience/style has been to use a declaration rather than a full include to > avoid include bloat and speed up compiles. If the extension developer needs > the declaration in the header, they can include it as needed. > OK. >> >> Plus just a detail but I guess mbuf struct is redundant for this patch, it can >> be added in next patch where mbufs header removed and hooks added. > > Agreed. Would you like another patch? > > Thanks > Ed. >