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 95E5AA04B6; Mon, 12 Oct 2020 10:45:22 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6BC331D679; Mon, 12 Oct 2020 10:45:21 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by dpdk.org (Postfix) with ESMTP id 0EFC41D673 for ; Mon, 12 Oct 2020 10:45: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)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id A38927F5D9; Mon, 12 Oct 2020 11:45:18 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru A38927F5D9 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1602492318; bh=9lFzaGZXe8y88edB2Y2e2/9tRK9sZzsWWtPMJBMEbw8=; h=From:Subject:To:Cc:References:Date:In-Reply-To; b=d/71HICRDdgag4hCVUxl9rVO4u/HN1qnRGCaV80oaRRc74X0LpOrAYNE8FZhxRvTi O5kldtT8qQbBMqgUBJ2uNuKAZffJRi25jYj2fI2t1pY2OMT7iK/qH/YmN92nasHgyI phiKf3tD/YN4ylVgwG5dvTFY6dFgHseudqu3TtBo= From: Andrew Rybchenko To: Slava Ovsiienko , "dev@dpdk.org" Cc: Thomas Monjalon , "stephen@networkplumber.org" , "ferruh.yigit@intel.com" , Shahaf Shuler , "olivier.matz@6wind.com" , "jerinjacobk@gmail.com" , "maxime.coquelin@redhat.com" , "david.marchand@redhat.com" , Asaf Penso References: <1870d31a-0ec1-4198-fcee-03646c009458@solarflare.com> Organization: OKTET Labs Message-ID: <4d4be3cd-e418-00cf-ce6d-51f6c3e5c078@oktetlabs.ru> Date: Mon, 12 Oct 2020 11:45:18 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US 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" Hi Slava, I'm sorry for late reply. See my notes below. On 10/1/20 11:54 AM, Slava Ovsiienko wrote: > Hi, Andrew > > Thank you for the comments, please see my replies below. > >> -----Original Message----- >> From: Andrew Rybchenko >> Sent: Thursday, September 17, 2020 19:55 >> To: Slava Ovsiienko ; dev@dpdk.org >> Cc: Thomas Monjalon ; >> stephen@networkplumber.org; ferruh.yigit@intel.com; Shahaf Shuler >> ; olivier.matz@6wind.com; jerinjacobk@gmail.com; >> maxime.coquelin@redhat.com; david.marchand@redhat.com; Asaf Penso >> >> Subject: Re: [dpdk-dev] [RFC] ethdev: introduce Rx buffer split >> > [snip] >>> >>> For example, let's suppose we configured the Rx queue with the >>> following segments: >>> seg0 - pool0, len0=14B, off0=RTE_PKTMBUF_HEADROOM >>> seg1 - pool1, len1=20B, off1=0B >>> seg2 - pool2, len2=20B, off2=0B >>> seg3 - pool3, len3=512B, off3=0B >>> >>> The packet 46 bytes long will look like the following: >>> seg0 - 14B long @ RTE_PKTMBUF_HEADROOM in mbuf from pool0 >>> seg1 - 20B long @ 0 in mbuf from pool1 >>> seg2 - 12B long @ 0 in mbuf from pool2 >>> >>> The packet 1500 bytes long will look like the following: >>> seg0 - 14B @ RTE_PKTMBUF_HEADROOM in mbuf from pool0 >>> seg1 - 20B @ 0 in mbuf from pool1 >>> seg2 - 20B @ 0 in mbuf from pool2 >>> seg3 - 512B @ 0 in mbuf from pool3 >>> seg4 - 512B @ 0 in mbuf from pool3 >>> seg5 - 422B @ 0 in mbuf from pool3 >> >> The behaviour is logical, but what to do if HW can't do it, i.e. use >> the last >> segment many times. Should it reject configuration if provided >> segments are >> insufficient to fit MTU packet? How to report the limitation? >> (I'm still trying to convince that SCATTER and BUFFER_SPLIT should be >> independent). > > BUFFER_SPLIT is rather the way to tune SCATTER. Currently scattering > happens on unconditional mbuf data buffer boundaries (we have reserved > HEAD space in the first mbuf and fill this one to the buffer end, > the next mbuf buffers might be filled completely). BUFFER_SPLIT provides > the way to specify the desired points to split packet, not just blindly > follow buffer boundaries. There is the check inplemented in common part > if each split segment fits the mbuf allocated from appropriate pool. > PMD should do extra check internally whether it supports the requested > split settings, if not - call will be rejected. > @Thomas, @Ferruh: I'd like to hear what other ethdev maintainers think about it. > [snip] >> >> I dislike the idea to introduce new device operation. >> rte_eth_rxconf has reserved space and BUFFER_SPLIT offload will mean that >> PMD looks at the split configuration location there. >> > We considered the approach of pushing split setting to the rxconf > structure. > [http://patches.dpdk.org/patch/75205/] > But it seems there are some issues: > > - the split configuration description requires the variable length > array (due > to variations in number of segments), so rte_eth_rxconf structure would > have the variable length (not nice, IMO). > > We could push pointers to the array of rte_eth_rxseg, but we would lost > the single structure (and contiguous memory) simplicity, this approach has > no advantages over the specifying the split configuration as parameters > of setup_ex(). > I think it has a huge advantage to avoid extra device operation. > - it would introduces the ambiguity, rte_eth_rx_queue_setup() > specifies the single > mbuf pool as parameter. What should we do with it? Set to NULL? Treat > as the first pool? I would prefer to specify all split segments in > uniform fashion, i.e. as array or rte_eth_rxseg structures (and it can be > easily updated with some extra segment attributes if needed). So, in my > opinion, we should remove/replace the pool parameter in rx_queue_setup > (by introducing new func). > I'm trying to resolve the ambiguity as described above (see BUFFER_SPLIT vs SCATTER). Use the pointer for tail segments with respect to SCATTER capability. > - specifying the new extended setup roiutine has an advantage that we > should > not update any PMDs code in part of existing implementations of > rte_eth_rx_queue_setup(). It is not required since it is controlled by the new offload flags. If the offload is not supported, the new field is invisible for PMD (it simply ignores). > > If PMD supports BUFFER_SPLIT (or other related feature) it just should > provide > rte_eth_rx_queue_setup_ex() and check the DEV_RX_OFFLOAD_BUFFER_SPLIT > (or HEADER_SPLIT, or ever feature) it supports. The common code does > not check the feature flags - it is on PMDs' own. In order to > configure PMD > to perfrom arbitrary desired Rx spliting the application should check > DEV_RX_OFFLOAD_BUFFER_SPLIT in port capabilites, if found - set > DEV_RX_OFFLOAD_BUFFER_SPLIT in configuration and call > rte_eth_rx_queue_setup_ex(). > And this approach can be followed for any other split related feature. > > With best regards, Slava >