On Mon, Aug 16, 2021 at 03:38:21PM +0000, Eric Decker wrote:
> Subject: [PATCH] Only forward responses to UDS port with corresponding
> requests on the UDS port, and always send management with a unique sequence
> count from uds.
The subject line should be ONE sentence, please.
>
> 1. Only forward responses to UDS port with a corresponding requests on
> the UDS port.
This is one "issue", and you have a second issue, below. That means
you should make (at least) two patches that address the issues
independently.
> When ptp4l is configured as a boundary clock and a host on ethernet
> is issuing excessive management requests (a PTP monitoring tool)
> then the requests get forwarded across the boundary clock and the
> subsequent responses get forwarded to the UDS port. The UDS code
> sends messages to the uds address of the last process it received a
> message from. The phc2sys daemon is not expecting these responses
> which causes its receive buffers to get full and then the ptp4l send
> buffers get full which causes ptp4l to lock until phc2sys reads the
> messages from its uds port. ptp4l will lock until phc2sys reads
> messages from the uds port which happens every 60sec.
So the proper fix would be to ensure the ptp4l's write() is non
blocking.
> How the proposed solution fixes the problem:
>
> Ptp4l will only forward ptp management response messages to the uds
> port if it was requested by the uds port. This will prevent the uds
> port buffers from getting full and causing ptp4l to hang until the
> buffers are read.
Actually, this is wrong. Why? Because the management scheme in 1588
is multicast on purpose. All of the clients benefit from the replies.
For example, if a client wants to monitor CURRENT_DATA_SET
periodically, it can set a timer. If a reply from *another* client
arrives before the timer expires, the client simply uses the
information in the reply and resets the timer. This scheme will
reduce duplicated queries in the network.
So ptp4l must not filter the replies.
> 2. PTP management messages originated from UDS (pmc) do not have
> the correct source clock id,
I can't agree with this statement. There is no such thing a "correct"
clockId. They are arbitrary.
> and always have the same sequence count
untrue. See line 540 of pmc_common.c:
msg->header.sequenceId = pmc->sequence_id++;
> which prevents end nodes on ethernet from responding.
Why should that prevent nodes from responding?
> Ptp4l will now maintain a static sequence count and send PTP
> management messages using this sequence count so each PTP management
> message will have a unique sequential sequence count.
ptp4l does not generate the messages, and so it has no business
"correcting" them.
> The correct
> source clock ID is also included in the management messages.
The proper fix is to allow configuration of the clockId in the pmc
program via the config mechanism, just like we have in ptp4l.
Thanks,
Richard
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
