mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: hejunhao <hejunhao3@huawei.com>
To: Yicong Yang <yangyicong@huawei.com>,
	Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: <yangyicong@hisilicon.com>, <will@kernel.org>,
	<mark.rutland@arm.com>, <linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <linuxarm@huawei.com>,
	<prime.zeng@hisilicon.com>, <fanghao11@huawei.com>
Subject: Re: Re: [PATCH 4/7] drivers/perf: hisi_pcie: Check the target filter properly
Date: Thu, 22 Feb 2024 09:21:39 +0800	[thread overview]
Message-ID: <0ab7dae0-e132-2b8a-5a6c-1e517c92aa01@huawei.com> (raw)
In-Reply-To: <03acfe6b-bcde-8a11-ea6d-add1998d5bd1@huawei.com>


On 2024/2/21 17:46, Yicong Yang wrote:
> On 2024/2/8 20:29, Jonathan Cameron wrote:
>> On Sun, 4 Feb 2024 15:45:24 +0800
>> Yicong Yang <yangyicong@huawei.com> wrote:
>>
>>> From: Junhao He <hejunhao3@huawei.com>
>>>
>>> The PMU can monitor traffic of certain target Root Port or downstream
>>> target Endpoint. User can specify the target filter by the "port" or
>>> "bdf" option respectively. The PMU can only monitor the Root Port or
>>> Endpoint on the same PCIe core so the value of "port" or "bdf" should
>>> be valid and will be checked by the driver.
>>>
>>> Currently at least and only one of "port" and "bdf" option must be set.
>>> If "port" filter is not set or is set explicitly to zero (default),
>>> driver will regard the user specifies a "bdf" option since "port" option
>>> is a bitmask of the target Root Ports and zero is not a valid
>>> value.
>>>
>>> If user not explicitly set "port" or "bdf" filter, the driver uses "bdf"
>>> default value (zero) to set target filter, but driver will skip the
>>> check of bdf=0, although it's a valid value (meaning 0000:000:00.0).
>>> Then the user just gets zero.
>>>
>>> Therefore, we need to check if both "port" and "bdf" are invalid, then
>>> return failure and report warning.
>>>
>>> Testing:
>>> before the patch:
>>>                     0      hisi_pcie0_core1/rx_mrd_flux/
>>>                     0      hisi_pcie0_core1/rx_mrd_flux,port=0/
>>>                24,124      hisi_pcie0_core1/rx_mrd_flux,port=1/
>>>                     0      hisi_pcie0_core1/rx_mrd_flux,bdf=0/
>>>       <not supported>      hisi_pcie0_core1/rx_mrd_flux,bdf=1/
>> Nice to include an example that works for bdf
>> 			    hisi_pcie0_core1/rx_mrd_flux,bdf=1,port=0
>> or something like that?
>>> after the patch:
>>>       <not supported>      hisi_pcie0_core1/rx_mrd_flux/
>>>       <not supported>      hisi_pcie0_core1/rx_mrd_flux,port=0/
>>>                24,153      hisi_pcie0_core1/rx_mrd_flux,port=1/
>>>       <not supported>      hisi_pcie0_core1/rx_mrd_flux,bdf=0/
>>>       <not supported>      hisi_pcie0_core1/rx_mrd_flux,bdf=1/
>>>
>>> Signed-off-by: Junhao He <hejunhao3@huawei.com>
>>> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
>> Clearly the current situation is wrong, but perhaps we can
>> have a more intuitive scheme (could be added as a follow up patch)
>> and have the driver figure out which port the bdf lies below?
>>
>> Maybe that's a job for userspace tooling rather than the driver, but
>> the driver already has verification code and it wouldn't be hard
>> to not just check the rp is ours, but also set the filter to specify
>> that rp, or maybe just set the mask to include them all?
>>
> To do a check should be simple, we can decode the bdf and find the target
> endpoint and related root port for doing the check.

