DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob <jerinjacobk@gmail.com>
To: "Kinsella, Ray" <mdr@ashroe.eu>
Cc: "Tim McDaniel" <timothy.mcdaniel@intel.com>,
	"Neil Horman" <nhorman@tuxdriver.com>,
	"Jerin Jacob" <jerinj@marvell.com>,
	"Mattias Rönnblom" <mattias.ronnblom@ericsson.com>,
	dpdk-dev <dev@dpdk.org>, "Gage Eads" <gage.eads@intel.com>,
	"Van Haaren, Harry" <harry.van.haaren@intel.com>
Subject: Re: [dpdk-dev] [PATCH 01/27] eventdev: dlb upstream prerequisites
Date: Tue, 30 Jun 2020 17:00:52 +0530	[thread overview]
Message-ID: <CALBAE1MLjciPWis-P2eAc1s6Vp7tf+wOx+K359WgZS4nAGs9GQ@mail.gmail.com> (raw)
In-Reply-To: <ef5de523-b205-746e-3bbe-346e028a3f7b@ashroe.eu>

On Tue, Jun 30, 2020 at 4:52 PM Kinsella, Ray <mdr@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.


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

  reply	other threads:[~2020-06-30 11:31 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-27  4:37 [dpdk-dev] [PATCH 00/27] event/dlb Intel DLB PMD Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 01/27] eventdev: dlb upstream prerequisites Tim McDaniel
2020-06-27  7:44   ` Jerin Jacob
2020-06-29 19:30     ` McDaniel, Timothy
2020-06-30  4:21       ` Jerin Jacob
2020-06-30 15:37         ` McDaniel, Timothy
2020-06-30 15:57           ` Jerin Jacob
2020-06-30 19:26             ` McDaniel, Timothy
2020-06-30 20:40               ` Pavan Nikhilesh Bhagavatula
2020-06-30 21:07                 ` McDaniel, Timothy
2020-07-01  4:50               ` Jerin Jacob
2020-07-01 16:48                 ` McDaniel, Timothy
2020-06-30 11:22     ` Kinsella, Ray
2020-06-30 11:30       ` Jerin Jacob [this message]
2020-06-30 11:36         ` Kinsella, Ray
2020-06-30 12:14           ` Jerin Jacob
2020-07-02 15:21             ` Kinsella, Ray
2020-07-02 16:35               ` McDaniel, Timothy
2020-06-27  4:37 ` [dpdk-dev] [PATCH 02/27] eventdev: do not pass disable_implicit_release bit to trace macro Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 03/27] event/dlb: add shared code version 10.7.9 Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 04/27] event/dlb: add make and meson build infrastructure Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 05/27] event/dlb: add DLB documentation Tim McDaniel
2020-07-09  3:29   ` Eads, Gage
2020-06-27  4:37 ` [dpdk-dev] [PATCH 06/27] event/dlb: add dynamic logging Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 07/27] event/dlb: add private data structures and constants Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 08/27] event/dlb: add definitions shared with LKM or shared code Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 09/27] event/dlb: add inline functions used in multiple files Tim McDaniel
2020-07-07 12:02   ` Bruce Richardson
2020-07-07 14:33     ` McDaniel, Timothy
2020-06-27  4:37 ` [dpdk-dev] [PATCH 10/27] event/dlb: add PFPMD-specific interface layer to shared code Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 11/27] event/dlb: add flexible PMD to device interfaces Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 12/27] event/dlb: add the PMD's public interfaces Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 13/27] event/dlb: add xstats support Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 14/27] event/dlb: add PMD self-tests Tim McDaniel
2020-07-10 20:42   ` Eads, Gage
2020-07-29 18:56     ` McDaniel, Timothy
2020-06-27  4:37 ` [dpdk-dev] [PATCH 15/27] event/dlb: add probe Tim McDaniel
2020-07-09  3:45   ` Eads, Gage
2020-06-27  4:37 ` [dpdk-dev] [PATCH 16/27] event/dlb: add infos_get and configure Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 17/27] event/dlb: add queue_def_conf and port_def_conf Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 18/27] event/dlb: add queue setup Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 19/27] event/dlb: add port_setup Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 20/27] event/dlb: add port_link Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 21/27] event/dlb: add queue_release and port_release Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 22/27] event/dlb: add port_unlink and port_unlinks_in_progress Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 23/27] event/dlb: add eventdev_start Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 24/27] event/dlb: add timeout_ticks, dump, xstats, and selftest Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 25/27] event/dlb: add enqueue and its burst variants Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 26/27] event/dlb: add dequeue, dequeue_burst, and variants Tim McDaniel
2020-06-27  4:37 ` [dpdk-dev] [PATCH 27/27] event/dlb: add eventdev_stop and eventdev_close Tim McDaniel
     [not found] <1593232671-5690-0-git-send-email-timothy.mcdaniel@intel.com>
2020-07-30 19:49 ` [dpdk-dev] [PATCH 00/27] Add Intel DLM PMD to 20.11 McDaniel, Timothy
2020-07-30 19:49   ` [dpdk-dev] [PATCH 01/27] eventdev: dlb upstream prerequisites McDaniel, Timothy
2020-08-11 17:44     ` Jerin Jacob
  -- strict thread matches above, loose matches on Subject: below --
2020-06-12 21:24 [dpdk-dev] [PATCH 00/27] V1 event/dlb add Intel DLB PMD McDaniel, Timothy
2020-06-12 21:24 ` [dpdk-dev] [PATCH 01/27] eventdev: dlb upstream prerequisites McDaniel, Timothy
2020-06-13  3:59   ` Jerin Jacob
2020-06-13 10:43     ` Mattias Rönnblom
2020-06-18 15:51       ` McDaniel, Timothy
2020-06-18 15:44     ` McDaniel, Timothy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALBAE1MLjciPWis-P2eAc1s6Vp7tf+wOx+K359WgZS4nAGs9GQ@mail.gmail.com \
    --to=jerinjacobk@gmail.com \
    --cc=dev@dpdk.org \
    --cc=gage.eads@intel.com \
    --cc=harry.van.haaren@intel.com \
    --cc=jerinj@marvell.com \
    --cc=mattias.ronnblom@ericsson.com \
    --cc=mdr@ashroe.eu \
    --cc=nhorman@tuxdriver.com \
    --cc=timothy.mcdaniel@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).