Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp869169pxf; Wed, 7 Apr 2021 13:44:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJygeszTHCrkAt31zmEDoYtYRXUBHvoQZQokg4tMCbMmRKWMJAlXLN0sdo5WOW7ITOMHvxPi X-Received: by 2002:a63:48d:: with SMTP id 135mr5048603pge.148.1617828296982; Wed, 07 Apr 2021 13:44:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617828296; cv=none; d=google.com; s=arc-20160816; b=RzmrZHvFG1KEz88QcaS9fINXxhtt5V4LwQTCNyEK7lAODQKDHJoe4D1ZV2Lw6ypweD q7gsqqvs8bkmhDiMIvTMTJnsDHWAcg06n9yAkGUYFQnehLmKzj1ZrLhxURgQmsrjgj/E T97xyyNoXjrFS1kUNaIB1ipwRl5t0/+NbGwgmWppKhiY0yZUuaGjhg3+v9TVInSy/50x /sTBTThbJTVQMPqZZQGUoEVK2hyqQ/BTpS35XIishddtccqH28Vnd7vNc0XLlxUlvX4u 39heLW70oKd2EqpSE3muBeQQjgR69joR+yY6nz3rOMic2b1Wabv30xyAK5h92OBmdqpE c/Eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=3Z8gi1QvlVFYGnch69WV1pVSvYVCJ02NknZ2nEG+dc4=; b=TFOVtDGz0pbQXuCBe+DIZXoctkvMsPVmwJUsNC/K+OHTzYl0LZzg9wbaQPfz1TaYZE r2Lp+42HuPkJvQseqH8gzv3Kg+fc6tzO9y8u7Ei1xhPRRTlTdAyr1hMRlRApFm9/vOZl 8w9TBIKl18rUg0WGEgWBAgqQXTnK/Qzz1+QcJLivzktxgxE6rXhkWfxcUFyqTGgArfKS uM+DZn/0REGAQHBqq0UXstqG9Cd3VdL/MskQQYPDTv02k0D7p94ocFfi+yzeROPoftiO zNKhW9+5NCcIQDAGewm6wxa0jesxUAApuSMT7Am5cMBzaL7bCk04Ls3iYGmTCc1byJiA Sj9w== 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=hisilicon.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z11si3162187pjr.155.2021.04.07.13.44.44; Wed, 07 Apr 2021 13:44:56 -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=hisilicon.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350471AbhDGKEE (ORCPT + 99 others); Wed, 7 Apr 2021 06:04:04 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:16379 "EHLO szxga06-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350489AbhDGKD3 (ORCPT ); Wed, 7 Apr 2021 06:03:29 -0400 Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4FFg0C2Z4ZzjYZn; Wed, 7 Apr 2021 18:01:31 +0800 (CST) Received: from [127.0.0.1] (10.69.38.196) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.498.0; Wed, 7 Apr 2021 18:03:11 +0800 Subject: Re: [PATCH 0/4] Add support for HiSilicon PCIe Tune and Trace device To: Greg KH CC: , , , , , , , , , , "liuqi (BA)" References: <1617713154-35533-1-git-send-email-yangyicong@hisilicon.com> From: Yicong Yang Message-ID: <01b6e8f7-3282-514e-818d-0e768dcc5ba3@hisilicon.com> Date: Wed, 7 Apr 2021 18:03:11 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.69.38.196] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/4/6 21:49, Greg KH wrote: > On Tue, Apr 06, 2021 at 08:45:50PM +0800, Yicong Yang wrote: >> HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex >> integrated Endpoint(RCiEP) device, providing the capability >> to dynamically monitor and tune the PCIe traffic(tune), >> and trace the TLP headers(trace). The driver exposes the user >> interface through debugfs, so no need for extra user space tools. >> The usage is described in the document. > > Why use debugfs and not the existing perf tools for debugging? > The perf doesn't match our device as we've analyzed. For the tune function it doesn't do the sampling at all. User specifys one link parameter and reads its current value or set the desired one. The process is static. We didn't find a way to adapt to perf. For the trace function, we may barely adapt to the perf framework but it doesn't seems like a better choice. We have our own format of data and don't need perf doing the parsing, and we'll get extra information added by perf as well. The settings through perf tools won't satisfy our needs, we cannot present available settings (filter BDF number, TLP types, buffer controls) to the user and user cannot set in a friendly way. For example, we cannot count on perf to decode the usual format BDF number like ::., which user can use filter the TLP headers. So we intended to make the operation of this driver a bit like ftrace. user sets the control settings through control files and get the result through files as well. No additional tools is necessay. A user space tool is necessary if we use a character device or misc device for implementing this. The trace data maybe hundreds of megabytes, and debugfs file can just satisfy it. Thanks, Yicong