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 25964A00BE; Tue, 29 Oct 2019 16:59:32 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 06DF41BECD; Tue, 29 Oct 2019 16:59:32 +0100 (CET) Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) by dpdk.org (Postfix) with ESMTP id 4829E1BEC3 for ; Tue, 29 Oct 2019 16:59:30 +0100 (CET) Received: by mail-il1-f195.google.com with SMTP id n13so2097800ilt.4 for ; Tue, 29 Oct 2019 08:59:30 -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:content-transfer-encoding; bh=s/L1Ym9bfhMLsIfCPMRVnRDumoPnqNVhPGBB0z+OqrM=; b=O00ET62pQRNDCpo06YycPTFM/wsJlbl7qiXJ35n7YHjOG9zHWjF9wHge24M3Ko0nkF q24QOOY15EZxvVCXfjv0p7nwmKpl4Ue4pv/2GwCuMA7c9+rmkzFPDj9Ae5Ce0rrANSih nhQJlkA/z4yAghr9K2kvi4B/3BP5EHTqLHSUduYdkhkxN/IwONxWm0Qb5vRKHXPXgFrU ULJnDHARUcEoiszxyDumzIXl/bZLx8uXA2EZbYtFiJ7o69bB5U+S14xB42W54QkZy85q hd9y9MUwzB/L37vF6yCSmrEOzD7t1oR/QKhb5YWbZ+6aFedEeSpdFVrr0YAcNfl5QP2M qO+w== 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:content-transfer-encoding; bh=s/L1Ym9bfhMLsIfCPMRVnRDumoPnqNVhPGBB0z+OqrM=; b=H7SRV18UAw2iA3HvTvj3yZkvFS31t4NBkc0JdQcK/a76zFWAGgaLD2T/CT4P81QQeK JsI6YYHS/GxSLbsXeH5iIH+489/zCJ/wMLLeG9N8IGRWKfNr2PT/sZEyCmtoQY+UFu5i Y/TyjGNAMvAPJqeTld6T3cP73g/rQj08r2UH7V1WnyW5cwX3xyicBv8s03yVJZMkyWyI J90N9IL/O09KrTOOf0xDn59Wg4Bd9bdkEblbHan48c9k1oRugIARy22KJ4HYG/PUt4ZI NeufzSg6g5fRi1wYvFORJ8dGz9oOIUGaZ9wdhMut84hmAKmBojqE27sZOKfxDpNhzyzf 8I/A== X-Gm-Message-State: APjAAAXjVEvmRvRpLywoQn8k4SVWIUB9nGquD4rEv99YIgdDNUTumBKN Ra2WLFDsgh0ISEX0YljDqAAMIrmOJR9zROAQTMc= X-Google-Smtp-Source: APXvYqzsM4DrvWbaBrJneSAltEq+6M4nEPe5F6FFwEdg0wDoXlYZogDUXGOmIDNKCfysR6FLFaWyFHQgeOTqPp2tPXs= X-Received: by 2002:a92:ce12:: with SMTP id b18mr28999202ilo.130.1572364769272; Tue, 29 Oct 2019 08:59:29 -0700 (PDT) MIME-Version: 1.0 References: <20191015075133.38560-1-haiyue.wang@intel.com> <1811898.7XjjD7ZjLQ@xps> <12001140.UMXFOKstgs@xps> In-Reply-To: From: Jerin Jacob Date: Tue, 29 Oct 2019 21:29:13 +0530 Message-ID: To: "Wang, Haiyue" Cc: Thomas Monjalon , "Yigit, Ferruh" , dpdk-dev , "Ye, Xiaolong" , "Kinsella, Ray" , "Iremonger, Bernard" , "Sun, Chenmin" , Andrew Rybchenko , Slava Ovsiienko , Stephen Hemminger , David Marchand , Jerin Jacob Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Tue, Oct 29, 2019 at 9:12 PM Wang, Haiyue wrote: > > > -----Original Message----- > > From: Jerin Jacob > > Sent: Tuesday, October 29, 2019 22:09 > > To: Wang, Haiyue > > Cc: Thomas Monjalon ; Yigit, Ferruh ; dpdk-dev > > ; Ye, Xiaolong ; Kinsella, Ray ; > > Iremonger, Bernard ; Sun, Chenmin ; Andrew > > Rybchenko ; Slava Ovsiienko ; Stephen Hemminger > > ; David Marchand ; Jerin Jacob > > > > Subject: Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add the API for getting = burst mode information > > > > > > > > > > > > > > > > > > How about *_str_* style ? > > > > > > > > _name kind of implies it the string. may be _mode is good as it is = short. > > > > > > > > > int > > > > > rte_eth_rx_burst_mode_str_get(uint16_t port_id, uint16_t queue_id= , > > > > > char *buf, int buflen) > > > > > > > > > > About the function, keep the same is better ? Then we need no whole > > > replace, just update the parameters, and the parameters indicated tha= t > > > it is in string format. > > > > In this case, we need additional PMD op to get the buflen as > > the application will not know the buffer size in advance. It needs to c= ome > > from the driver and common code. > > > > > > See below. > > > > > > > > > We don't need buflen as it is not known to the application. The > > > > typical pattern, we followed, > > > > in dpdk is, when function called buf as NULL then the function retu= rns > > > > the expected size so that > > > > the application can alloc and get the buffer from ethdev layer on t= he > > > > next iteration. > > > > > > > > > > > > > > A little complicated and too heavy for using ? where is the example c= ode ? > > > > See rte_eth_xstats_get_names() API as example for dynamic buffer alloca= tion > > and similar use case in DPDK. > > In fact, this is no so complex as dynamic string handling. :) > > /* Get count */ > cnt_xstats =3D rte_eth_xstats_get_names(port_id, NULL, 0); > if (cnt_xstats < 0) { > printf("Error: Cannot get count of xstats\n"); > return; > } > > xstats_names =3D malloc(sizeof(struct rte_eth_xstat_name) * cnt_xstats); > > struct rte_eth_xstat_name { > char name[RTE_ETH_XSTATS_NAME_SIZE]; /**< The statistic name. */ > }; not really, it will be,[1] count =3D rte_eth_rx_burst_mode_name(port_id, queue_id, NULL); buf =3D malloc(count); count =3D rte_eth_rx_burst_mode_name(port_id, queue_id, buf); > > > Frankly speaking, after re-thinking, I prefer to keep current design. > 1) Use the structure to expose the *raw* data. Make the APIs work as > a SDK, DON'T image to format the string for user. User can call the > API to dump to file, print to console etc. Because he has the raw > data. [1] Dont have such issue. > > struct rte_eth_burst_mode { > uint64_t options; > }; > > The 'options' bit definition reflects the rx/tx source code structure rou= ghly: > > "tree drivers/net/ | grep rxtx" > =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 virtio_rxtx_simple_sse.c > =E2=94=94=E2=94=80=E2=94=80 vmxnet3_rxtx.c Files don't represent the actual mode PMD is running. So listing the file example is not correct. > > 2. add "char dev_specific[]" data as needed if a PMD wants to expose it, > enhance the APIs step by step, and do it as needed. This would change ABI for no reason and who allocates the memory for dev_specific?