DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@xilinx.com>
To: Hanumanth Reddy Pothula <hpothula@marvell.com>,
	"Ding, Xuan" <xuan.ding@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"Wu, WenxuanX" <wenxuanx.wu@intel.com>,
	"Li, Xiaoyun" <xiaoyun.li@intel.com>,
	"stephen@networkplumber.org" <stephen@networkplumber.org>,
	"Wang, YuanX" <yuanx.wang@intel.com>,
	"mdr@ashroe.eu" <mdr@ashroe.eu>,
	"Zhang, Yuying" <yuying.zhang@intel.com>,
	"Zhang, Qi Z" <qi.z.zhang@intel.com>,
	"viacheslavo@nvidia.com" <viacheslavo@nvidia.com>,
	Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
	Nithin Kumar Dabilpuram <ndabilpuram@marvell.com>
Subject: Re: [EXT] Re: [PATCH v2 1/3] ethdev: introduce pool sort capability
Date: Wed, 7 Sep 2022 12:24:24 +0100	[thread overview]
Message-ID: <1e1ae69c-8cf3-5447-762f-ef00616dc225@xilinx.com> (raw)
In-Reply-To: <PH0PR18MB475075D7A0F3173021C410C4CB419@PH0PR18MB4750.namprd18.prod.outlook.com>

