From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by dpdk.org (Postfix) with ESMTP id 451FC952 for ; Mon, 6 Mar 2017 11:32:18 +0100 (CET) Received: by mail-wm0-f48.google.com with SMTP id v186so60037397wmd.0 for ; Mon, 06 Mar 2017 02:32:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=cP4w53FlGRsQBejLYjDVPNLCw4uqELC8cfkIZGD9uhs=; b=g7SwNarshbeWo7EQ5pxqdg/PsybzqqZzYii8b0TAM6AshshvlW1Z4dCvAZ2wez7xtX 9QAzoWwywydSrRV3EZVrjOxitqRFIUNnD3QbDGxrLhkWb6VZSuVA0t72kjgxiX6IjKmN p49agDR91Kw17bYUXL4dCJtx7LQ5ueW/+PhADVRkD82zidLmNes0tihpweBcr3m6AfP9 CHeLAzvOMh2Bn4p6BNwUUitUk4ljlntyA76/j/qUuiV/hfeUUzSbIQ58/ui/TVugPzVQ LSLGornzWvvesTWsK2tYaHuTTk3XjC6Ly7VeAlEQOqu7GAZY1+F6Vac3H8YoC/lloHCT X/Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=cP4w53FlGRsQBejLYjDVPNLCw4uqELC8cfkIZGD9uhs=; b=BwvLOQYMJQcgCMGPNP5/bPIGo1pwgnImrPr42FUNs7mTS/yzn9idGndm7MKKrFEnyd r7ErNgsdnIJI3IlO4sFDpGWXAX/5lATbxycMBCn9IPW4vUJ7cwCbOGlBtfRxuFMfQRgd IhVypFSKuJTRKa2BIp3x/J5bE4+TDd+qMPUhaciRAjFYxOxVC1F2ea49GThzL3g3WNW5 VlAGaqCX1Ysj1pLXt3a3Xa5HpuXLAYbjVqECbc/ujxNe2sRVuTWz0OoUlxnFN6+h9HVL JbTJqre+6Es0gwPSNbU+GL+IUv7WXS1u6wps1aTTAiUfZlTMbhfoP1oH53Jbmx697x9C bgMw== X-Gm-Message-State: AMke39nJi4ZtjmH7jp1gf3e1U/shIWg8qqfc0LUWt+hVGE08/Hb5wzL0E3Cu10xuDcVqmcyd X-Received: by 10.28.154.7 with SMTP id c7mr13416122wme.119.1488796337942; Mon, 06 Mar 2017 02:32:17 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id x18sm12945408wmd.14.2017.03.06.02.32.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 02:32:17 -0800 (PST) From: Thomas Monjalon To: Cristian Dumitrescu Cc: dev@dpdk.org, jerin.jacob@caviumnetworks.com, balasubramanian.manoharan@cavium.com, hemant.agrawal@nxp.com, shreyansh.jain@nxp.com Date: Mon, 06 Mar 2017 11:32:16 +0100 Message-ID: <2480022.hlQWxlV5d8@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <1488589820-206947-2-git-send-email-cristian.dumitrescu@intel.com> References: <1488589820-206947-1-git-send-email-cristian.dumitrescu@intel.com> <1488589820-206947-2-git-send-email-cristian.dumitrescu@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 1/2] ethdev: add capability control API 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: , X-List-Received-Date: Mon, 06 Mar 2017 10:32:18 -0000 Hi Cristian, 2017-03-04 01:10, Cristian Dumitrescu: > struct rte_flow_ops *eth_flow_ops; > int rte = rte_eth_dev_filter_ctrl(eth_port_id, > RTE_ETH_FILTER_GENERIC, RTE_ETH_FILTER_GET, ð_flow_ops); > > Unfortunately, the rte_flow opportunistically uses the rte_eth_dev_filter_ctrl() > API function, which is applicable just to RX-side filters as opposed to > introducing a mechanism that could be used by any capability in a generic way. > > This is the gap that addressed by the current patch. This mechanism is intended > to be used to introduce new capabilities into ethdev in a modular plugin-like > approach, such as hierarchical scheduler. Over time, if agreed, it can also be > used for exposing the existing Ethernet device capabilities in a modular way, > such as: xstats, filters, multicast, mirroring, tunnels, time stamping, eeprom, > bypass, etc. > > Changes in v3: > -Followed up on suggestion from Jerin: renamed capability from Hierarchical > Scheduler (sched) to Traffic Manager (tm) > > Changes in v2: > -Followed up on suggestion from Jerin and Hemant: renamed capability_control() > to capability_ops_get() > -Added ACK from Keith, Jerin and Hemant It is difficult to follow previous discussions as you do not keep threading with --in-reply-to. > Signed-off-by: Cristian Dumitrescu > Acked-by: Keith Wiles > Acked-by: Jerin Jacob > Acked-by: Hemant Agrawal [...] > +enum rte_eth_capability { > + RTE_ETH_CAPABILITY_FLOW = 0, /**< Flow */ > + RTE_ETH_CAPABILITY_TM, /**< Traffic Manager */ > + RTE_ETH_CAPABILITY_MAX > +}; [...] > /** > + * Take capability operations on an Ethernet device. > + * > + * @param port_id > + * The port identifier of the Ethernet device. > + * @param cap > + * The capability of the Ethernet device > + * @param arg > + * A pointer to arguments defined specifically for the operation. > + * @return > + * - (0) if successful. > + * - (-ENOTSUP) if hardware doesn't support. > + * - (-ENODEV) if *port_id* invalid. > + */ > +int rte_eth_dev_capability_ops_get(uint8_t port_id, > + enum rte_eth_capability cap, void *arg); What is the benefit of getting different kind of capabilities with the same function? enum + void* = ioctl A self-explanatory API should have a dedicated function for each kind of features with different argument types.