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 5614FA04DB; Thu, 15 Oct 2020 12:28:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9BCA91DE20; Thu, 15 Oct 2020 12:28:07 +0200 (CEST) Received: from mail-il1-f193.google.com (mail-il1-f193.google.com [209.85.166.193]) by dpdk.org (Postfix) with ESMTP id 116761D6F9 for ; Thu, 15 Oct 2020 12:28:06 +0200 (CEST) Received: by mail-il1-f193.google.com with SMTP id j17so596764ilr.2 for ; Thu, 15 Oct 2020 03:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Go/pVbp3M8AxKgigY1vHskGiOC4VwIqCY7iLgAeWVvE=; b=Xfc3laIT9iYNAb9OVqurJYmY0/4JMS8NzdTEJiqrqn5Y/vaoho1eqBEBpkEQM4CSX9 o5foNiQ0hQXN2jo7xe5QwLOc/wCW3SF987fUzKTexFzjQfvyPfcnFdXFAG9mPBrkpYVy D67fRBSp50RSWPDCzPIWfOMbitbk5NbDvgtolipMtv86ZeDkBr/casA5DY9DVO+LdTkl VcgaJ/HZSG/ubuNJgTqNpS/NyJQgEsjs4AnM6TVG98oDfeEzPa9ZxvSLvS+dNnPoY5G2 EaBSB9zHIA0JYF8iQPzK/Saw6GGQkVPq6yetoYNQJKQrAo6eqf1T/pt1X/Sg630gVHro 8ZjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Go/pVbp3M8AxKgigY1vHskGiOC4VwIqCY7iLgAeWVvE=; b=rkR29pNEO9Tt39WNNBRhX6YM/tBo806uEXFUJAgucndHIU0Q03WI2wYhPolBRUCg7S 5pbNs0m6iVLOJnxv1+5IFlX1s7y3GY3UMJsTLMFsfWNoGKFvDZDYM6kMJevEtGRywtux xYDvzILv19Ei4UKKWiNItdoB92huYWwWz7gq6yaSzd8IC2Yc1bsN4rbUMU3559W1DNNJ P7YDOSJXFBS+URPILlBWZeNntn3VK6X/LboBvXZO5jZjKOAC3OR3+vKns0LVYbZEukBj XtyLrVena+sHxi3K2e0SADFV7TevKBlwQDOseJTIhX4beAurV19WbGfi6NZdbIGwLNLJ JmTQ== X-Gm-Message-State: AOAM533kCnvY1koRVnXZUM37WYyEKdghvir6oA7piqOYI9qEnm/4watL EB7ORy3T2V1duHRV4G/jPI9KYlDt7z12W5u95U0= X-Google-Smtp-Source: ABdhPJxb1THLbnfwYE12c/O7thmgR0zsPZGVypZD27WW4ChfZspgoe95gVOI7S3CW9ZVpgFh7Qpf1ojG+KY39B8eTg4= X-Received: by 2002:a92:d7c4:: with SMTP id g4mr2563463ilq.162.1602757684353; Thu, 15 Oct 2020 03:28:04 -0700 (PDT) MIME-Version: 1.0 References: <1602699122-15737-1-git-send-email-viacheslavo@nvidia.com> <1602699122-15737-2-git-send-email-viacheslavo@nvidia.com> In-Reply-To: From: Jerin Jacob Date: Thu, 15 Oct 2020 15:57:47 +0530 Message-ID: To: Slava Ovsiienko Cc: dpdk-dev , NBU-Contact-Thomas Monjalon , Stephen Hemminger , Ferruh Yigit , Olivier Matz , Maxime Coquelin , David Marchand , Andrew Rybchenko Content-Type: text/plain; charset="UTF-8" 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 Thu, Oct 15, 2020 at 2:57 PM Jerin Jacob wrote: > > On Thu, Oct 15, 2020 at 1:13 PM Slava Ovsiienko wrote: > > > > Hi, Jerin > > Hi Slava, > > > > > > -----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. > > Reporting the limitation in the documentation will not help for the > generic applications. > > > > > 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. Also , I agree that w will have multiple use cases with segment descriptors. In order to make it future proof on the API definion is better to have from: struct rte_eth_rxseg { struct rte_mempool *mp; /**< Memory pool to allocate segment from. */ uint16_t length; /**< Segment data length, configures split point. */ uint16_t offset; /**< Data offset from beginning of mbuf data buffer. */ uint32_t reserved; /**< Reserved field. */ }; something lime below: struct rte_eth_rxseg { enum rte_eth_rxseg_mode mode ; union { struct rte_eth_rxseg_mode xxx { struct rte_mempool *mp; /**< Memory pool to allocate segment from. */ uint16_t length; /**< Segment data length, configures split point. */ uint16_t offset; /**< Data offset from beginning of mbuf data buffer. */ uint32_t reserved; /**< Reserved field. */ } } Another mode, Marvell PMD has it(I believe Intel also) i.e When we say: seg0 - pool0, len0=2000B, off0=0 seg1 - pool1, len1=2001B, off1=0 packet size up to, 2000B goes to pool 0 and if is >=2001 goes to pool1. I think, it is better to have mode param in rte_eth_rxseg for avoiding ABI changes.(Just like clean rte_flow APIs) > > 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. > > My only concern with that approach will be ABI break again if > something needs to exposed over rte_eth_dev_info(). > IMO, if we featured needs to completed only when its capabilities are > exposed in a programmatic manner. > As of mlx5, if there not limitation then info > rte_eth_dev_info::rxsegs[x].len, offset etc as UINT16_MAX so > that application is aware of the state. > > > > > With best regards, Slava > >