On 9/7/2022 8:02 AM, Hanumanth Reddy Pothula wrote:
> 
> 
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit@xilinx.com>
>> Sent: Tuesday, September 6, 2022 5:48 PM
>> To: Hanumanth Reddy Pothula <hpothula@marvell.com>; Ding, Xuan
>> <xuan.ding@intel.com>; Thomas Monjalon <thomas@monjalon.net>; Andrew
>> Rybchenko <andrew.rybchenko@oktetlabs.ru>
>> Cc: dev@dpdk.org; Wu, WenxuanX <wenxuanx.wu@intel.com>; Li, Xiaoyun
>> <xiaoyun.li@intel.com>; stephen@networkplumber.org; Wang, YuanX
>> <yuanx.wang@intel.com>; mdr@ashroe.eu; Zhang, Yuying
>> <yuying.zhang@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
>> viacheslavo@nvidia.com; Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
>> Nithin Kumar Dabilpuram <ndabilpuram@marvell.com>
>> Subject: Re: [EXT] Re: [PATCH v2 1/3] ethdev: introduce pool sort capability
>>
>> On 8/30/2022 1:08 PM, Hanumanth Reddy Pothula wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Ferruh Yigit <ferruh.yigit@xilinx.com>
>>>> Sent: Wednesday, August 24, 2022 9:04 PM
>>>> To: Ding, Xuan <xuan.ding@intel.com>; Hanumanth Reddy Pothula
>>>> <hpothula@marvell.com>; Thomas Monjalon <thomas@monjalon.net>;
>> Andrew
>>>> Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>> Cc: dev@dpdk.org; Wu, WenxuanX <wenxuanx.wu@intel.com>; Li, Xiaoyun
>>>> <xiaoyun.li@intel.com>; stephen@networkplumber.org; Wang, YuanX
>>>> <yuanx.wang@intel.com>; mdr@ashroe.eu; Zhang, Yuying
>>>> <yuying.zhang@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
>>>> viacheslavo@nvidia.com; Jerin Jacob Kollanukkaran
>>>> <jerinj@marvell.com>; Nithin Kumar Dabilpuram
>>>> <ndabilpuram@marvell.com>
>>>> Subject: [EXT] Re: [PATCH v2 1/3] ethdev: introduce pool sort
>>>> capability
>>>>
>>>> External Email
>>>>
>>>> ---------------------------------------------------------------------
>>>> -
>>>
>>>
>>> Thanks Ding Xuan and Ferruh Yigit for reviewing the changes and for providing
>> your valuable feedback.
>>> Please find responses inline.
>>>
>>>> On 8/23/2022 4:26 AM, Ding, Xuan wrote:
>>>>> Hi Hanumanth,
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Hanumanth Pothula <hpothula@marvell.com>
>>>>>> Sent: Saturday, August 13, 2022 1:25 AM
>>>>>> To: Thomas Monjalon <thomas@monjalon.net>; Ferruh Yigit
>>>>>> <ferruh.yigit@xilinx.com>; Andrew Rybchenko
>>>>>> <andrew.rybchenko@oktetlabs.ru>
>>>>>> Cc: dev@dpdk.org; Ding, Xuan <xuan.ding@intel.com>; Wu, WenxuanX
>>>>>> <wenxuanx.wu@intel.com>; Li, Xiaoyun <xiaoyun.li@intel.com>;
>>>>>> stephen@networkplumber.org; Wang, YuanX <yuanx.wang@intel.com>;
>>>>>> mdr@ashroe.eu; Zhang, Yuying <yuying.zhang@intel.com>; Zhang, Qi Z
>>>>>> <qi.z.zhang@intel.com>; viacheslavo@nvidia.com; jerinj@marvell.com;
>>>>>> ndabilpuram@marvell.com; Hanumanth Pothula <hpothula@marvell.com>
>>>>>> Subject: [PATCH v2 1/3] ethdev: introduce pool sort capability
>>>>>>
>>>>>> Presently, the 'Buffer Split' feature supports sending multiple
>>>>>> segments of the received packet to PMD, which programs the HW to
>>>>>> receive the packet in segments from different pools.
>>>>>>
>>>>>> This patch extends the feature to support the pool sort capability.
>>>>>> Some of the HW has support for choosing memory pools based on the
>>>>>> packet's size. The pool sort capability allows PMD to choose a
>>>>>> memory pool based on the packet's length.
>>>>>>
>>>>>> This is often useful for saving the memory where the application
>>>>>> can create a different pool to steer the specific size of the
>>>>>> packet, thus enabling effective use of memory.
>>>>>>
>>>>>> For example, let's say HW has a capability of three pools,
>>>>>>     - pool-1 size is 2K
>>>>>>     - pool-2 size is > 2K and < 4K
>>>>>>     - pool-3 size is > 4K
>>>>>> Here,
>>>>>>            pool-1 can accommodate packets with sizes < 2K
>>>>>>            pool-2 can accommodate packets with sizes > 2K and < 4K
>>>>>>            pool-3 can accommodate packets with sizes > 4K
>>>>>>
>>>>>> With pool sort capability enabled in SW, an application may create
>>>>>> three pools of different sizes and send them to PMD. Allowing PMD
>>>>>> to program HW based on packet lengths. So that packets with less
>>>>>> than 2K are received on pool-1, packets with lengths between 2K and
>>>>>> 4K are received on pool-2 and finally packets greater than 4K are
>>>>>> received on pool-
>>>> 3.
>>>>>>
>>>>>> The following two capabilities are added to the rte_eth_rxseg_capa
>>>>>> structure, 1. pool_sort --> tells pool sort capability is supported by HW.
>>>>>> 2. max_npool --> max number of pools supported by HW.
>>>>>>
>>>>>> Defined new structure rte_eth_rxseg_sort, to be used only when pool
>>>>>> sort capability is present. If required this may be extended
>>>>>> further to support more configurations.
>>>>>>
>>>>>> Signed-off-by: Hanumanth Pothula <hpothula@marvell.com>
>>>>>>
>>>>>> v2:
>>>>>>     - Along with spec changes, uploading testpmd and driver changes.
>>>>>
>>>>> Thanks for CCing. It's an interesting feature.
>>>>>
>>>>> But I have one question here:
>>>>> Buffer split is for split receiving packets into multiple segments,
>>>>> while pool sort supports PMD to put the receiving packets into
>>>>> different pools
>>>> according to packet size.
>>>>> Every packet is still intact.
>>>>>
>>>>> So, at this level, pool sort does not belong to buffer split.
>>>>> And you already use a different function to check pool sort rather
>>>>> than check
>>>> buffer split.
>>>>>
>>>>> Should a new RX offload be introduced? like
>>>> "RTE_ETH_RX_OFFLOAD_POOL_SORT".
>>>>>
>>> Please find my response below.
>>>>
>>>> Hi Hanumanth,
>>>>
>>>> I had the similar concern with the feature. I assume you want to
>>>> benefit from exiting config structure that gets multiple mempool as
>>>> argument, since this feature also needs multiple mempools, but the feature is
>> different.
>>>>
>>>> It looks to me wrong to check 'OFFLOAD_BUFFER_SPLIT' offload to
>>>> decide if to receive into multiple mempool or not, which doesn't have
>> anything related split.
>>>> Also not sure about using the 'sort' keyword.
>>>> What do you think to introduce new fetaure, instead of extending
>>>> existing split one?
>>>
>>> Actually we thought both BUFFER_SPLIT and POOL_SORT are similar
>>> features where RX pools are configured in certain way and thought not
>>> use up one more RX offload capability, as the existing software architecture
>> can be extended to support pool_sort capability.
>>> Yes, as part of pool sort, there is no buffer split but pools are picked based on
>> the buffer length.
>>>
>>> Since you think it's better to use new RX offload for POOL_SORT, will go ahead
>> and implement the same.
>>>
>>>> This is optimisation, right? To enable us to use less memory for the
>>>> packet buffer, does it qualify to a device offload?
>>>>
>>> Yes, its qualify as a device offload and saves memory.
>>> Marvel NIC has a capability to receive packets on  two different pools based
>> on its length.
>>> Below explained more on the same.
>>>>
>>>> Also, what is the relation with segmented Rx, how a PMD decide to use
>>>> segmented Rx or bigger mempool? How can application can configure this?
>>>>
>>>> Need to clarify the rules, based on your sample, if a 512 bytes
>>>> packet received, does it have to go pool-1, or can it go to any of three pools?
>>>>
>>> Here, Marvell NIC supports two HW pools, SPB(small packet buffer) pool and
>> LPB(large packet buffer) pool.
>>> SPB pool can hold up to 4KB
>>> LPB pool can hold anything more than 4KB Smaller packets are received
>>> on SPB pool and larger packets on LPB pool, based on the RQ configuration.
>>> Here, in our case HW pools holds whole packet. So if a packet is
>>> divided into segments, lower layer HW going to receive all segments of
>>> the packet and then going to place the whole packet in SPB/LPB pool, based
>> on the packet length.
>>>
>>
>> If the packet is bigger than 4KB, you have two options,
>> 1- Use multiple chained buffers in SPB
>> 2- Use single LPB buffer
>>
>> As I understand (2) is used in this case, but I think we should clarify how this
>> feature works with 'RTE_ETH_RX_OFFLOAD_SCATTER' offload, if it is requested
>> by user.
>>
>> Or lets say HW has two pools with 1K and 2K sizes, what is expected with 4K
>> packet, with or without scattered Rx offload?
>>
> 
> As mentioned, Marvell supports two pools, pool-1(SPB) and pool-2(LPB)
> If the packet length is within pool-1 length and has only one segment then the packet is allocated from pool-1.
> If the packet length is greater than pool-1 or has more than one segment then the packet is allocated from pool-2.
> 
> So, here packets with a single segment and length less than 1K are allocated from pool-1 and
> packets with multiple segments or packets with length greater than 1K are allocated from pool-2.
> 

