Dear Erez,
Thanks for your feedback.
Thinking about it more carefully, I'm not sure that an index-based GET/SET can
be the right way because we cannot retrieve the history in an atomic way.
An idea, but I still need to investigate, can be a CMD "GIVE_ME_PM_HISTORY"
(fancy name). After the command the daemon will send all sample using different
management messages.
Process Monitor Linux PTP
CMD GIVE_ME_PM_HISTORY ->
<- RESP CMD GIVE_ME_PM_HISTORY OK
<- RESP GET PM_SAMPLE x
<- RESP GET PM_SAMPLE x+1
...
<- RESP GET PM_SAMPLE current
The behavior will be very similar to notification mechanism with unsolicited
GET Response messages.
Erez, did you get a look at the code?
ciao
________________________________
Da: Erez <erezge...@gmail.com>
Inviato: venerdì 18 agosto 2023 19:55
A: Luigi Mantellini <luigi.mantell...@gmail.com>
Cc: linuxptp-devel@lists.sourceforge.net <linuxptp-devel@lists.sourceforge.net>
Oggetto: Re: [Linuxptp-devel] [RFC PATCH 0/1] Support for Port level
Perforamnce Monitoring Counters
Caution: This message was sent from an external source. Please take care when
clicking links or opening attachments. When in doubt, contact your IT Department
On Fri, 18 Aug 2023 at 14:36, Luigi Mantellini
<luigi.mantell...@gmail.com<mailto:luigi.mantell...@gmail.com>> wrote:
Dear All,
Starting from IEEE 1588-2019 Annex J, I'm trying to introduce a Performace
monitoring Counters.
The standard asks to keep up 98 records (96 for 15min records and 2 for 24h
records).
I tried to follow a more general approach keeping different circular buffer
for 15min and 24h (and adding also 1h for test purpose).
The patch need to be split, of course, but it's a starting point to have any
feedbacks.
Starting from config, I introduced 3 port level parameters in order to
configure the circular buffer sizes/history:
performance_monitor.15m_history (default 0, disabled)
performance_monitor.1h_history (default 0, disabled)
performance_monitor.24h_history (default 0, disabled)
The parameters can also be changed using the management TLV PM_CONF_NP.
When at least a pm is enabled, a PM_TIMER is armed (TFD_TIMER_ABSTIME aligned
to 15min).
When the PM_TIMER expires the sample is stored into circolar buffer and a
notification is sent (NOTIFY_{PM15Mm,PM1H,PM24H}_UPDATE).
The notification generates a {PM15M,PM1H,PM24H}_LAST_NP management message.
A monitor process can receive the update and manage the data model according
the IEEE 1588-2019 Annex J.
In addition to above {PM15M,PM1H,PM24H}_LAST_NP management message, I
introduced also messages to retrive the CURRENT and the complete HISTORY:
x_LAST_NP Get the last SAVED sample with the delta counters.
x_CURRENT_NP Get the current (NOT saved yet) sample.
x_HISTORY_NP Get the complete history of all records.
(where x is PM15M, PM1H or PM24H)
All mamagement messages use the same TLV format.
I already known that the implementation is far to be accettable, and should be
split in more patches.
I ask for any feedbacks. My main issue is the x_HISTORY_NP messages. Using a
1500 bytes frame there is not enough space to keep an huge history, causing a
frame corruption (bad message). Any idea to handle huge management messages?
I also tried to imaginate a x_GET_NP to read a specific item. In this case I
need to put an index vale into the GET message in order to handle the answer.
Unfortunately sent GET messages are empty by construction and I cannot
prefill with an index value. (WA: use SET?).
I think using 'SET' is OK.
On request you put the index as first value and leave the rest of the TLV with
zeroes.
Then respond with the same index and fill the TLV with statistics values.
As I remember, the response of a set can use the same TLV.
>From IEEE 1558-2019 "Table 57 - Values of the actionField"
"SET"
"The PTP management message shall carry a single management TLV.
The managementId field of the TLV indicates the specific information values
that need to be set.
If the data identified by the managementId consists of several fields, the
update shall be considered as an atomic action and the failure to update any
item shall be considered an error in the execution of the SET.
Attempts to set a static or nonconfigurable value shall return a management
error status TLV (see 15.5.4).
TLVs with data definitions that mix configurable and nonconfigurable data are
not permitted.
An addressed PTP Port or PTP Instance shall respond with a PTP management
message with the actionField value set to RESPONSE.
If no error occurs, the TLV in the PTP management message shall contain the
current values of the data identified by the managementId.
If an error occurs, the TLV shall be a management error status TLV."
I understand that the response should use the same TLV.
On both the SET and the RESPONSE, the index value is the same.
Although the standard forbids setting a static or nonconfigurable value.
It also forbids mixing, so what about using only nonconfigurable and non-static
values?
I think we can skip this rule for statistics.
And as the index and the statistics are both nonconfigurable and non static
data. I think we are on safe ground.
Erez
I will appreciate any comments.
Thanks agian and best regards,
luigi
Luigi Mantellini (1):
Add Port Performance Monitor support
config.c | 3 +
ddt.h | 2 +
e2e_tc.c | 36 +++++++
fd.h | 1 +
makefile | 2 +-
msg.h | 2 +-
notification.h | 3 +
p2p_tc.c | 36 +++++++
pmc.c | 123 +++++++++++++++++++++-
pmc_common.c | 66 +++++++++++-
port.c | 277 ++++++++++++++++++++++++++++++++++++++++++++++++-
port_pm.c | 212 +++++++++++++++++++++++++++++++++++++
port_pm.h | 141 +++++++++++++++++++++++++
port_private.h | 7 ++
tlv.c | 80 ++++++++++++++
tlv.h | 35 +++++++
16 files changed, 1017 insertions(+), 9 deletions(-)
create mode 100644 port_pm.c
create mode 100644 port_pm.h
--
2.41.0
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net<mailto:Linuxptp-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
