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 09173A32A8 for ; Sat, 26 Oct 2019 08:58:46 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 027757CBC; Sat, 26 Oct 2019 08:58:45 +0200 (CEST) Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by dpdk.org (Postfix) with ESMTP id 1B8CD2BA2 for ; Sat, 26 Oct 2019 08:58:44 +0200 (CEST) Received: by mail-io1-f65.google.com with SMTP id c11so4916909iom.10 for ; Fri, 25 Oct 2019 23:58:44 -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=fVfsbl/r1cDSaDk6qZCFeA4uPTlP5rWussVvg6HAK9k=; b=qKbDVd4/5leUEn27knCXMPmQeCmrAQowyRFCmZdFwDV8XlCe7fLZvPbuDrHOYjc4KF WzCPuh53zByUxo/JxQ/Ra3VriZUtSg4JopP82o6t9cY3c7Fqlh9PAhWf1GyhL8P+zcE2 qUUY5OTGHGPv8KlckpxjwC/lr6jF0H4H6tcmXL7us9cMW1u0YOH/siyaMqC2kL+URUkc 8OmS/IH+X4i7z00fINUbDLRsCzU/U9a3CKKdVrMfzMxaJ3+GHiYvD5vxwjQVzAjG+sR/ BE9MrNbUt06fBxx+AdLZNB11vFAsS1h8n/F+/+6S/1uKCuzqqXHagmuD1cWNi9itR6R7 NK9g== 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=fVfsbl/r1cDSaDk6qZCFeA4uPTlP5rWussVvg6HAK9k=; b=Kq+H86kMbZSGiXx5N+iCFgGM6PUe5tOElQFzn8e+SPtDKc6No8VsfayvIiUHWibGFg XAoOZy3v49I29DfwBAngrbAZcGHo3COSB4CNbud/Xu1fNSpYXW7Q9tLzVAFijTGFq3fP qiBxcGUNpYKrosxTIc25KoteHE/71dlJtK9192ZdMdGRBKIYtNjtv5mb/IpUTORT9oNW Ab5pW03LEcJGlc0WbMupOScbYc6kA6YH+CBCNpjOmlFUiSRtxaIOcBl1ZwAYE37Sg471 OR63gXFLHNJFeR13ov3DK3gZ1I+dEGURUcfq1bSLqz+dblcf3orCrWgumFBgZ3YqNFBY ZvkQ== X-Gm-Message-State: APjAAAXmu/fSdSaX8UMmlrC0LlKJSk7c/BfSCsYTMmstob0+P1nUoVQK c8W+m2lgzzIeYh6xDQm9k1AyCeaeVqp8xyud358= X-Google-Smtp-Source: APXvYqzKFTH4Y+cp8pULNihXK501Ha/DouRaLr3Og2sSmK2g540e48v8syqEDSTYkhkdUslb6vHzaS2TK3cmzVnVhSM= X-Received: by 2002:a5e:9515:: with SMTP id r21mr7746525ioj.271.1572073123228; Fri, 25 Oct 2019 23:58:43 -0700 (PDT) MIME-Version: 1.0 References: <20191015075133.38560-1-haiyue.wang@intel.com> <1811898.7XjjD7ZjLQ@xps> <12001140.UMXFOKstgs@xps> In-Reply-To: <12001140.UMXFOKstgs@xps> From: Jerin Jacob Date: Sat, 26 Oct 2019 12:28:26 +0530 Message-ID: To: Thomas Monjalon Cc: Ferruh Yigit , Haiyue Wang , dpdk-dev , xiaolong.ye@intel.com, ray.kinsella@intel.com, Bernard Iremonger , chenmin.sun@intel.com, Andrew Rybchenko , Slava Ovsiienko , Stephen Hemminger , David Marchand , Jerin Jacob Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting burst mode information 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 Sat, Oct 26, 2019 at 3:57 AM Thomas Monjalon wrote: > > 25/10/2019 18:02, Jerin Jacob: > > On Fri, Oct 25, 2019 at 9:15 PM Thomas Monjalon wrote: > > > 25/10/2019 16:08, Ferruh Yigit: > > > > On 10/25/2019 10:36 AM, Thomas Monjalon wrote: > > > > > 15/10/2019 09:51, Haiyue Wang: > > > > >> Some PMDs have more than one RX/TX burst paths, add the ethdev API > > > > >> that allows an application to retrieve the mode information about > > > > >> Rx/Tx packet burst such as Scalar or Vector, and Vector technology > > > > >> like AVX2. > > > > > > > > > > I missed this patch. I and Andrew, maintainers of ethdev, were not CC'ed. > > > > > Ferruh, I would expect to be Cc'ed and/or get a notification before merging. > > > > > > > > It has been discussed in the mail list and went through multiple discussions, > > > > patch is out since the August, +1 to cc all maintainers I missed that part, > > > > but when the patch is reviewed and there is no objection, why block the merge? > > > > > > I'm not saying blocking the merge. > > > My bad is that I missed the patch and I am asking for help with a notification > > > in this case. Same for Andrew I guess. > > > Note: it is merged in master and I am looking to improve this feature. > > > > > > >> +/** > > > > >> + * Ethernet device RX/TX queue packet burst mode information structure. > > > > >> + * Used to retrieve information about packet burst mode setting. > > > > >> + */ > > > > >> +struct rte_eth_burst_mode { > > > > >> + uint64_t options; > > > > >> +}; > > > > > > > > > > Why a struct for an integer? > > > > > > > > Again by a request from me, to not need to break the API if we need to add more > > > > thing in the future. > > > > > > I would replace it with a string. This is the most flexible API. > > > > IMO, Probably, best of both worlds make a good option here, > > as Haiyue suggested if we have an additional dev_specific[1] in structure. > > and when a pass to the application, let common code make final string as > > (options flags to string + dev_specific) > > > > options flag can be zero if PMD does not have any generic flags nor > > interested in such a scheme. > > Generic flags will help at least to have some common code. > > > > [1] > > struct rte_eth_burst_mode { > > uint64_t options; > > char dev_specific[128]; /* PMD has specific burst mode information */ > > }; > > I really don't see how we can have generic flags. > The flags which are proposed are just matching > the functions implemented in Intel PMDs. > And this is a complicate solution. > Why not just returning a name for the selected Rx/Tx mode? +1 only for the name Let me clarify my earlier proposal: 1) The public ethdev API should return only "string" i.e the flags SHOULD NOT be exposed as ethdev API i.e int rte_eth_tx_burst_mode_name(uint16_t port_id, uint16_t queue_id, char *name); 2) The PMD interface to the common code can be following struct eth_pmd_burst_mode { uint64_t options; char name[128]; /* PMD specific burst mode information */ }; typedef int (*eth_burst_mode_get_t)(struct rte_eth_dev *dev, uint16_t queue_id, struct eth_burst_mode *mode) 3) The implementation of rte_eth_tx_burst_mode_name() shall do optons flag to string converion(again internal to common code implemetation) and concatenate with eth_pmd_burst_mode::name This would help to reuse some of the flags to name conversion logic across all PMDs. And PMD are free to return eth_pmd_burst_mode::options as zero in that case final string only be eth_pmd_burst_mode::name. I don't see any downside with this approach and it best of both worlds. > >