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 <zhiyong.y...@intel.com>
> > Cc: Yao, Lei A <lei.a....@intel.com>; dev@dpdk.org; tho...@monjalon.net;
> > Yigit, Ferruh <ferruh.yi...@intel.com>; Wiles, Keith
> > <keith.wi...@intel.com>;
> > step...@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
