From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by dpdk.org (Postfix) with ESMTP id 0840212A8 for ; Thu, 24 Nov 2016 17:59:08 +0100 (CET) Received: by mail-wm0-f44.google.com with SMTP id f82so67882557wmf.1 for ; Thu, 24 Nov 2016 08:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=R0PARLNwPkmSOlEAw0XFoMfgnHujEyJSwv2ONKYvXc4=; b=Ntrn7EEy3BNC/EysiZXgZF9Z5LH5Djioi3sfFKPQTLzlaA4WUYF9kpWH71e0nfNwBr 9R6I9JWwkwVIJj6SGgoadGWw2JrlNLeY9lznnoa5RGYFUyRxT22VszeGvc7BrZKgQbY2 QNMxValX2rSHSzNr9uD6m0IpF7fv/dDXZV+gHDIU9YYx5nW6xMvWQeSroSae9I3ltg3h ddyYdyPmwGwamZFV/JFpVl0Ao5WXwhwkbyUyHRpY+o1O1mQkR+fRB6p80fax34kIoJR3 /2se7/LHMe7JuZkjXIcwChjc9pz36DZTfC4parZZCnA9NFkY9rmO8yzBBGGlS5y+gd54 vDEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=R0PARLNwPkmSOlEAw0XFoMfgnHujEyJSwv2ONKYvXc4=; b=T4Gkocc+OVZnSITv11JR+DuZCtgH3qUBrwfN+LPedwlr5QxOyaeCOFAXDum6l6j/W3 JMl8yuzP+MlmmDTXJtJCsJXK4pfblClymjRuZjyNQSOPZyxVBgqRBuP+puZGAXrOQDFc ze/jbwExDf2xeR+rIbjA3RyzsrgL/g0aCvH4K1P/QN6yWgjCtdaJugE/WkLTHwWmQytX cOlQ+2DVKa1yRMBCaD1V7crx6f1GK1VdBeVaZOIIVZdd1stnDcpNCU7FW566Dis8D4nB JkAOXr92s3POgX3FhOmhdl1DaN0vrX9nRDGHMpSE0NiuSf7DJXtL5zK6ihChBbEYxgdH fzcA== X-Gm-Message-State: AKaTC02s9fID19L48bG6SlSxl8pCsfExcQcSE7695RwHspywbmD45F43IxilTB5lm542EQNW X-Received: by 10.28.165.131 with SMTP id o125mr3206246wme.9.1480006748648; Thu, 24 Nov 2016 08:59:08 -0800 (PST) Received: from 2a01cb0c08e311000226b0fffeed02fc.ipv6.abo.wanadoo.fr (2a01cb0c08e311000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:8e3:1100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id m145sm9119470wma.3.2016.11.24.08.59.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 24 Nov 2016 08:59:07 -0800 (PST) Message-ID: <1480006746.31853.14.camel@6wind.com> From: Olivier Matz To: Alejandro Lucero , dev@dpdk.org Cc: Bert van Leeuwen , thomas.monjalon@6wind.com Date: Thu, 24 Nov 2016 17:59:06 +0100 In-Reply-To: <1479722378-23959-1-git-send-email-alejandro.lucero@netronome.com> References: <1479722378-23959-1-git-send-email-alejandro.lucero@netronome.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.2-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v2] ethdev: check number of queues less than RTE_ETHDEV_QUEUE_STAT_CNTRS 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: Thu, 24 Nov 2016 16:59:09 -0000 Hi, On Mon, 2016-11-21 at 09:59 +0000, Alejandro Lucero wrote: > From: Bert van Leeuwen > > Arrays inside rte_eth_stats have size=RTE_ETHDEV_QUEUE_STAT_CNTRS. > Some devices report more queues than that and this code blindly uses > the reported number of queues by the device to fill those arrays up. > This patch fixes the problem using MIN between the reported number of > queues and RTE_ETHDEV_QUEUE_STAT_CNTRS. > > Signed-off-by: Alejandro Lucero > Reviewed-by: Olivier Matz As a next step, I'm wondering if it would be possible to remove this limitation. We could replace the tables in struct rte_eth_stats by a pointer to an array allocated dynamically at pmd setup. It would break the API, so it should be announced first. I'm thinking of something like: struct rte_eth_generic_stats {         uint64_t ipackets;         uint64_t opackets;         uint64_t ibytes;         uint64_t obytes;         uint64_t imissed;         uint64_t ierrors;         uint64_t oerrors;         uint64_t rx_nombuf }; struct rte_eth_stats { struct rte_eth_generic_stats port_stats; struct rte_eth_generic_stats *queue_stats; }; The queue_stats array would always be indexed by queue_id. The xstats would continue to report the generic stats per-port and per-queue. About the mapping API, either we keep it as-is, or it could become a driver-specific API. Thomas, what do you think? Regards, Olivier