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 AA3EFA00BE; Tue, 29 Oct 2019 04:38:01 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7E9571BED7; Tue, 29 Oct 2019 04:38:01 +0100 (CET) Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) by dpdk.org (Postfix) with ESMTP id 7DB711BECB for ; Tue, 29 Oct 2019 04:38:00 +0100 (CET) Received: by mail-io1-f68.google.com with SMTP id c11so13177270iom.10 for ; Mon, 28 Oct 2019 20:38:00 -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=DGN9M+ueuvMTXp24nmuUvP19H+VhtHOLWdghg21gRwY=; b=ob8kVo5eYCFWV12asaGMcezzpLJtpwXAYgWzVTvaXpMuwhBukY3BDkBGZV0uD/ExSO BdRlefP6r6ZEAR+Ju5lCJ9mx8yO8gf1O1CCgC1qH8Eh9oBFtUuoKY4D5KHY1Do3NPb1E t9nYvUEEV3j4rqOQ3bC0/C60Yj0hmmwIgZJSbdtpgg6mEqO2LdUxfzfyIONGG471cbcO kJhCLmiMtGEqRBk/LpUp0g+G1x0rsw3Gwghf+khsMER1lHY3TMge9WMKjT1bZf6zl/sR Tpbpwsif92K+N44whZd6Gy7oen0zuTV+plcgYVpUB5GfPdqZj7IRS3jEeB5cW/PPVzg/ fnVw== 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=DGN9M+ueuvMTXp24nmuUvP19H+VhtHOLWdghg21gRwY=; b=HJHBVXxj1OFstFHEQF0KVEmWVG++SbTe8B6J80FX1YLUSdFVhwIjjTOLRJxKXXzf7b 8wZEhO6BOlRvqMMh8oSaaER4WjUef9Zt+mi658J5l0tToQZzHRePxNKiNUJ3PEo96aZl 443aKp/zHxjz5lgsWGAoq7gczp7utUU1bI5LoLm0dPMx5xTYnSfeCVo/projFnf6BErl UJ6rGfWWivbs96RZ37X+GloFGx8rfC+Lk/AFYKo+TADDXkWJPjCYQJrUbU2z+2XFzZ5M bAoKQAuoBJPP2PJgax/n5HsW+uBeCc+3bTJLjLvecIbcjaMk/1lOh3vwZ/aqCXC1DGPR /JDw== X-Gm-Message-State: APjAAAXupDeIrDuNqk9PEQbonlprnPfx7bPn8XKCOkhU5/b2Z5EI6kt5 Ko5dlk6zdElV86SFKiRmYKC0rS9jYVNsuA9jsoI= X-Google-Smtp-Source: APXvYqyzBm8hJgbt0gmbxDVHi7MFkEC0gk9KpoiUZ4J8PV7+T9nAv2cUKkafqgCtTBV3ELKHc2CIXYgynenWidSbG6M= X-Received: by 2002:a6b:c701:: with SMTP id x1mr1470687iof.162.1572320279697; Mon, 28 Oct 2019 20:37:59 -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 09:07:43 +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" 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" > > > > 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. > > > > In fact, 'rte_eth_burst_mode_option_name' for single option, not > for struct eth_pmd_burst_mode::option[s]. Need loop to display them. I see two issues with the flag approach in public API(Internally for common code it fine to avoid code duplication) 1) We can not standardize all flags when it comes to HW specific details. We should NOT pollute public API with HW specific details. 2) There is a danger if application starts taking any action based on flags. It should be only for display purpose so in that case public API should be the string to avoid misuse of the API(eventually the app will fail on some PMD if it takes any action based on the flag)