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 B8910A0520; Thu, 2 Jul 2020 17:21:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B4F671D913; Thu, 2 Jul 2020 17:21:08 +0200 (CEST) Received: from qrelay95.mxroute.com (qrelay95.mxroute.com [172.82.139.95]) by dpdk.org (Postfix) with ESMTP id 172011D736 for ; Thu, 2 Jul 2020 17:21:06 +0200 (CEST) Received: from filter004.mxroute.com ([149.28.56.236] 149.28.56.236.vultr.com) (Authenticated sender: mN4UYu2MZsgR) by qrelay95.mxroute.com (ZoneMTA) with ESMTPA id 173101df84a00027dd.001 for ; Thu, 02 Jul 2020 15:21:06 +0000 X-Zone-Loop: d1abf6f93733dbf7f1b97e72f22760fa0a59126cf250 X-Originating-IP: [149.28.56.236] Received: from echo.mxrouting.net (echo.mxrouting.net [116.202.222.109]) by filter004.mxroute.com (Postfix) with ESMTPS id 9B9273EADC; Thu, 2 Jul 2020 15:21:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ashroe.eu; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=PQ6+cBrc5t43yRogn5imdcqnFpwWgB0ONiKSEg1e2lc=; b=EDPgToaVPe08iPcPag8qxDP856 gFnFaYc+SSIEHmuUw9kipWQuN7N7krTOR/h9UkcQhMyu5G78O0/sEdiAVDb3ZdJIIbi4c6/Ahy3p7 uhR7jyE59JTTzQsktf9oLRhEpHyN5Tp9W+fgdu7CZShEQbxy2S6TMaCkeppDpaIij2A1nSgyt/izy /sVaG6D2QjF2EZpPWuahGOwpDpHRgGWiwHUkOtd/BU+X94+ktHcYIlxhvmPAUxLGqAlYBrqZQuoX4 EDCf6Bvx1ZY4MZJa37X9pmd3tYgMQzQwf+gqr6eoNkL5MlFg5LfEwDaNwGNrTV5I6rlBJ7LNUi+0D mxDpDyIw==; To: Jerin Jacob Cc: Tim McDaniel , Neil Horman , Jerin Jacob , =?UTF-8?Q?Mattias_R=c3=b6nnblom?= , dpdk-dev , Gage Eads , "Van Haaren, Harry" References: <1593232671-5690-1-git-send-email-timothy.mcdaniel@intel.com> <1593232671-5690-2-git-send-email-timothy.mcdaniel@intel.com> From: "Kinsella, Ray" Autocrypt: addr=mdr@ashroe.eu; keydata= mQINBFv8B3wBEAC+5ImcgbIvadt3axrTnt7Sxch3FsmWTTomXfB8YiuHT8KL8L/bFRQSL1f6 ASCHu3M89EjYazlY+vJUWLr0BhK5t/YI7bQzrOuYrl9K94vlLwzD19s/zB/g5YGGR5plJr0s JtJsFGEvF9LL3e+FKMRXveQxBB8A51nAHfwG0WSyx53d61DYz7lp4/Y4RagxaJoHp9lakn8j HV2N6rrnF+qt5ukj5SbbKWSzGg5HQF2t0QQ5tzWhCAKTfcPlnP0GymTBfNMGOReWivi3Qqzr S51Xo7hoGujUgNAM41sxpxmhx8xSwcQ5WzmxgAhJ/StNV9cb3HWIoE5StCwQ4uXOLplZNGnS uxNdegvKB95NHZjRVRChg/uMTGpg9PqYbTIFoPXjuk27sxZLRJRrueg4tLbb3HM39CJwSB++ YICcqf2N+GVD48STfcIlpp12/HI+EcDSThzfWFhaHDC0hyirHxJyHXjnZ8bUexI/5zATn/ux TpMbc/vicJxeN+qfaVqPkCbkS71cHKuPluM3jE8aNCIBNQY1/j87k5ELzg3qaesLo2n1krBH bKvFfAmQuUuJT84/IqfdVtrSCTabvDuNBDpYBV0dGbTwaRfE7i+LiJJclUr8lOvHUpJ4Y6a5 0cxEPxm498G12Z3NoY/mP5soItPIPtLR0rA0fage44zSPwp6cQARAQABtBxSYXkgS2luc2Vs bGEgPG1kckBhc2hyb2UuZXU+iQJUBBMBCAA+FiEEcDUDlKDJaDuJlfZfdJdaH/sCCpsFAlv8 B3wCGyMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQdJdaH/sCCptdtRAAl0oE msa+djBVYLIsax+0f8acidtWg2l9f7kc2hEjp9h9aZCpPchQvhhemtew/nKavik3RSnLTAyn B3C/0GNlmvI1l5PFROOgPZwz4xhJKGN7jOsRrbkJa23a8ly5UXwF3Vqnlny7D3z+7cu1qq/f VRK8qFyWkAb+xgqeZ/hTcbJUWtW+l5Zb+68WGEp8hB7TuJLEWb4+VKgHTpQ4vElYj8H3Z94a 04s2PJMbLIZSgmKDASnyrKY0CzTpPXx5rSJ1q+B1FCsfepHLqt3vKSALa3ld6bJ8fSJtDUJ7 JLiU8dFZrywgDIVme01jPbjJtUScW6jONLvhI8Z2sheR71UoKqGomMHNQpZ03ViVWBEALzEt TcjWgJFn8yAmxqM4nBnZ+hE3LbMo34KCHJD4eg18ojDt3s9VrDLa+V9fNxUHPSib9FD9UX/1 +nGfU/ZABmiTuUDM7WZdXri7HaMpzDRJUKI6b+/uunF8xH/h/MHW16VuMzgI5dkOKKv1LejD dT5mA4R+2zBS+GsM0oa2hUeX9E5WwjaDzXtVDg6kYq8YvEd+m0z3M4e6diFeLS77/sAOgaYL 92UcoKD+Beym/fVuC6/55a0e12ksTmgk5/ZoEdoNQLlVgd2INtvnO+0k5BJcn66ZjKn3GbEC VqFbrnv1GnA58nEInRCTzR1k26h9nmS5Ag0EW/wHfAEQAMth1vHr3fOZkVOPfod3M6DkQir5 xJvUW5EHgYUjYCPIa2qzgIVVuLDqZgSCCinyooG5dUJONVHj3nCbITCpJp4eB3PI84RPfDcC hf/V34N/Gx5mTeoymSZDBmXT8YtvV/uJvn+LvHLO4ZJdvq5ZxmDyxfXFmkm3/lLw0+rrNdK5 pt6OnVlCqEU9tcDBezjUwDtOahyV20XqxtUttN4kQWbDRkhT+HrA9WN9l2HX91yEYC+zmF1S OhBqRoTPLrR6g4sCWgFywqztpvZWhyIicJipnjac7qL/wRS+wrWfsYy6qWLIV80beN7yoa6v ccnuy4pu2uiuhk9/edtlmFE4dNdoRf7843CV9k1yRASTlmPkU59n0TJbw+okTa9fbbQgbIb1 pWsAuicRHyLUIUz4f6kPgdgty2FgTKuPuIzJd1s8s6p2aC1qo+Obm2gnBTduB+/n1Jw+vKpt 07d+CKEKu4CWwvZZ8ktJJLeofi4hMupTYiq+oMzqH+V1k6QgNm0Da489gXllU+3EFC6W1qKj tkvQzg2rYoWeYD1Qn8iXcO4Fpk6wzylclvatBMddVlQ6qrYeTmSbCsk+m2KVrz5vIyja0o5Y yfeN29s9emXnikmNfv/dA5fpi8XCANNnz3zOfA93DOB9DBf0TQ2/OrSPGjB3op7RCfoPBZ7u AjJ9dM7VABEBAAGJAjwEGAEIACYWIQRwNQOUoMloO4mV9l90l1of+wIKmwUCW/wHfAIbDAUJ CWYBgAAKCRB0l1of+wIKm3KlD/9w/LOG5rtgtCUWPl4B3pZvGpNym6XdK8cop9saOnE85zWf u+sKWCrxNgYkYP7aZrYMPwqDvilxhbTsIJl5HhPgpTO1b0i+c0n1Tij3EElj5UCg3q8mEc17 c+5jRrY3oz77g7E3oPftAjaq1ybbXjY4K32o3JHFR6I8wX3m9wJZJe1+Y+UVrrjY65gZFxcA thNVnWKErarVQGjeNgHV4N1uF3pIx3kT1N4GSnxhoz4Bki91kvkbBhUgYfNflGURfZT3wIKK +d50jd7kqRouXUCzTdzmDh7jnYrcEFM4nvyaYu0JjSS5R672d9SK5LVIfWmoUGzqD4AVmUW8 pcv461+PXchuS8+zpltR9zajl72Q3ymlT4BTAQOlCWkD0snBoKNUB5d2EXPNV13nA0qlm4U2 GpROfJMQXjV6fyYRvttKYfM5xYKgRgtP0z5lTAbsjg9WFKq0Fndh7kUlmHjuAIwKIV4Tzo75 QO2zC0/NTaTjmrtiXhP+vkC4pcrOGNsbHuaqvsc/ZZ0siXyYsqbctj/sCd8ka2r94u+c7o4l BGaAm+FtwAfEAkXHu4y5Phuv2IRR+x1wTey1U1RaEPgN8xq0LQ1OitX4t2mQwjdPihZQBCnZ wzOrkbzlJMNrMKJpEgulmxAHmYJKgvZHXZXtLJSejFjR0GdHJcL5rwVOMWB8cg== Message-ID: Date: Thu, 2 Jul 2020 16:21:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-AuthUser: mdr@ashroe.eu 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 30/06/2020 13:14, Jerin Jacob wrote: > 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? 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 . > > >> 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. >>>>>