netdev - Re: [PATCH net-next v3] net: micrel: Change to receive timestamp in the frame for lan8841

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 20 Jun 2023 11:30:21 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Horatiu Vultur <horatiu.vultur@...rochip.com>
Cc: <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
 <andrew@...n.ch>, <hkallweit1@...il.com>, <linux@...linux.org.uk>,
 <davem@...emloft.net>, <edumazet@...gle.com>, <pabeni@...hat.com>,
 <richardcochran@...il.com>
Subject: Re: [PATCH net-next v3] net: micrel: Change to receive timestamp in
 the frame for lan8841

On Thu, 15 Jun 2023 11:47:40 +0200 Horatiu Vultur wrote:
> Currently for each timestamp frame, the SW needs to go and read the
> received timestamp over the MDIO bus. But the HW has the capability
> to store the received nanoseconds part and the least significant two
> bits of the seconds in the reserved field of the PTP header. In this
> way we could save few MDIO transactions (actually a little more
> transactions because the access to the PTP registers are indirect)
> for each received frame.
> 
> Instead of reading the rest of seconds part of the timestamp of the
> frame using MDIO transactions schedule PTP worker thread to read the
> seconds part every 500ms and then for each of the received frames use
> this information. Because if for example running with 512 frames per
> second, there is no point to read 512 times the second part.
> 
> Doing all these changes will give a great CPU usage performance.
> Running ptp4l with logSyncInterval of -9 will give a ~60% CPU
> improvement.

Richard, looks good?

I'm not sure if the settime handling is sufficient, some packets may
still sneak thru both getting stamped with new value of time and use
old upper bits and get stamped with old bits and use new upper.
Can we disable timestamping, drain the queue, then change the time
and enable stamping again?