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.
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.
>
> 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.
>
