Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp3543862pxv; Mon, 28 Jun 2021 07:04:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxnXiMnSFuAqjucp9QOOIYlRqjTS2/fRxg++WkY+KdCHAyH89shvMNdS/LHwYSICzvkJhwR X-Received: by 2002:a5d:8584:: with SMTP id f4mr20894957ioj.59.1624889071867; Mon, 28 Jun 2021 07:04:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624889071; cv=none; d=google.com; s=arc-20160816; b=BNLIgFi0fgPT+2lhBIce3ZaDDq1WFdcWE0bvdaooGzMnDklIevG7Rq00Xlb4TvZGR3 6GOFvxvIgAb9FgrQb0RHjB/lkj3NlHw4X2ANbe2itbvLsoVojOQuSc6DN78IP4jaxGfj X6k9DeTOL+l09cp6LgPBhV++Wl8khOrYuk3/H6l/MSfSjxecC17KRtXGPv6rIhAdkMON 0yfYbkfGSxA3eaSlSScBoF52HPwm9b9gmEPxbwynuMhIPEoH9gvmdOPEVrqRfhiEPSnz YK6dSN5SipTq9CrgTqsM9Bec9vApmFTHTZ+8N6rPMv88z/xTPrccMFPRh9xWMY9vWq/O gOOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=pyVxKwXotP/ijr0X2KAUdv7J4MtUCuINpvv5mbhqzhY=; b=Ll30iv4BdIB18TpS58sPtUSVQZ/OSTIWt13SLDaZ84E+MYB0DXjeugfHPCKmtoBEwO sJheYDHfGdiLPWklnczgNoov79t38jOQp9LRqL6YVCtITQW1Bl4yVqn989j4J1sx+Owc LU3zROonH5zIgJ0BebwfVrSIRcQIPkygh1I5vbhLm8ZSSMLS2gTlsFs32FJgwJ5SVyHJ efstEITm67U/XxSGYyLm2fOyrgn6CzMLRlQ5C3Bxd4j7C8cHaMlAhMolhyN/9lGZgMbG ADPl1XZ4XmgR9u+PCfzsW/kwzikPiiZlLN3CzlAje06rv0Az6JXBbpYqGgJ9UgTLunY0 JbRA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j25si17443360jaj.93.2021.06.28.07.04.18; Mon, 28 Jun 2021 07:04:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233116AbhF1NUO (ORCPT + 99 others); Mon, 28 Jun 2021 09:20:14 -0400 Received: from szxga08-in.huawei.com ([45.249.212.255]:9286 "EHLO szxga08-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232941AbhF1NUK (ORCPT ); Mon, 28 Jun 2021 09:20:10 -0400 Received: from dggemv704-chm.china.huawei.com (unknown [172.30.72.56]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4GD7Lf074Yz1BSm5; Mon, 28 Jun 2021 21:12:26 +0800 (CST) Received: from dggema757-chm.china.huawei.com (10.1.198.199) by dggemv704-chm.china.huawei.com (10.3.19.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Mon, 28 Jun 2021 21:17:43 +0800 Received: from [127.0.0.1] (10.69.38.203) by dggema757-chm.china.huawei.com (10.1.198.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Mon, 28 Jun 2021 21:17:42 +0800 Subject: Re: [PATCH v7 2/2] drivers/perf: hisi: Add driver for HiSilicon PCIe PMU To: John Garry , Linuxarm , "will@kernel.org" , "mark.rutland@arm.com" , "bhelgaas@google.com" CC: "linux-pci@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Zhangshaokun References: <1624532384-43002-1-git-send-email-liuqi115@huawei.com> <1624532384-43002-3-git-send-email-liuqi115@huawei.com> <485dcb90-01bc-766a-466a-f32563e2076f@huawei.com> <95de93f7-1618-5aa6-9a23-6445c5cb3515@huawei.com> <1b164e4b-b30b-f071-51fa-841cc76ec017@huawei.com> <403d09f8-6fe8-c04c-151b-40816c344b55@huawei.com> From: "liuqi (BA)" Message-ID: Date: Mon, 28 Jun 2021 21:17:41 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Originating-IP: [10.69.38.203] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggema757-chm.china.huawei.com (10.1.198.199) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/6/28 20:11, John Garry wrote: > On 28/06/2021 11:49, liuqi (BA) wrote: >>>> Hardware counter and ext_counter work together for bandwidth, latency, >>>> bus utilization and buffer occupancy events. For example, for latency >>>> events(idx = 0x10), counter counts total delay cycles and ext_counter >>>> counts PCIe packets number. >>>> >>>> As we don't want PMU driver to process these two data, "delay cycles" >>>> can be treated as an event(id = 0x10), "packets number" as another >>>> event >>>> (id = 0x10 << 8), and driver could export these data separately. >>>> >>>> if the user want to calculate latency of rx memory read, they should: >>>> ./perf stat -v -e '{hisi_pcieX/event=0x10, >>>> subevent=0x01/,hisi_pcieX/event=0x0400, subevent=0x01/ >>>> >>>> and for bandwidth event: >>>> ./perf stat -v -e '{hisi_pcieX/event=0x4, >>>> subevent=0x02/,hisi_pcieX/event=0x1000, subevent=0x02/ >> Hi John, >>> I would suggest supporting a perf metric for this then, which would be >>> like: >>> >>> { >>>      "BriefDescription": "Latency for inbound traffic...", >>>      "MetricName": "hisi_pcie_lat_rx_mrd", >>>      "MetricExpr": "hisi_pcieX@event\\=0x4@subevent\\=0x02 \ >>> hisi_pcieX@event\\=0x1000@subevent\\=0x02 \", >>>      "Unit": "hisi_pci", >>>      "Compat": "v1" >>> }, >>> >>> (syntax may be incorrect - illustration only) >>> >> yes, we could add these metrics in json file, thanks. > > The syntax is actually like: >    "MetricExpr": "hisi_pcieX@event\\=0x4\\,subevent\\=0x2@ / > hisi_pcieX@event\\=0x1000\\,subevent\\=0x2@", > >>>> Then the value in HISI_PCIE_CNT and HISI_PCIE_EXT_CNT returned >>>> separately, and userspace could do the calculation. >>> But I am still curious about lat_rx_mrd and the other events which we >>> continue to advertise. They don't really provide latency or bandwidth on >>> their own, but only half the necessary data. So I doubt their purpose. >>> >> So how about changing the event name to show the real purpose of this >> event, like changing "bw_rx_mrd" to "flux_rx_mrd", and changing >> "lat_rx_mrd" to "delay_rx_mrd"? > > eh, I suppose you could, but I am not sure of the value. However > assume that the driver will detect and reject invalid or nonsense > combinations of events if you did want this. > Hi John, As content in two counters are registered as two independent different events, these events perhaps should be selected without limitation (Although it make sense only when using in combination). So perhaps we don't need to do this rejection if user only get the value in HISI_PCIE_CNT or only get HISI_PCIE_EXT_CNT. Thanks, Qi > Thanks, > John > .