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 23CAAA04B6; Mon, 12 Oct 2020 18:03:59 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 79A801D917; Mon, 12 Oct 2020 18:03:56 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by dpdk.org (Postfix) with ESMTP id 2EC871D8FE for ; Mon, 12 Oct 2020 18:03:54 +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 A786C7F513; Mon, 12 Oct 2020 19:03:52 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru A786C7F513 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1602518632; bh=su2QuTcbnH5vu6fw1zGOCkXvAsGXYZOLf+DQ9dN0unw=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=L/g1zzLVHUdYvJldZNvoVUK48Yy/A4wLLkxKfev5o/Qg6SjsneRgZxleuQLai2d7o Ry9L6XgasztvcNMtG+YxVxsJM0TZdBySPlr0IEnhIYdhjDTFj7hLf/eDR9vrEUZHQv sczc2iO4aNgNFN80/Ijx4fUfaYfYMAUZTelakBoo= To: Thomas Monjalon , "ferruh.yigit@intel.com" , Slava Ovsiienko Cc: "dev@dpdk.org" , "stephen@networkplumber.org" , Shahaf Shuler , "olivier.matz@6wind.com" , "jerinjacobk@gmail.com" , "maxime.coquelin@redhat.com" , "david.marchand@redhat.com" , Asaf Penso References: <4d4be3cd-e418-00cf-ce6d-51f6c3e5c078@oktetlabs.ru> <8304375.31BPq7MtOA@thomas> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <4a7e3bb7-1620-c4eb-3dd3-7449f36eb87d@oktetlabs.ru> Date: Mon, 12 Oct 2020 19:03:52 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <8304375.31BPq7MtOA@thomas> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC] ethdev: introduce Rx buffer split 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 10/12/20 6:14 PM, Thomas Monjalon wrote: > 12/10/2020 11:56, Slava Ovsiienko: >> Hi, Andrew >> >> Thank you for the comments. >> >> We have two approaches how to specify multiple segments to split Rx packets: >> 1. update queue configuration structure >> 2. introduce new rx_queue_setup_ex() routine with extra parameters. >> >> For [1] my only actual dislike is that we would have multiple places to specify >> the pool - in rx_queue_setup() and in the config structure. So, we should >> implement some checking (if we have offload flag set we should check >> whether mp parameter is NULL and segment descriptions array pointer/size >> is provided, if no offload flag set - we must check the description array is empty). >> >>> @Thomas, @Ferruh: I'd like to hear what other ethdev maintainers think >>> about it. >> >> Yes, it would be very nice to hear extra opinions. Do we think the providing >> of extra API function is worse than extending existing structure, introducing >> some conditional ambiguity and complicating the parameter compliance >> check? > > Let's try listing pros and cons of each approach, so we can conclude. > > 1/ update queue config struct > > 1.1 pro: keep same queue setup function pro: no code duplication > 1.2 con: two mempool pointers (struct or function) > 1.3 con: variable size of segment description array > > 2/ new queue setup function > > 2.1 con: two functions for queue setup con: code duplication or refactoring of existing stable code > 2.2 pro: mempool pointer is not redundant > 2.3 pro: segment description array size defined by the caller > > What else I'm missing? >