>-----Original Message-----
>From: Kinsella, Ray <m...@ashroe.eu>
>Sent: Thursday, July 2, 2020 10:21 AM
>To: Jerin Jacob <jerinjac...@gmail.com>
>Cc: McDaniel, Timothy <timothy.mcdan...@intel.com>; Neil Horman
><nhor...@tuxdriver.com>; Jerin Jacob <jer...@marvell.com>; Mattias
>Rönnblom <mattias.ronnb...@ericsson.com>; dpdk-dev <dev@dpdk.org>; Eads,
>Gage <gage.e...@intel.com>; Van Haaren, Harry <harry.van.haa...@intel.com>
>Subject: Re: [dpdk-dev] [PATCH 01/27] eventdev: dlb upstream prerequisites
>
>
>
>On 30/06/2020 13:14, Jerin Jacob wrote:
>> On Tue, Jun 30, 2020 at 5:06 PM Kinsella, Ray <m...@ashroe.eu> wrote:
>>>
>>>
>>>
>>> On 30/06/2020 12:30, Jerin Jacob wrote:
>>>> On Tue, Jun 30, 2020 at 4:52 PM Kinsella, Ray <m...@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.
>>
>> Yes, With respect to that function.
>> But the application can use struct rte_event_port_conf in their code
>> and it can be part of other structures.
>> Right?
>
>Tim, it looks like you might be inadvertently breaking other symbols also.
>For example ...
>
>int
>rte_event_crypto_adapter_create(uint8_t id, uint8_t dev_id,
> struct rte_event_port_conf *port_config,
> enum rte_event_crypto_adapter_mode mode);
>
>int
>rte_event_port_setup(uint8_t dev_id, uint8_t port_id,
> const struct rte_event_port_conf *port_conf);
>
>These and others symbols are also using rte_event_port_conf and would need to
>be updated to use the v20 struct,
>if we aren't to break them .
>
Yes, we just discovered that after successfully running the ABI checker. I will
address those in the v3
patch set. Thanks.
>>
>>
>>> 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.
>>>>>>
