On 28/06/2021 11:49, liuqi (BA) wrote:Hi John,
Hi John,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/
I would suggest supporting a perf metric for this then, which would beyes, we could add these metrics in json file, thanks.
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)
The syntax is actually like:
"MetricExpr": "hisi_pcieX@event\\=0x4\\,subevent\\=0x2@ / hisi_pcieX@event\\=0x1000\\,subevent\\=0x2@",
So how about changing the event name to show the real purpose of thisThen the value in HISI_PCIE_CNT and HISI_PCIE_EXT_CNT returnedBut I am still curious about lat_rx_mrd and the other events which we
separately, and userspace could do the calculation.
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.
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.
Thanks,
John
.