[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220307213020.GB4490@hoboy.vegasvil.org>
Date: Mon, 7 Mar 2022 13:30:20 -0800
From: Richard Cochran <richardcochran@...il.com>
To: Gerhard Engleder <gerhard@...leder-embedded.com>
Cc: yangbo.lu@....com, David Miller <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, mlichvar@...hat.com,
Vinicius Costa Gomes <vinicius.gomes@...el.com>,
netdev <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH net-next 0/6] ptp: Support hardware clocks with
additional free running time
On Mon, Mar 07, 2022 at 06:54:19PM +0100, Gerhard Engleder wrote:
> ktime_to_cycles uses hwtstamp as key for the cache lookup. As long as
> the PHC is monotonic, the key is unique. If the time of the PHC is set, then
> the cache would be invalidated. I'm afraid that setting the PHC could lead to
> wrong or missing timestamps.
"Wrong" timestamps happen with normal PHCs anyhow. Not a big deal.
Your driver can drop the cache and force racing vclock frames to omit
the Rx timestamp. User space must deal with this in any case.
> For RX both timestamps are already available within skbuff, because they are
> stored in front of the Ethernet header by the hardware. So I have to find a way
> to detect the RX case and copy the right timestamp to hwtstamp.
This works for your driver, but not for the generic vclock. Maybe you
could let the ptp_convert_timestamp() method pass the skb back into your
driver.
Thanks,
Richard
Powered by blists - more mailing lists