From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7AA2DA0C41; Thu, 30 Sep 2021 17:07:42 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 010E9410EF; Thu, 30 Sep 2021 17:07:42 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id D956A410EB for ; Thu, 30 Sep 2021 17:07:40 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 381777F508; Thu, 30 Sep 2021 18:07:40 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 381777F508 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1633014460; bh=zXXzDYdJlMEB0hgKa1Un8BEi/WstjRlmJom+4iZEwxs=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=WJ1t3Fc+eJn7KWr+aaSGLLuQy+xvmFBBU6UZ2rDgbYVPiVm59UAHnkU4w6weo3sUh ZobHJU/yRy9ny2oQTiBnWPK8rJOFK7/eaIxRNupWHqqXEZ6knUgMYRcc3h46UzfAqF Ig9JDILjge/iLvzath8CvVJqzXoOdYhhKCet5j2E= To: Ori Kam , Ivan Malov , "dev@dpdk.org" Cc: Andy Moreton , Ray Kinsella , Jerin Jacob , Wisam Monther , Xiaoyun Li , NBU-Contact-Thomas Monjalon , Ferruh Yigit References: <20210902142359.28138-1-ivan.malov@oktetlabs.ru> <20210923112012.14595-1-ivan.malov@oktetlabs.ru> <20210923112012.14595-2-ivan.malov@oktetlabs.ru> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <9418f13b-d01e-b688-0fea-567ef161f5f1@oktetlabs.ru> Date: Thu, 30 Sep 2021 18:07:40 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v3 1/5] ethdev: add API to negotiate delivery of Rx meta data X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" Hi Ori, On 9/30/21 5:59 PM, Ori Kam wrote: > Hi Ivan, > Sorry for jumping in late. > > I have a concern that this patch breaks other PMDs. >>>From the rst file " One should negotiate flag delivery beforehand" > since you only added this function for your PMD all other PMD will fail. > I see that you added exception in the examples, but it doesn't make sense > that applications will also need to add this exception which is not documented. It is a new API and the function description lists possible return codes. An application can handle these return codes gracefully. I'm not sure that it makes sense to highlight it as a special case. > > Please see more comments inline. See below > Thanks, > Ori > >> -----Original Message----- >> From: Ivan Malov >> Sent: Thursday, September 23, 2021 2:20 PM >> Subject: [PATCH v3 1/5] ethdev: add API to negotiate delivery of Rx meta >> data >> >> Delivery of mark, flag and the likes might affect small packet performance. >> If these features are disabled by default, enabling them in started state >> without causing traffic disruption may not always be possible. >> >> Let applications negotiate delivery of Rx meta data beforehand. >> >> Signed-off-by: Ivan Malov >> Reviewed-by: Andrew Rybchenko >> Reviewed-by: Andy Moreton >> Acked-by: Ray Kinsella >> Acked-by: Jerin Jacob [snip] >> +__rte_experimental >> +int rte_eth_rx_meta_negotiate(uint16_t port_id, uint64_t *features); > > I don't think meta is the best name since we also have meta item and the word meta can be used > in other cases. Do you have any idea what could be used instead of it? Thanks, Andrew.