[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 9 Sep 2022 09:51:23 +0100
From: Lasse Johnsen <lasse@...ebeat.app>
To: Richard Cochran <richardcochran@...il.com>
Cc: netdev@...r.kernel.org, Tony Nguyen <anthony.l.nguyen@...el.com>,
Jesse Brandeburg <jesse.brandeburg@...el.com>,
"Stanton, Kevin B" <kevin.b.stanton@...el.com>,
Jonathan Lemon <bsd@...com>
Subject: Re: [PATCH net-next 1/1] igc: ptp: Add 1-step functionality to igc
driver
My apologies, I will try and be more specific.
This patch affects only skbs in the TX direction which upon being passed to ptp_classify_raw are found
to be of class PTP_CLASS_L2 and of class PTP_CLASS_V2, and on being passed to ptp_msg_is_sync
are found to be of type SYNC as well.
So where the driver received an ioctl with tx config option HWTSTAMP_TX_ONESTEP_SYNC it will process
skbs not matching the above criteria (including PTP_CLASS_IPV4) as it would have had the tx config option
been HWTSTAMP_TX_ON. This patch does not change the behaviour of the latter in any way.
Therefore a user space application which has used the HWTSTAMP_TX_ONESTEP_SYNC tx config option
and is sending UDP messages will as usual receive those messages back in the error queue with
hardware timestamps in the normal fashion. (provided of course in the case of this specific driver that
another tx timestamping operation is not in progress.)
All the best,
Lasse
> On 9 Sep 2022, at 03:51, Richard Cochran <richardcochran@...il.com> wrote:
>
> On Thu, Sep 08, 2022 at 11:48:48PM +0100, Lasse Johnsen wrote:
>> PTP over UDPv4 can run as 2-step concurrently with PTP over Ethernet as 1-step.
>
> That is not my question.
>
> What happens when user space dials one-step and UDP?
>
> Thanks,
> Richard
Powered by blists - more mailing lists