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 4C82AA04DC; Thu, 15 Oct 2020 13:27:20 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E5F8F1DBC3; Thu, 15 Oct 2020 13:27:17 +0200 (CEST) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by dpdk.org (Postfix) with ESMTP id 23BD01D62F for ; Thu, 15 Oct 2020 13:27:16 +0200 (CEST) Received: by mail-io1-f67.google.com with SMTP id q9so3802635iow.6 for ; Thu, 15 Oct 2020 04:27:16 -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=fuN7GN4iKNZCNoW87/gr0R6ItTlrD6nmQ8N+OdNEQow=; b=Ypxzv5Py28my7C3Zfz4N7VUszP9Yn1o4KzF0XL10nfOgTLkv6O3I2Ch1kh+SKJQ91d hSDTkELJ38Xo67NtMpUFgVfxl6gRYuXOQNGO3To2QkoM7p/Nt5qqxHlMUiC+cwVE3YEF 6lMN3zATJ0edOEuzxlYub1cuTpOcI8dEFDFAtngwFWNPVafcXWiudam0g7PqEorO5FPk aP/KVjYxD9GuY4+ueVyk+M5lBCbeuWV4/UhqjIbfNZJmlLebGHenYiNgIf9HjUUwnjh8 JnirU+QCPbdogJ9LnALk23SVn2WZPnNAB4Yi9xQO1TMiT7LEplqw5myhG7KqppzQnhEk NTnA== 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=fuN7GN4iKNZCNoW87/gr0R6ItTlrD6nmQ8N+OdNEQow=; b=rjHFKS82K9v6XfYQ203N6T3QaoqXiuMd/Z8QdV1meTrovl0sWAN2wL8zUj19eiktZS sxxxC7r/hC8id5Ze/622phdKIZNT3i5Qyby1KF54g2AC4+WgThMnlz78p/2T2doAQCnP DiBZoIYcrB1RyQYeDTe/IAjNQWovbF4U2saoAb08f7skAIrlMZmMpTP+cHts0X+a+JYw YjLy9kTOZxUx+gaPnU9T5dWCtJW6eeRKxKsUc88wg4ujETaGo2c9aSMsikOfgXkcSc1T XWao/uXep46w4A4vPwCYGxlziBgIpqgs3pUtP2z4N53bp73LfO/sEB2zQgsq45kwHrAL RiYA== X-Gm-Message-State: AOAM532n77Dnob69B9tZvsDRX1nKF3YGGBbS6RJeg34SYS3b3AYIgv3D U+b3dQPdQupARLTMDmPRPhdGAWRFkRQMnmhgQzI= X-Google-Smtp-Source: ABdhPJzgQZpOkhOLfGjePwuAztOPVDXtBn7jUR+uo9lY1PiExYoLrWl5zlvWHqVmECl2EvnRyqnk61XFq+XaDEDpZi0= X-Received: by 2002:a6b:ce1a:: with SMTP id p26mr2662961iob.94.1602761234286; Thu, 15 Oct 2020 04:27:14 -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 16:56:57 +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 4:21 PM Slava Ovsiienko wrote: > > Hi, Jerin > > > -----Original Message----- > > From: Jerin Jacob > > Sent: Thursday, October 15, 2020 13:28 > > 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 > > > [..snip..] > > > > 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. */ > > } > > } > > There is an array of rte_eth_rxseg. It would introduce multiple "enum rte_eth_rxseg_mode mode" > and would cause some ambiguity. About mode selection - please, see below. > Union seems to be good idea, let's adopt. Ack. Let's take the only union concept. > > > > > 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) > > It is supposed to choose with RTE_ETH_RX_OFFLOAD_xxx flags. > For packet sorting it should be something like this RTE_ETH_RX_OFFLOAD_SORT. > PMD reports it supports the feature, the flag is set in rx_conf->offloads > and rxseg structure is interpreted according to these flags. Works for me. > > Please, note, there is intentionally no check for RTE_ETH_RX_OFFLOAD_xxx > in rte_eth_dev_rx_queue_setup() - it should be done on PMD side. > > > > > > > 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(). > > Let's reserve the pointer to struct rte_eth_rxseg_limitations > in the rte_eth_dev_info to avoid ABI break? Works for me. If we add an additional reserved field. Due to RC1 time constraint, I am OK to leave it as a reserved filed and fill meat when it is required if other ethdev maintainers are OK. I will be required for feature complete. > > With best regards, Slava