The function hisi_pcie_pmu_valid_requester_id() already does this.
It can get the RP of the bdf, then check whether the RP is within
the RP range of the PCIe PMU.

> Another example is what we've done in hisi_ptt that we maintian a list of
> supported root ports and endpoints, but that will be a bit more complex.
>
>> Jonathan
>>
>>
>>> ---
>>>   drivers/perf/hisilicon/hisi_pcie_pmu.c | 8 ++++----
>>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/perf/hisilicon/hisi_pcie_pmu.c b/drivers/perf/hisilicon/hisi_pcie_pmu.c
>>> index 83be3390686c..b91f03c02c57 100644
>>> --- a/drivers/perf/hisilicon/hisi_pcie_pmu.c
>>> +++ b/drivers/perf/hisilicon/hisi_pcie_pmu.c
>>> @@ -306,10 +306,10 @@ static bool hisi_pcie_pmu_valid_filter(struct perf_event *event,
>>>   	if (hisi_pcie_get_trig_len(event) > HISI_PCIE_TRIG_MAX_VAL)
>>>   		return false;
>>>   
>>> -	if (requester_id) {
>>> -		if (!hisi_pcie_pmu_valid_requester_id(pcie_pmu, requester_id))
>>> -			return false;
>>> -	}
>>> +	/* Need to explicitly set filter of "port" or "bdf" */
>>> +	if (!hisi_pcie_get_port(event) &&
>>> +	    !hisi_pcie_pmu_valid_requester_id(pcie_pmu, requester_id))
>>> +		return false;
>>>   
>>>   	return true;
>>>   }
>> .
>>


  reply	other threads:[~2024-02-22  1:21 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-04  7:45 [PATCH 0/7] Several updates for HiSilicon PCIe PMU driver Yicong Yang
2024-02-04  7:45 ` [PATCH 1/7] drivers/perf: hisi_pcie: Introduce hisi_pcie_pmu_get_filter() Yicong Yang
2024-02-08 12:06   ` Jonathan Cameron
2024-02-08 12:18     ` Jonathan Cameron
2024-02-21  9:39       ` Yicong Yang
2024-02-04  7:45 ` [PATCH 2/7] drivers/perf: hisi_pcie: Fix incorrect counting under metric mode Yicong Yang
2024-02-08 12:19   ` Jonathan Cameron
2024-02-04  7:45 ` [PATCH 3/7] drivers/perf: hisi_pcie: Add more events for counting TLP bandwidth Yicong Yang
2024-02-08 12:20   ` Jonathan Cameron
2024-02-21  9:40     ` Yicong Yang
2024-02-04  7:45 ` [PATCH 4/7] drivers/perf: hisi_pcie: Check the target filter properly Yicong Yang
2024-02-08 12:29   ` Jonathan Cameron
2024-02-21  9:46     ` Yicong Yang
2024-02-22  1:21       ` hejunhao [this message]
2024-02-22  1:29     ` hejunhao
2024-02-04  7:45 ` [PATCH 5/7] drivers/perf: hisi_pcie: Relax the check on related events Yicong Yang
2024-02-04  7:45 ` [PATCH 6/7] drivers/perf: hisi_pcie: Merge find_related_event() and get_event_idx() Yicong Yang
2024-02-08 12:39   ` Jonathan Cameron
2024-02-22  3:00     ` hejunhao
2024-02-04  7:45 ` [PATCH 7/7] docs: perf: Update usage for target filter of hisi-pcie-pmu Yicong Yang

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=0ab7dae0-e132-2b8a-5a6c-1e517c92aa01@huawei.com \
    --to=hejunhao3@huawei.com \
    --cc=Jonathan.Cameron@Huawei.com \
    --cc=fanghao11@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=mark.rutland@arm.com \
    --cc=prime.zeng@hisilicon.com \
    --cc=will@kernel.org \
    --cc=yangyicong@hisilicon.com \
    --cc=yangyicong@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®