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 B7722A0350; Tue, 30 Jun 2020 14:15:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E84D71BE95; Tue, 30 Jun 2020 14:15:06 +0200 (CEST) Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) by dpdk.org (Postfix) with ESMTP id 50F041B9BF for ; Tue, 30 Jun 2020 14:15:05 +0200 (CEST) Received: by mail-il1-f196.google.com with SMTP id i18so17466243ilk.10 for ; Tue, 30 Jun 2020 05:15:05 -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=r+359+z7EU4lXYCuvaSzyo93BvCzS/uWOm0yYvnFDEc=; b=q5NU1awFJUaSk2w7sqMkVnCgV2HK9yqyx8a/vcNuLe/xjym/H6dJWQaQPBVfxKuQxt dJxk63MgmqJYfJdIp05nA5yNfMh7g8kNQxvpE2+X/lllvRUwYtYd+fEft1YpL+ByW5c/ vb33LlyPwIMM5rEIb9hc+SY9Fsi/HzxWITIBnJUdw5nJ17bGAAk7++TYJcsrucCF0CIi u0VdGsKZYapdrj2M1oFc8H0IhaRqVrFb6YKPFbQouVsZYgkLLYRbvD2KcQQJFm9SXQ0S jPVuVbR6119uebzl/HuAUEgMOm4HWpRP9OcYWqngbxG0fR8kZluU+ezh+l+QCMxQHP5Q RuXA== 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=r+359+z7EU4lXYCuvaSzyo93BvCzS/uWOm0yYvnFDEc=; b=tnmPTpFCpot1OHvs6qS5iTD6DpVDiqig29tW64EbDd2dor5mTQn59V1mCPJoO8CEP2 Vb5vnt0C5hGH7Pe4qD+x3Oz8AhdArrLtc+Q5TKkawVfymqqLn3I8Y6mtxTr+Z7o+rG7L UX6Vpqx38PnELcyzR5pXLhyS+EwfQ1nu0OCOxPrEz7ePlIpZ50YEviT/opKy6VmSbSgI hJyUFoHSFnq1ldyv4zPnnMGuajbx/WTQuzJbp5V6S3oRReAuit7gbWVawgByZP8SDEuK vIROdiOARL8gA+hK3i/loDzQxLgUoWTtsh34yYwttnGNXvfDYo60qCUCCsfA55gHChtQ iDww== X-Gm-Message-State: AOAM533ZMbuxc9CpVo25RxZ6My38ELfyJutgPBNjCEvPfwLWyufU1WSs wFXtLh6WZYqeJQMdJR++7k63QsqRHUa9gYMUKNo= X-Google-Smtp-Source: ABdhPJxKJv7i0F3DvF3LJzH7w5MKEMyv08881tyqkKE+FTkMnBFK8MvxHv47bWrDhr0b/dVTdvS6fYbgeR0ErZl7WqE= X-Received: by 2002:a92:2d4:: with SMTP id 203mr2156933ilc.60.1593519304486; Tue, 30 Jun 2020 05:15:04 -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:44:48 +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 5:06 PM Kinsella, Ray wrote: > > > > On 30/06/2020 12:30, Jerin Jacob wrote: > > 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. > > 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? > 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. > >>>