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 614002B8C for ; Fri, 11 Nov 2016 10:48:20 +0100 (CET) Received: by mail-wm0-f44.google.com with SMTP id a197so415763876wmd.0 for ; Fri, 11 Nov 2016 01:48:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WuF0L/TN05vqwsU4uvZ2yM7972u4iP9bVejB21JXHQo=; b=WFc0p9x1S15fVzjWQYjycnFmdGssGPK+COAFjdcxTdN37IXZryPHYHH+AJa2vhc3XX 0/nH0Zf9Mk68OZuRrJafs+5FF1tZFidTSnqTOljtoKlmH6jiraAx6bnRjXO1PowT3f+m r8QwbS0cm+BufZDjt7tRdJH0XuZgeoKbV0RdhaUajNFXbdwMNvDKY9xGdywz36UpRo8/ NtOoc/YSFhbEbDffq6nejXMm+kOQSXH9AEw6Jw/jRCdTjdY+XzgzV7FwAAUprd9dybWd JETQgjsnNVxBvXM/n1Km0Yopbvzz4mEUoAhxyjWJttZWh2TvfiPax/MbrsZ0+GtLJ7hS /TYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WuF0L/TN05vqwsU4uvZ2yM7972u4iP9bVejB21JXHQo=; b=NUKKN7L2Ck8R0PdaruoPv1wcvGVbKUIezF+0CVptIsBB3eBNvE8sOSkeqnoLrgktvW Oj+Dkz5i7iFxEJO5vzDOgLzHe1MYAVG+yJolb8bJq+2IU6Wholgf84vXAnEu2IgXnrUh 95vSkymNvivqj01qosqZ8vzxNk09jWmp7Kqjhv55soPz4WkhtYqvGXvR+xIXSaRNpA8I lN7lP6KZlL0TbL/1tPxYoGJxjWfQiSJ5KaanLIxTRdYkG+JJhcprtouQKHWdmNTGJCtK /xbSPEB5nd2Ntcs8YR6ihwA6Kb8X0UPZvKzRuhSX2Qi4KKIPpKnsnRurPcAHwGy/tI8j NyJg== X-Gm-Message-State: ABUngvcDJ+blk8kNxtLp6bgLE3Yy1YpTOx1/Av4r5ukes/mwxlxNTlLWgJaIBi9nyJCqkUf+ X-Received: by 10.28.54.97 with SMTP id d94mr10148249wma.28.1478857700074; Fri, 11 Nov 2016 01:48:20 -0800 (PST) Received: from [192.168.0.102] (169-0-200-241.ip.afrihost.co.za. [169.0.200.241]) by smtp.gmail.com with ESMTPSA id o62sm17899856wmg.12.2016.11.11.01.48.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 11 Nov 2016 01:48:19 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Bert van Leeuwen In-Reply-To: <1630834.YGmmObtqnA@xps13> Date: Fri, 11 Nov 2016 11:48:15 +0200 Cc: Alejandro Lucero , dev@dpdk.org Content-Transfer-Encoding: quoted-printable Message-Id: <4D79411C-0FB4-45DF-9CDB-06570DDB2818@netronome.com> References: <1478786449-44745-1-git-send-email-alejandro.lucero@netronome.com> <1630834.YGmmObtqnA@xps13> To: Thomas Monjalon X-Mailer: Apple Mail (2.3124) Subject: Re: [dpdk-dev] [PATCH] 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: Fri, 11 Nov 2016 09:48:20 -0000 > On 11 Nov 2016, at 11:29 AM, Thomas Monjalon = wrote: >=20 > 2016-11-11 09:16, Alejandro Lucero: >> Thomas, >>=20 >> We are wondering if you realize this patch fixes a bug with current = ethdev >> code as a device can have more than RTE_ETHDEV_QUEUE_STAT_CNTRS. >>=20 >> Maybe the commit message is giving the wrong impression and as you >> commented, it should just focus on the bug it fixes and to leave for >> another email thread the discussion of how to solve the >> RTE_ETHDEV_QUEUE_STAT_CNTRS >> problem. >>=20 >> Should we remove this from patchwork and to send another patch that = way? >=20 > Yes please. It was my first comment, we don't understand the exact = issue > you are fixing. In a nutshell, the rte_eth_xstats_get function was reading memory beyond = what was stored in the internal arrays (and thus returning junk values). = The patch simply prevents it from going out of bounds, it does not = address the issue that the rest of the counters are lost though. This = issue is not specific to our device, in fact we found it while using a = multiqueue virtio device (32 queues), and traced the issue into this = core ethdev functionality. > And I have a bad feeling it could break something else (really just a = feeling). > It is not the kind of patch we can apply the last day of a release. > That's why I think it should wait 17.02. >=20 > Of course you can try to convince me and others to apply it as a last = minute > patch. But why are you sending a patch on the generic API in the last = days? >=20 > Last argument: it is not fixing a regression of 16.11, so it is not so = urgent. Yes, it looks like this bug was present in DPDK 2.2 even, and possibly = before that too.=