All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Shuai Xue <xueshuai@linux.alibaba.com>
Cc: chengyou@linux.alibaba.com, kaishen@linux.alibaba.com,
	yangyicong@huawei.com, will@kernel.org,
	Jonathan.Cameron@huawei.com, baolin.wang@linux.alibaba.com,
	robin.murphy@arm.com, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
	rdunlap@infradead.org, mark.rutland@arm.com,
	zhuo.song@linux.alibaba.com, renyu.zj@linux.alibaba.com
Subject: Re: [PATCH v7 3/4] drivers/perf: add DesignWare PCIe PMU driver
Date: Fri, 13 Oct 2023 11:30:25 -0500	[thread overview]
Message-ID: <20231013163025.GA1116248@bhelgaas> (raw)
In-Reply-To: <a2265967-5088-7f17-35e5-29bf1c85c15f@linux.alibaba.com>

On Fri, Oct 13, 2023 at 11:46:44AM +0800, Shuai Xue wrote:
> 
> 
> On 2023/10/13 00:25, Bjorn Helgaas wrote:
> > On Thu, Oct 12, 2023 at 11:28:55AM +0800, Shuai Xue wrote:
> >> This commit adds the PCIe Performance Monitoring Unit (PMU) driver support
> >> for T-Head Yitian SoC chip. Yitian is based on the Synopsys PCI Express
> >> Core controller IP which provides statistics feature. The PMU is not a PCIe
> >> Root Complex integrated End Point(RCiEP) device but only register counters
> >> provided by each PCIe Root Port.

IIUC, the PMU is directly integrated into the Root Port: it's
discovered and operated via the Root Port config space.  If so, I
wouldn't bother mentioning RCiEP because there's no need to list all
the things it's *not*.

> >> To facilitate collection of statistics the controller provides the
> >> following two features for each Root Port:
> >>
> >> - Time Based Analysis (RX/TX data throughput and time spent in each
> >>   low-power LTSSM state)
> >> - Event counters (Error and Non-Error for lanes)
> >>
> >> Note, only one counter for each type and does not overflow interrupt.
> > 
> > Not sure what "does not overflow interrupt" means.  Does it mean
> > there's no interrupt generated when the counter overflows?
> 
> Yes, exactly. The rootport does NOT generate interrupt when the
> couter overflows.  I think the assumption hidden in this design is
> 64-bit counter will not overflow within observable time.
> 
> PCIe 5.0 slots can now reach anywhere between ~4GB/sec for a x1 slot
> up to ~64GB/sec for a x16 slot. The unit of counter is 16 byte.
> 
> 	2^64/(64/16*10^9)/60/60/24/365=146 years
> 
> so, the counter will not overflow within 146 years.

Certainly a reasonable assumption :)

But I'm confused about how many counters there are.  Clearly there are
two features ((1) time-based analysis and (2) event counters).

"One counter for each type" suggests there's one counter for
time-based analysis and a second counter for event counting, but from
dwc_pcie_pmu_event_add(), it looks like each Root Port might have a
single counter, and you can decide whether that counter is used for
time-based analysis or event counting, but you can't do both at the
same time?  And the event counting is for a single lane, not for the
link as a whole?

If so, I might word this as:

  Each Root Port contains one counter that can be used for either:

    - Time-Based Analysis (RX/TX data throughput and time spent in
      each low-power LTSSM state) or

    - Event counting (error and non-error events for a specified lane)

  There is no interrupt for counter overflow.

> >> +	  Enable perf support for Synopsys DesignWare PCIe PMU Performance
> >> +	  monitoring event on platform including the Yitian 710.
> > 
> > Should this mention Alibaba or T-Head?  I don't know how
> > Alibaba/T-Head/Yitian are all related.
> 
> The server chips, named Yitian 710, are custom-built by Alibaba Group's chip
> development business, T-Head.
> 
> 	  Enable perf support for Synopsys DesignWare PCIe PMU Performance
> 	  monitoring event on platform including the Alibaba Yitian 710.
> 
> Is this okay?

Perfect :)

Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Shuai Xue <xueshuai@linux.alibaba.com>
Cc: chengyou@linux.alibaba.com, kaishen@linux.alibaba.com,
	yangyicong@huawei.com, will@kernel.org,
	Jonathan.Cameron@huawei.com, baolin.wang@linux.alibaba.com,
	robin.murphy@arm.com, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
	rdunlap@infradead.org, mark.rutland@arm.com,
	zhuo.song@linux.alibaba.com, renyu.zj@linux.alibaba.com
Subject: Re: [PATCH v7 3/4] drivers/perf: add DesignWare PCIe PMU driver
Date: Fri, 13 Oct 2023 11:30:25 -0500	[thread overview]
Message-ID: <20231013163025.GA1116248@bhelgaas> (raw)
In-Reply-To: <a2265967-5088-7f17-35e5-29bf1c85c15f@linux.alibaba.com>

On Fri, Oct 13, 2023 at 11:46:44AM +0800, Shuai Xue wrote:
> 
> 
> On 2023/10/13 00:25, Bjorn Helgaas wrote:
> > On Thu, Oct 12, 2023 at 11:28:55AM +0800, Shuai Xue wrote:
> >> This commit adds the PCIe Performance Monitoring Unit (PMU) driver support
> >> for T-Head Yitian SoC chip. Yitian is based on the Synopsys PCI Express
> >> Core controller IP which provides statistics feature. The PMU is not a PCIe
> >> Root Complex integrated End Point(RCiEP) device but only register counters
> >> provided by each PCIe Root Port.

