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 2316B4CE4 for ; Fri, 15 Apr 2016 12:36:13 +0200 (CEST) Received: by mail-wm0-f48.google.com with SMTP id v188so25021355wme.1 for ; Fri, 15 Apr 2016 03:36:13 -0700 (PDT) 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:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=QOEvjxKFpJoHj4K4DUKykNGBFuB8UQEpy9dchOmZhxs=; b=jOfJc9lXafYn9oGyRJTkHWqwIxygrhdXDt1bliwtWSvbumSAFeRmYIarkR8pBbXasT 2lnvOchIreUCdRSnfgrE6A17541aNv6pPV4Y0xDG67x50+vqmI8SUhzo+FGWLLgR5zFl mCcff9DNK0Dz6Ei8K2gb5klXHiNJtbzsKWdRs+zL/AhjKIdHucak2MLg65R7HJuA66/J Udxp8AufW6MUnDDifcjUxxowI/mEg6gGjQhcbCNFXLENqnqS8Vq87c1lWIeiNCPblBYb 3jKuMsnDd/GAqZmFWGiiNeMDeKUMOmMYmya9iULblDbiQQwVUhRPWGA9GGWsmZIvl9L0 Th5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding; bh=QOEvjxKFpJoHj4K4DUKykNGBFuB8UQEpy9dchOmZhxs=; b=Kp0fT3WMTBjLvmY0oeXx8m+z2JkKTvIzL9Pjp20pKP9GQquS442dE65hfYbYyjWM/t 8DIyaTJ+4oDYkZfBcw986yLbW5ns+oFw+ed2Zrtrycd07LowuF+jrRMkREROCBhVo02v oEzB3LUbwvcPuWfBYlsaWIaIjxKtNRTVOZjGkKia9v6PY6p8NeqKFKlhHHI4cYEefF0C mafs7ZLE5Yg+BUUeYd1OjpWpWtzBoZpG7Peh+Gft393BJmHWWb8HAnpL/Zt/zg8eVW67 MKoIb0pQMiWjJ3H2x0USG+yjQ4zZaQjGeqCffg0bF0C0Ec8+9shC3KmSggLnFDj6ehuO T44g== X-Gm-Message-State: AOPr4FVwHxZIhXwwk1L8gNMQdn2PgJEWqMYCRsED2DDnoYEHlCtgViy6DZCiuQyA6Mh4vkh4 X-Received: by 10.194.58.138 with SMTP id r10mr20780712wjq.153.1460716572893; Fri, 15 Apr 2016 03:36:12 -0700 (PDT) Received: from xps13.localnet (245.111.75.86.rev.sfr.net. [86.75.111.245]) by smtp.gmail.com with ESMTPSA id f186sm30763828wmf.24.2016.04.15.03.36.11 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Apr 2016 03:36:12 -0700 (PDT) From: Thomas Monjalon To: Reshma Pattan Cc: dev@dpdk.org Date: Fri, 15 Apr 2016 12:36:10 +0200 Message-ID: <2916536.igaxvufRMN@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <1460627077-8207-3-git-send-email-reshma.pattan@intel.com> References: <1460627077-8207-1-git-send-email-reshma.pattan@intel.com> <1460627077-8207-3-git-send-email-reshma.pattan@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC 2/2] librte_ether: add new fields to rte_eth_dev_info struct X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 10:36:13 -0000 2016-04-14 10:44, Reshma Pattan: > --- a/lib/librte_ether/rte_ethdev.h > +++ b/lib/librte_ether/rte_ethdev.h > @@ -908,6 +908,9 @@ struct rte_eth_dev_info { > struct rte_eth_desc_lim rx_desc_lim; /**< RX descriptors limits */ > struct rte_eth_desc_lim tx_desc_lim; /**< TX descriptors limits */ > uint32_t speed_capa; /**< Supported speeds bitmap (ETH_LINK_SPEED_). */ > + /** number of queues configured by software*/ > + uint16_t nb_rx_queues; /**< Number of RX queues. */ > + uint16_t nb_tx_queues; /**< Number of TX queues. */ > }; I think the ethdev design is strange for these structures. struct rte_eth_dev is internal to be used inside the ethdev API or by the drivers. It contains struct rte_eth_dev_data which can be of interest for the application, except the dev_private part (which could be directly in struct rte_eth_dev). So the global question is: how to share the device data with the application? Instead of giving a pointer or a copy of struct rte_eth_dev_data, we have some different accessors: - rte_eth_dev_info_get() with a specific struct rte_eth_dev_info which gathers a lot of info, not only from struct rte_eth_dev_data - rte_eth_macaddr_get() - rte_eth_dev_socket_id() - rte_eth_link_get() which is more than an accessor I think having some specialized accessors is good. But the rte_eth_dev_info_get() looks like to be a big request without precise goal and going to break ABI really often. There are some queues informations, some (not so precise) offload capabilities, some steering (RSS/VMDq) informations, the default configuration of some Intel NIC thresholds, the speed capabilities, etc. Shouldn't we try to streamline this API?