From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id B863F5A6E for ; Mon, 4 Sep 2017 12:29:49 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Sep 2017 03:29:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,474,1498546800"; d="scan'208";a="1214449817" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.24]) by fmsmga002.fm.intel.com with SMTP; 04 Sep 2017 03:29:46 -0700 Received: by (sSMTP sendmail emulation); Mon, 04 Sep 2017 11:29:45 +0100 Date: Mon, 4 Sep 2017 11:29:45 +0100 From: Bruce Richardson To: "Yang, Zhiyong" Cc: "Yao, Lei A" , "dev@dpdk.org" , "thomas@monjalon.net" , "Yigit, Ferruh" , "Wiles, Keith" , "stephen@networkplumber.org" Message-ID: <20170904102945.GB16984@bricha3-MOBL3.ger.corp.intel.com> References: <20170809084203.17562-1-zhiyong.yang@intel.com> <20170904055734.21354-1-zhiyong.yang@intel.com> <20170904055734.21354-4-zhiyong.yang@intel.com> <2DBBFF226F7CF64BAFCA79B681719D953A266703@shsmsx102.ccr.corp.intel.com> <20170904090903.GB17464@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.8.3 (2017-05-23) Subject: Re: [dpdk-dev] [PATCH v2 3/4] common_base: extend RTE_MAX_ETHPORTS from 32 to 1024 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: Mon, 04 Sep 2017 10:29:50 -0000 On Mon, Sep 04, 2017 at 11:05:11AM +0100, Yang, Zhiyong wrote: > Hi, Bruce: > > > -----Original Message----- > > From: Richardson, Bruce > > Sent: Monday, September 4, 2017 5:09 PM > > To: Yang, Zhiyong > > Cc: Yao, Lei A ; dev@dpdk.org; thomas@monjalon.net; > > Yigit, Ferruh ; Wiles, Keith ; > > stephen@networkplumber.org > > Subject: Re: [dpdk-dev] [PATCH v2 3/4] common_base: extend > > RTE_MAX_ETHPORTS from 32 to 1024 > > > > > --- a/config/common_base > > > > > +++ b/config/common_base > > > > > @@ -131,7 +131,7 @@ CONFIG_RTE_LIBRTE_KVARGS=y # > > > > > CONFIG_RTE_LIBRTE_ETHER=y CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n > > > > > -CONFIG_RTE_MAX_ETHPORTS=32 > > > > > +CONFIG_RTE_MAX_ETHPORTS=1024 > > > > > CONFIG_RTE_MAX_QUEUES_PER_PORT=1024 > > > > > CONFIG_RTE_LIBRTE_IEEE1588=n > > > > > CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16 > > > > > -- > > > > > 2.13.3 > > > > Hi, Zhiyong > > > > > > > > I met one issue for changing CONFIG_RTE_MAX_ETHPORTS to 1024. > > > > One process can only open 1024 file as maximum in common linux > > > > distribution, after practice, only 1009 socket file can be used for > > > > vdev device with testpmd sample. > > > > > > Thanks for your info. It seems that 1024 is too large and may bring some > > potential issues. > > > > > > Thanks > > > Zhiyong > > > > > > > It should be possible to have a dynamically allocated ethdev array, which would > > allow use to have a default value - which could be e.g. 32 or 64 as now - while > > also allowing a run-time parameter to increase that to thousands if needed. > > > > /Bruce > > In testpmd, the following function will be called to validate the port_id. > So, It is necessary to modify the max port num RTE_MAX_ETHPORTS. > > I think that RTE_MAX_ETHPORTS and a default value(num of port ) should be different values. > Now dpdk limits the max num to RTE_MAX_ETHPORTS = 32 by default. > int > rte_eth_dev_is_valid_port(uint16_t port_id) > { > if (port_id >= RTE_MAX_ETHPORTS || > (rte_eth_devices[port_id].state != RTE_ETH_DEV_ATTACHED && > rte_eth_devices[port_id].state != RTE_ETH_DEV_DEFERRED)) > return 0; > else > return 1; > } > If we have a dynamically allocated array size, the port_id can still be bounds-checks. It's just the check comes from a variable rather than a compile-time constant. It should not be any slower in practice. As for an absolute max value, I won't object to having one, but I don't see it as needed. If we don't use one, we have one automatically at 64k, i.e. UINT_16_MAX. I fail to see the need to limit it to lower than that - if a user wants that many ports, let them have them. /Bruce