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 2055FA32A4 for ; Fri, 25 Oct 2019 18:03:17 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 42BE91D153; Fri, 25 Oct 2019 18:03:16 +0200 (CEST) Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) by dpdk.org (Postfix) with ESMTP id 9068F1C43F for ; Fri, 25 Oct 2019 18:03:15 +0200 (CEST) Received: by mail-il1-f195.google.com with SMTP id v2so2292199ilq.4 for ; Fri, 25 Oct 2019 09:03:15 -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=W4u3teIqueKNQWsKlExofqDGIXa3PoRbTacP44eb2nA=; b=Tx3OSaZzxB5VH9Xn/9mVQgPIhNgDd3BjzbqkxjrLyIi/l7K20MfE4yq+NpubpzB6et bOJqlqvrJ9Bjv+kUBeamN/y1jSrRlh8KOz78Zmo2ZPpmtDL+PtunXlhABCA5rUQTggHK 67DDmqm6lZmI/jKcRDiogWTKZCdRgHGuJiIELAVz8XdSwMi966wJ/PoTI+mLgaYPmhWB u+6JxTAliUzAvNObykyaFZjOrr67XZL1W5pXfgY29AOKQY7l7fg+UqqyYP3ra5PTlft8 WKU/6nrVDfg9VTftq6Q7SI/VuWzpWF2jhMaOkAeteN9EsjnPeGZlHmOdOt5pTar4VkRv fgGg== 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=W4u3teIqueKNQWsKlExofqDGIXa3PoRbTacP44eb2nA=; b=H7Z+SwPmDrzHm6Gc86J7N2gk50I+MZ+QTPJgaJh33OttUeq4ivXOgV7zeFnbeqQPUX GkbFk77r0vIw7JO+7eTWKMwOelR//5nVby5r4JWqR3+tJ9ohQ81ubaZmvbn73YW08wce 544xIgVBpjJ0hjPtXBAjC2eV5VaioeSUvxop3s4pmdukUeVBzhOzFw0yvSUraMKKktLD cYB/zDucc85bBmXBpnBPr7CLrxQ+kXNiX9wsgV5s9oVXr57F4/99+65AV1cdz4riSPDD ioSxQlhEYvJTWmKSxA6DSetHuoMZ6AUNEtn1Yrlnkycypuf0S1hSrMG715wqugbLGE4U Hc7A== X-Gm-Message-State: APjAAAVK/ivauRQTsydEc7DG/y3oEY8mb0BJKzbk/H9ZqxUgZSicNP5m 2bBS13042Fl98CN+1SDGaaHxOmD+ODxJOfzYaG4= X-Google-Smtp-Source: APXvYqztSpyza1QpPPe+3XRse0aHbNP6+ngNIM6yXgu8s94kU5FsNP2xhCD7hPk98X3kWvNlrOnhT58Hn5mdLINyVlI= X-Received: by 2002:a92:d78f:: with SMTP id d15mr2803915iln.294.1572019394707; Fri, 25 Oct 2019 09:03:14 -0700 (PDT) MIME-Version: 1.0 References: <20191015075133.38560-1-haiyue.wang@intel.com> <1682096.FjkMPolNrE@xps> <419163b4-2fe9-443c-0796-e928cdf697d6@intel.com> <1811898.7XjjD7ZjLQ@xps> In-Reply-To: <1811898.7XjjD7ZjLQ@xps> From: Jerin Jacob Date: Fri, 25 Oct 2019 21:32:58 +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 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 */ };