+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 <tho...@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.
