From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 832FDA0350; Tue, 30 Jun 2020 13:31:11 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3EC351BEC0; Tue, 30 Jun 2020 13:31:11 +0200 (CEST) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by dpdk.org (Postfix) with ESMTP id 8FBD11BEB2 for ; Tue, 30 Jun 2020 13:31:09 +0200 (CEST) Received: by mail-io1-f66.google.com with SMTP id v6so6883688iob.4 for ; Tue, 30 Jun 2020 04:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xBUbZAcvFQO0t5E93DklQM3T1cBra+YgB2K5Gz9xh0k=; b=kTbUou6ivbIY50/Nk1/z9lh6gMIsrh1mmHvKbWd/+ImvYsLiJFKYrzIAbbFEHyWaU3 Q+o7RXX+vxuSukyk9MPqSlFs2PMQYQ6OG510iXRD3iuGtJaQZOG1cam6lKGyO4F3RQnn ybV4DBlD61gw5UavgCUA652fdHX4zG6mYchZEaiFDhIHH/bv51uWpEQ1lfopcRso7nq2 ufqdT/MPJ9QpuyXrCvWSvVgOJ47DFTGU2u73c7K9cF+aQY/EbUZ+7lgbbob5ffzhXuXr ZSwYR2SH++SeR6PcgzaSMqSXV8+aed3nMLyQ+PCOG3MB+1FyiP598h6UmwKNFi2KCqAF MvBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xBUbZAcvFQO0t5E93DklQM3T1cBra+YgB2K5Gz9xh0k=; b=NFrY05yB3YmFRW3524fUEyV+EM3nYo2+pwo6oxzqfmdgVL/aQ5gsfH81SnZ50mZ/ND M5PYlxk/Dt8ppWDb/f9PCSEFWGhXy+3b6nN+sTkoBaKeqbwBk+Vc2gQ7KtN+0oLYIsOy U/DmEG59F7kVs84uqMMrnvzdfjMtqtv0Kkp53/1Tb1nDWZWouUx8UmhfWQb0X6l8ZuyP qkVhImXutcdubgIzHQ2INvIOsEjxoK0+KZW6Da+Pd7cSL7cj4Yn0tsGMNgoQ3slkJIHr G1zIawLwheQFdIuUEifjAi90WdQNuwmuNOxuvzw6qgM2IL5EKOTSS8gaUbWO5faegc1x GzCQ== X-Gm-Message-State: AOAM532TjwP32aCUq98pluwgZc+hd+A0OqBisKwh0I6hS0p/UnjDnNUZ IyCFdgFX1GEZsNYZZST0VwNFub7JZ/+bwHmleh8= X-Google-Smtp-Source: ABdhPJwAOheZtqf6gfNWoX1qM9DyI+3h31yW9d+RyYNZMMVfRTI86pXZauVYVJbBSUO4AV8QpzalAs/hnfThtbNmQl8= X-Received: by 2002:a6b:b344:: with SMTP id c65mr22061137iof.123.1593516668828; Tue, 30 Jun 2020 04:31:08 -0700 (PDT) MIME-Version: 1.0 References: <1593232671-5690-1-git-send-email-timothy.mcdaniel@intel.com> <1593232671-5690-2-git-send-email-timothy.mcdaniel@intel.com> In-Reply-To: From: Jerin Jacob Date: Tue, 30 Jun 2020 17:00:52 +0530 Message-ID: To: "Kinsella, Ray" Cc: Tim McDaniel , Neil Horman , Jerin Jacob , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , dpdk-dev , Gage Eads , "Van Haaren, Harry" Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH 01/27] eventdev: dlb upstream prerequisites X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, Jun 30, 2020 at 4:52 PM Kinsella, Ray 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. > >