Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information

[Ray Kinsella <mdr@ashroe.eu>]

+1

On 29/10/2019 16:59, Ferruh Yigit wrote:
> On 10/26/2019 7:58 AM, Jerin Jacob wrote:
>> On Sat, Oct 26, 2019 at 3:57 AM Thomas Monjalon <thomas@monjalon.net> wrote:
>>>
>>> 25/10/2019 18:02, Jerin Jacob:
[SNIP]
> 
> I agree it will be hard or restrictive if we want to represent the all data path
> options with standardized data.
> 
> But the free text string is good for logging, but not good if the application
> will get this input and give some decision with it.

Logging is probably enough for now.
In an ideal world - the PMD's would be self-describing in a machine readable 
standardized way. Similar to a GStreamer caps filter for example, that doesn't 
preclude using strings, it just means everyone needs to agree what the strings are. 

> 
> To combine both two, what do you think a mixed approach, similar to what Jerin
> described but both options and string is visible to application,
> and make 'options' only for vectorization information which is limited and be
> standardized:
> 
> int rte_eth_tx_burst_mode_get(uint16_t port_id, uint16_t queue_id,
> 	struct rte_eth_burst_mode *mode);
> 
> struct rte_eth_burst_mode {
> 	uint64_t options; // This is only for VECTORIZATION mode
> 	char *alternate_options;
> }
> 
> since "burst_mode:options" only for vectorization, it is limited and can be easy
> to consume by applications.
> This means removing some data path options, like "BULK_ALLOC" from current struct.

Makes sense, the bit fields are pretty easy to determine also. 

> 
> 'rte_eth_burst_mode_option_name()' can get "struct rte_eth_burst_mode" as
> parameter and convert the 'options' to string and combine into single string as
> a helper function to the applications.
+1

> 
> And +1 to providing NULL "alternate_options" can return the size of that string.
+1

> 
> And as we find more common/standard data path options, we can move them to the
> bitfield and remove from the free text. Does it make sense?
+1 

It would allow the standardization of options to be an evolutionary process - very good idea.