Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD-tuned Tx/Rx parameters

[Remy Horton <remy.horton@intel.com>]

On 16/03/2018 13:54, Shreyansh Jain wrote:
> On Thu, Mar 15, 2018 at 8:27 PM, Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>> On 3/15/2018 2:39 PM, Bruce Richardson wrote:
>>> On Thu, Mar 15, 2018 at 01:57:13PM +0000, Ferruh Yigit wrote:
[..]
>> Hi Remy, Shreyansh,
>>
>> What do you think about using a variable name consistent with existing
>> "default_[rt]xconf" in dev_info?
>
> It just turned out to be much more complex than I initially thought :)
> Is this what the above conversation merging at (for Rx, as example):
>
> 1. 'default_rx_size_conf' is added in rte_eth_dev_info (and this
> includes I/O  params like burst size, besides configure time nb_queue,
> nb_desc etc). Driver would return these values filled in when
> info_get() is called.

At the moment thinking of the names below, based in what I've read so far..

struct rte_eth_dev_preferred_size {
	uint16_t rx_burst;
	uint16_t tx_burst;
	uint16_t rx_ring;
	uint16_t tx_ring;
	uint16_t rx_nb_queues;
	uint16_t tx_nb_queues;
};
struct rte_eth_dev_info {
	/* ... */
	struct rte_eth_dev_preferred_size preferred_size;
};

Since Rx and Tx use the same parameters, a possible alternative is 
below, although such separation of Rx & Tx was not something I was 
planning on doing:

struct rte_eth_dev_preferred_size {
	uint16_t burst;
	uint16_t ring;
	uint16_t nb_queues;
};
struct rte_eth_dev_info {
	/* ... */
	struct rte_eth_dev_preferred_size preferred_rx;
	struct rte_eth_dev_preferred_size preferred_tx;
};


> 2a. If an application needs the defaults, it would perform info_get()
> and get the values. then, use the values in configuration APIs
> (rx_queue_setup for nb_rx_desc, eth_dev_dev_configure for
> nb_rx_queues).
> For rx_burst calls, it would use the burst_size fields obtained from info_get().
> This is good enough for configuration and datapath (rx_burst).

There was also the suggestion of adding a completely new API function 
rather than using info_get() although there might be some resistance as 
struct eth_dev_ops is already pretty large.


> OR, another case
>
> 2b. Application wants to use default vaules provided by driver without
> calling info_get. In which case, it would call
> rx_queue_setup(nb_rx_desc=0..) or eth_dev_configure(nb_rx_queue=0,
> nb_tx_queue=0). The implementation would query the value from
> 'default_rx_size_conf' through info_get() and use those values.
> Though, in this case, rte_eth_rx_burst(burst=0) might not work for
> picking up the default within rte_ethdev.h.

Since rte_eth_*_burst() are fast-path functions, they are places I would 
prefer not to put conditionals.


> :Four observations:
> A). For burst size (or any other I/O time value added in future),
> values would have to be explicitly used by application - always. If
> value reported by info_get() is '0' (see (B) below), application to
> use its own judgement. No default override by lib_eal.
> IMO, This is good enough assumption.
>
> B). '0' as an indicator for 'no-default-value-available-from-driver'
> is still an open point. It is good enough for current proposed
> parameters, but may be a valid numerical value in future.
> IMO, this can be ignored for now.
>
> C) Unlike the original proposal, this would add two separate members
> to rte_eth_dev_info - one each for Rx and Tx. They both are still
> expected to be populated through the info_get() implementation but not
> by lib_eal.
> IMO, doesn't matter.

There's been quite a bit of discussion whether ethdev should provide 
fall-back values if the PMD doesn't. In this case applications can 
assume the value is always valid and it makes the 0-as-indicator issue 
disappear, but it comes with its own set of issues.


> D) Would there be no non-Rx and non-Tx defaults which need to be shared?
> I am not sure about this, though.

I can't think of any off-hand.

>
> Sorry if I am repeating everything again, but I got lost in the
> conversation and needed to break it again.
>