To have multiple segment or not is HW configuration, it is not external 
variable. Drivers mostly decide to configure HW to receive multiple 
segment or not based on buffer size and max packet size device support.
In this case since buffer size is not fixed, there are multiple buffer 
sizes, how driver will configure HW?

This is not specific to Marvell HW, for the case multiple mempool 
supported, it is better to clarify in this patch how it is works with 
'RTE_ETH_RX_OFFLOAD_SCATTER' offload.

>>> As pools are picked based on the packets length we used SORT term. In case
>> you have any better term(word), please suggest.
>>>
>>
>> what about multiple pool, like RTE_ETH_RX_OFFLOAD_MULTIPLE_POOL, I think
>> it is more clear but I would like to get more comments from others, naming is
>> hard ;)
>>
> Yes, RTE_ETH_RX_OFFLOAD_MULTIPLE_POOL is clearer than RTE_ETH_RX_OFFLOAD_SORT_POOL.
> Thanks for the suggestion.
> Will upload V4 with RTE_ETH_RX_OFFLOAD_MULTIPLE_POOL.
> 
>>>>
>>>> And I don't see any change in the 'net/cnxk' Rx burst code, when
>>>> multiple mempool used, while filling the mbufs shouldn't it check
>>>> which mempool is filled. How this works without update in the Rx
>>>> burst code, or am I missing some implementation detail?
>>>>
>>> Please find PMD changes in patch [v2,3/3] net/cnxk: introduce pool
>>> sort capability Here, in control path, HW pools are programmed based on the
>> inputs it received from the application.
>>> Once the HW is programmed, packets are received on HW pools based the
>> packets sizes.
>>
>> I was expecting to changes in datapath too, something like in Rx burst function
>> check if spb or lpb is used and update mbuf pointers accordingly.
>> But it seems HW doesn't work this way, can you please explain how this feature
>> works transparent to datapath code?
>>
>>>>
>>>
>>> I will upload V3 where POOL_SORT is implemented as new RX OFFLOAD, unless
>> If you have any other suggestion/thoughts.
>>>
>>
>> <...>
> 


  reply	other threads:[~2022-09-07 11:24 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-12 10:46 [PATCH v1 1/1] " Hanumanth Pothula
2022-08-12 13:27 ` Morten Brørup
2022-08-12 17:24 ` [PATCH v2 1/3] " Hanumanth Pothula
2022-08-12 17:24   ` [PATCH v2 2/3] app/testpmd: add command line argument 'rxseg-mode' Hanumanth Pothula
2022-08-12 17:24   ` [PATCH v2 3/3] net/cnxk: introduce pool sort capability Hanumanth Pothula
2022-08-23  3:26   ` [PATCH v2 1/3] ethdev: " Ding, Xuan
2022-08-24 15:33     ` Ferruh Yigit
2022-08-30 12:08       ` [EXT] " Hanumanth Reddy Pothula
2022-09-06 12:18         ` Ferruh Yigit
2022-09-07  7:02           ` Hanumanth Reddy Pothula
2022-09-07 11:24             ` Ferruh Yigit [this message]
2022-09-07 21:31               ` Hanumanth Reddy Pothula
2022-09-13  9:28                 ` Ferruh Yigit
2022-09-13 10:00                   ` Hanumanth Reddy Pothula
2022-09-02  7:00   ` [PATCH v3 " Hanumanth Pothula
2022-09-02  7:00     ` [PATCH v3 2/3] app/testpmd: Add support for " Hanumanth Pothula
2022-09-02  7:00     ` [PATCH v3 3/3] net/cnxk: introduce " Hanumanth Pothula
2022-09-13  8:06     ` [PATCH v3 1/3] ethdev: " Andrew Rybchenko
2022-09-13  9:31       ` Ferruh Yigit
2022-09-13 10:41         ` [EXT] " Hanumanth Reddy Pothula
2022-09-15  7:07     ` [PATCH v4 1/3] ethdev: Add support for mulitiple mbuf pools per Rx queue Hanumanth Pothula
2022-09-15  7:07       ` [PATCH v4 2/3] app/testpmd: " Hanumanth Pothula
2022-09-15  7:07       ` [PATCH v4 3/3] net/cnxk: Add support for mulitiple mbuf pools Hanumanth Pothula
2022-09-28  9:43       ` [PATCH v4 1/3] ethdev: Add support for mulitiple mbuf pools per Rx queue Andrew Rybchenko
2022-09-28 11:06         ` Thomas Monjalon
2022-10-06 17:01       ` [PATCH v5 1/3] ethdev: support " Hanumanth Pothula
2022-10-06 17:01         ` [PATCH v5 2/3] net/cnxk: " Hanumanth Pothula
2022-10-06 17:01         ` [PATCH v5 3/3] app/testpmd: " Hanumanth Pothula
2022-10-06 17:29         ` [PATCH v5 1/3] ethdev: " Stephen Hemminger
2022-10-07 14:13           ` Andrew Rybchenko
2022-10-06 17:53         ` [PATCH v6 " Hanumanth Pothula
2022-10-06 17:53           ` [PATCH v6 2/3] net/cnxk: " Hanumanth Pothula
2022-10-06 17:53           ` [PATCH v6 3/3] app/testpmd: " Hanumanth Pothula
2022-10-06 18:14           ` [PATCH v6 1/3] ethdev: " Hanumanth Reddy Pothula
2022-10-07 14:37         ` [PATCH v7 0/4] " Andrew Rybchenko
2022-10-07 14:37           ` [PATCH v7 1/4] ethdev: factor out helper function to check Rx mempool Andrew Rybchenko
2022-10-07 14:37           ` [PATCH v7 2/4] ethdev: support mulitiple mbuf pools per Rx queue Andrew Rybchenko
2022-10-07 16:08             ` Thomas Monjalon
2022-10-07 16:18               ` Stephen Hemminger
2022-10-07 16:20                 ` Stephen Hemminger
2022-10-07 16:33                   ` Andrew Rybchenko
2022-10-07 17:30               ` Andrew Rybchenko
2022-10-07 14:37           ` [PATCH v7 3/4] net/cnxk: " Andrew Rybchenko
2022-10-07 14:37           ` [PATCH v7 4/4] app/testpmd: " Andrew Rybchenko
2022-10-07 17:29         ` [PATCH v8 0/4] ethdev: " Andrew Rybchenko
2022-10-07 17:29           ` [PATCH v8 1/4] ethdev: factor out helper function to check Rx mempool Andrew Rybchenko
2022-10-07 17:29           ` [PATCH v8 2/4] ethdev: support multiple mbuf pools per Rx queue Andrew Rybchenko
2022-10-07 18:35             ` Thomas Monjalon
2022-10-07 19:45               ` Andrew Rybchenko
2022-10-07 17:29           ` [PATCH v8 3/4] net/cnxk: support mulitiple " Andrew Rybchenko
2022-10-07 17:29           ` [PATCH v8 4/4] app/testpmd: " Andrew Rybchenko
     [not found]             ` <PH0PR18MB47500560DC1793F68E7312DDCB5F9@PH0PR18MB4750.namprd18.prod.outlook.com>
2022-10-07 19:43               ` [EXT] " Andrew Rybchenko
2022-10-07 19:56                 ` Hanumanth Reddy Pothula
2022-10-17  8:48             ` [PATCH v9 1/1] " Hanumanth Pothula
2022-10-21 15:57               ` Singh, Aman Deep
2022-10-24  3:32                 ` [EXT] " Hanumanth Reddy Pothula
2022-10-24  4:07               ` [PATCH v10 1/1] app/testpmd: support multiple " Hanumanth Pothula
2022-10-25  1:40                 ` [PATCH v11 " Hanumanth Pothula
2022-11-01 14:13                   ` Hanumanth Reddy Pothula
2022-11-03 12:15                   ` Singh, Aman Deep
2022-11-03 12:36                     ` [EXT] " Hanumanth Reddy Pothula
2022-11-03 15:20                       ` Singh, Aman Deep
2022-11-04 15:38                         ` Hanumanth Reddy Pothula
2022-11-07  5:31                   ` [PATCH v12 " Hanumanth Pothula
2022-11-09  8:04                     ` Singh, Aman Deep
2022-11-09 10:39                       ` Andrew Rybchenko
2022-11-10  6:51                         ` Andrew Rybchenko
2022-11-10  8:17                     ` [PATCH v13 " Hanumanth Pothula
2022-11-10  9:01                       ` Andrew Rybchenko
2022-11-10  9:31                         ` [EXT] " Hanumanth Reddy Pothula
2022-11-10 10:16                       ` [PATCH v14 " Hanumanth Pothula
2022-11-10 10:47                         ` Andrew Rybchenko
2022-11-17  8:43                         ` Jiang, YuX
2022-11-17 11:38                           ` Hanumanth Reddy Pothula
2022-10-08 20:38           ` [PATCH v8 0/4] ethdev: support mulitiple " Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1e1ae69c-8cf3-5447-762f-ef00616dc225@xilinx.com \
    --to=ferruh.yigit@xilinx.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=hpothula@marvell.com \
    --cc=jerinj@marvell.com \
    --cc=mdr@ashroe.eu \
    --cc=ndabilpuram@marvell.com \
    --cc=qi.z.zhang@intel.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    --cc=viacheslavo@nvidia.com \
    --cc=wenxuanx.wu@intel.com \
    --cc=xiaoyun.li@intel.com \
    --cc=xuan.ding@intel.com \
    --cc=yuanx.wang@intel.com \
    --cc=yuying.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).