[dpdk-dev] [PATCH 01/27] eventdev: dlb upstream prerequisites

[Kinsella, Ray]

On 30/06/2020 12:30, Jerin Jacob wrote:
> On Tue, Jun 30, 2020 at 4:52 PM Kinsella, Ray <mdr at ashroe.eu> wrote:
>>
>>
>>
>> On 27/06/2020 08:44, Jerin Jacob wrote:
>>>> +
>>>> +/** Event port configuration structure */
>>>> +struct rte_event_port_conf_v20 {
>>>> +       int32_t new_event_threshold;
>>>> +       /**< A backpressure threshold for new event enqueues on this port.
>>>> +        * Use for *closed system* event dev where event capacity is limited,
>>>> +        * and cannot exceed the capacity of the event dev.
>>>> +        * Configuring ports with different thresholds can make higher priority
>>>> +        * traffic less likely to  be backpressured.
>>>> +        * For example, a port used to inject NIC Rx packets into the event dev
>>>> +        * can have a lower threshold so as not to overwhelm the device,
>>>> +        * while ports used for worker pools can have a higher threshold.
>>>> +        * This value cannot exceed the *nb_events_limit*
>>>> +        * which was previously supplied to rte_event_dev_configure().
>>>> +        * This should be set to '-1' for *open system*.
>>>> +        */
>>>> +       uint16_t dequeue_depth;
>>>> +       /**< Configure number of bulk dequeues for this event port.
>>>> +        * This value cannot exceed the *nb_event_port_dequeue_depth*
>>>> +        * which previously supplied to rte_event_dev_configure().
>>>> +        * Ignored when device is not RTE_EVENT_DEV_CAP_BURST_MODE capable.
>>>> +        */
>>>> +       uint16_t enqueue_depth;
>>>> +       /**< Configure number of bulk enqueues for this event port.
>>>> +        * This value cannot exceed the *nb_event_port_enqueue_depth*
>>>> +        * which previously supplied to rte_event_dev_configure().
>>>> +        * Ignored when device is not RTE_EVENT_DEV_CAP_BURST_MODE capable.
>>>> +        */
>>>>         uint8_t disable_implicit_release;
>>>>         /**< Configure the port not to release outstanding events in
>>>>          * rte_event_dev_dequeue_burst(). If true, all events received through
>>>> @@ -733,6 +911,14 @@ struct rte_event_port_conf {
>>>>  rte_event_port_default_conf_get(uint8_t dev_id, uint8_t port_id,
>>>>                                 struct rte_event_port_conf *port_conf);
>>>>
>>>> +int
>>>> +rte_event_port_default_conf_get_v20(uint8_t dev_id, uint8_t port_id,
>>>> +                               struct rte_event_port_conf_v20 *port_conf);
>>>> +
>>>> +int
>>>> +rte_event_port_default_conf_get_v21(uint8_t dev_id, uint8_t port_id,
>>>> +                                     struct rte_event_port_conf *port_conf);
>>>
>>> Hi Timothy,
>>>
>>> + ABI Maintainers (Ray, Neil)
>>>
>>> # As per my understanding, the structures can not be versioned, only
>>> function can be versioned.
>>> i.e we can not make any change to " struct rte_event_port_conf"
>>
>> So the answer is (as always): depends
>>
>> If the structure is being use in inline functions is when you run into trouble
>> - as knowledge of the structure is embedded in the linked application.
>>
>> However if the structure is _strictly_ being used as a non-inlined function parameter,
>> It can be safe to version in this way.
> 
> But based on the optimization applied when building the consumer code
> matters. Right?
> i.e compiler can "inline" it, based on the optimization even the
> source code explicitly mentions it.

Well a compiler will typically only inline within the confines of a given object file, or 
binary, if LTO is enabled. 

If a function symbol is exported from library however, it won't be inlined in a linked application. 
The compiler doesn't have enough information to inline it. 
All the compiler will know about it is it's offset in memory, and it's signature. 

> 
> 
>>
>> So just to be clear, it is still the function that is actually being versioned here.
>>
>>>
>>> # We have a similar case with ethdev and it deferred to next release v20.11
>>> http://patches.dpdk.org/patch/69113/
>>
>> Yes - I spent a why looking at this one, but I am struggling to recall,
>> why when I looked it we didn't suggest function versioning as a potential solution in this case.
>>
>> Looking back at it now, looks like it would have been ok.
> 
> Ok.
> 
>>
>>>
>>> Regarding the API changes:
>>> # The slow path changes general looks good to me. I will review the
>>> next level in the coming days
>>> # The following fast path changes bothers to me. Could you share more
>>> details on below change?
>>>
>>> diff --git a/app/test-eventdev/test_order_atq.c
>>> b/app/test-eventdev/test_order_atq.c
>>> index 3366cfc..8246b96 100644
>>> --- a/app/test-eventdev/test_order_atq.c
>>> +++ b/app/test-eventdev/test_order_atq.c
>>> @@ -34,6 +34,8 @@
>>>                         continue;
>>>                 }
>>>
>>> +               ev.flow_id = ev.mbuf->udata64;
>>> +
>>> # Since RC1 is near, I am not sure how to accommodate the API changes
>>> now and sort out ABI stuffs.
>>> # Other concern is eventdev spec get bloated with versioning files
>>> just for ONE release as 20.11 will be OK to change the ABI.
>>> # While we discuss the API change, Please send deprecation notice for
>>> ABI change for 20.11,
>>> so that there is no ambiguity of this patch for the 20.11 release.
>>>