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 2F5D9A04DB; Thu, 15 Oct 2020 11:50:19 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3D82D1DDA1; Thu, 15 Oct 2020 11:49:22 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by dpdk.org (Postfix) with ESMTP id C7E801DDA1 for ; Thu, 15 Oct 2020 11:49:20 +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 626017F537; Thu, 15 Oct 2020 12:49:19 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 626017F537 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1602755359; bh=kWvGwsvmLveD/hy0tiKG4rQDJFHJpFfy92k2JW1YEBw=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=UUS1TJT2oiMPDtM9st/S2mhgQkXwBzKjkDqYQ6riYBRof2IfxNNqB7yoXr2GhpUmy LXkmxC9NecKG3CKdX5NZB14O4LDzg0c3w/avWVxbCRPuekOZ/q6K3/X6B5b/m19snB 6T2z37nzLm+CzV5AOI4Aq+Ra9QSpuHECnYRL+biY= To: Slava Ovsiienko , Jerin Jacob Cc: dpdk-dev , NBU-Contact-Thomas Monjalon , Stephen Hemminger , Ferruh Yigit , Olivier Matz , Maxime Coquelin , David Marchand , Andrew Rybchenko References: <1602699122-15737-1-git-send-email-viacheslavo@nvidia.com> <1602699122-15737-2-git-send-email-viacheslavo@nvidia.com> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <663a2ea8-cb32-9960-75d1-2a4854dcc0ff@oktetlabs.ru> Date: Thu, 15 Oct 2020 12:49:19 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v6 1/6] 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/15/20 10:43 AM, Slava Ovsiienko wrote: > Hi, Jerin > >> -----Original Message----- >> From: Jerin Jacob >> Sent: Wednesday, October 14, 2020 21:57 >> To: Slava Ovsiienko >> Cc: dpdk-dev ; NBU-Contact-Thomas Monjalon >> ; Stephen Hemminger >> ; Ferruh Yigit ; >> Olivier Matz ; Maxime Coquelin >> ; David Marchand >> ; Andrew Rybchenko >> >> Subject: Re: [PATCH v6 1/6] ethdev: introduce Rx buffer split >> >> On Wed, Oct 14, 2020 at 11:42 PM Viacheslav Ovsiienko >> wrote: >>> >>> The DPDK datapath in the transmit direction is very flexible. >>> An application can build the multi-segment packet and manages almost >>> all data aspects - the memory pools where segments are allocated from, >>> the segment lengths, the memory attributes like external buffers, >>> registered for DMA, etc. >>> > > [..snip..] > >>> For example, let's suppose we configured the Rx queue with the >>> following segments: >>> seg0 - pool0, len0=14B, off0=2 >>> seg1 - pool1, len1=20B, off1=128B >>> seg2 - pool2, len2=20B, off2=0B >>> seg3 - pool3, len3=512B, off3=0B >> >> >> Sorry for chime in late. This API lookout looks good to me. >> But, I am wondering how the application can know the capability or "limits" of >> struct rte_eth_rxseg structure for the specific PMD. The other descriptor limit, >> it's being exposed with struct rte_eth_dev_info::rx_desc_lim; If PMD can >> support a specific pattern rather than returning the blanket error, the >> application should know the limit. >> IMO, it is better to add >> struct rte_eth_rxseg *rxsegs; >> unint16_t nb_max_rxsegs >> in rte_eth_dev_info structure to express the capablity. >> Where the en and offset can define the max offset. >> >> Thoughts? > > Moreover, there might be implied a lot of various limitations - offsets might be not supported at all or > have some requirements for alignment, the similar requirements might be applied to segment size > (say, ask for some granularity). Currently it is not obvious how to report all nuances, and it is supposed > the limitations of this kind must be documented in PMD chapter. As for mlx5 - it has no special > limitations besides common requirements to the regular segments. > > One more point - the split feature might be considered as just one of possible cases of using > these segment descriptions, other features might impose other (unknown for now) limitations. > If we see some of the features of such kind or other PMDs adopts the split feature - we'll try to find > the common root and consider the way how to report it. At least there are few simple limitations which are easy to express: 1. Maximum number of segments 2. Possibility to use the last segment many times if required (I was suggesting to use scatter for it, but you rejected the idea - may be time to reconsider :) ) 3. Maximum offset Frankly speaking I'm not sure why it cannot be handled on PMD level (i.e. provide descriptors with offset taken into account or guarantee that HW mempool objects initialized correctly with required headroom). May be in some corner cases when the same HW mempool is shared by various segments with different offset requirements. 4. Offset alignment 5. Maximum/minimum length of a segment 6. Length alignment I realize that 3, 4 and 5 could be per segment number. If it is really that complex, report common denominator which is guaranteed to work. If we have no checks on ethdev layer, application can ignore it if it knows better.