IIUC, the PMU is directly integrated into the Root Port: it's
discovered and operated via the Root Port config space.  If so, I
wouldn't bother mentioning RCiEP because there's no need to list all
the things it's *not*.

> >> To facilitate collection of statistics the controller provides the
> >> following two features for each Root Port:
> >>
> >> - Time Based Analysis (RX/TX data throughput and time spent in each
> >>   low-power LTSSM state)
> >> - Event counters (Error and Non-Error for lanes)
> >>
> >> Note, only one counter for each type and does not overflow interrupt.
> > 
> > Not sure what "does not overflow interrupt" means.  Does it mean
> > there's no interrupt generated when the counter overflows?
> 
> Yes, exactly. The rootport does NOT generate interrupt when the
> couter overflows.  I think the assumption hidden in this design is
> 64-bit counter will not overflow within observable time.
> 
> PCIe 5.0 slots can now reach anywhere between ~4GB/sec for a x1 slot
> up to ~64GB/sec for a x16 slot. The unit of counter is 16 byte.
> 
> 	2^64/(64/16*10^9)/60/60/24/365=146 years
> 
> so, the counter will not overflow within 146 years.

Certainly a reasonable assumption :)

But I'm confused about how many counters there are.  Clearly there are
two features ((1) time-based analysis and (2) event counters).

"One counter for each type" suggests there's one counter for
time-based analysis and a second counter for event counting, but from
dwc_pcie_pmu_event_add(), it looks like each Root Port might have a
single counter, and you can decide whether that counter is used for
time-based analysis or event counting, but you can't do both at the
same time?  And the event counting is for a single lane, not for the
link as a whole?

If so, I might word this as:

  Each Root Port contains one counter that can be used for either:

    - Time-Based Analysis (RX/TX data throughput and time spent in
      each low-power LTSSM state) or

    - Event counting (error and non-error events for a specified lane)

  There is no interrupt for counter overflow.

> >> +	  Enable perf support for Synopsys DesignWare PCIe PMU Performance
> >> +	  monitoring event on platform including the Yitian 710.
> > 
> > Should this mention Alibaba or T-Head?  I don't know how
> > Alibaba/T-Head/Yitian are all related.
> 
> The server chips, named Yitian 710, are custom-built by Alibaba Group's chip
> development business, T-Head.
> 
> 	  Enable perf support for Synopsys DesignWare PCIe PMU Performance
> 	  monitoring event on platform including the Alibaba Yitian 710.
> 
> Is this okay?

Perfect :)

Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2023-10-13 16:31 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-12  3:28 [PATCH v7 0/4] drivers/perf: add Synopsys DesignWare PCIe PMU driver support Shuai Xue
2023-10-12  3:28 ` Shuai Xue
2023-10-12  3:28 ` [PATCH v7 1/4] docs: perf: Add description for Synopsys DesignWare PCIe PMU driver Shuai Xue
2023-10-12  3:28   ` Shuai Xue
2023-10-12  3:28 ` [PATCH v7 2/4] PCI: Add Alibaba Vendor ID to linux/pci_ids.h Shuai Xue
2023-10-12  3:28   ` Shuai Xue
2023-10-12 14:59   ` Bjorn Helgaas
2023-10-12 14:59     ` Bjorn Helgaas
2023-10-12 15:27     ` Bjorn Helgaas
2023-10-12 15:27       ` Bjorn Helgaas
2023-10-13  1:07       ` Shuai Xue
2023-10-13  1:07         ` Shuai Xue
2023-10-12  3:28 ` [PATCH v7 3/4] drivers/perf: add DesignWare PCIe PMU driver Shuai Xue
2023-10-12  3:28   ` Shuai Xue
2023-10-12 16:25   ` Bjorn Helgaas
2023-10-12 16:25     ` Bjorn Helgaas
2023-10-13  3:46     ` Shuai Xue
2023-10-13  3:46       ` Shuai Xue
2023-10-13  8:41       ` Jonathan Cameron
2023-10-13  8:41         ` Jonathan Cameron
2023-10-13 10:45         ` Shuai Xue
2023-10-13 10:45           ` Shuai Xue
2023-10-13 16:30       ` Bjorn Helgaas [this message]
2023-10-13 16:30         ` Bjorn Helgaas
2023-10-16  3:00         ` Shuai Xue
2023-10-16  3:00           ` Shuai Xue
2023-10-16 14:38           ` Bjorn Helgaas
2023-10-16 14:38             ` Bjorn Helgaas
2023-10-17  0:48             ` Shuai Xue
2023-10-17  0:48               ` Shuai Xue
2023-10-12  3:28 ` [PATCH v7 4/4] MAINTAINERS: add maintainers for " Shuai Xue
2023-10-12  3:28   ` Shuai Xue

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231013163025.GA1116248@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=chengyou@linux.alibaba.com \
    --cc=kaishen@linux.alibaba.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=rdunlap@infradead.org \
    --cc=renyu.zj@linux.alibaba.com \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    --cc=xueshuai@linux.alibaba.com \
    --cc=yangyicong@huawei.com \
    --cc=zhuo.song@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.