Re: [Linuxptp-devel] [PATCH v2 09/10] tmv: Add converters for hardware timestamps
On Thu, Mar 08, 2018 at 07:18:04PM +, Michael Brown wrote:
> Can you give me some idea of what names will be acceptable? I was trying to
> fit within the current naming scheme as closely as possible, but I'm very
> happy to redo it with whatever names you prefer.
Let me think about this. Part of the problem is the hwts.sw field,
which is an ugly hack to being with. That probably should be changed.
> One idea is to extend struct scm_timestamping to append a fractional
> nanosecond field for the hardware timestamp only. This would produce a
> layout that is backwards compatible with older userspace, which would simply
> ignore the fractional part (assuming that it does a minimum-length rather
> than exact-length check on cmsg_len).
>
> Does this sound sensible?
For the kernel, I (and others) would like to get away from the clunky
timespec altogether. Dividing a time value into two fields might have
made sense 30 years ago when operations on eight byte words were
expensive, but today it makes no sense. It only causes pointless
extra computation, first in user space and again the kernel,
converting to and from the timespec.
How about this?
SOF_TIMESTAMPING_HIGH_RES requests time stamps in a new format:
struct {
uint64_t nanoseconds;
uint32_t fractional_nanoseconds;
uint32_t reserved;
};
Would that be enough resolution for you?
Also, will you be able to mainline your driver? It helps new kernel
API acceptance when there is an actual, realistic use case and users.
Thanks,
Richard
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] Planning release 1.9
On Thu, Mar 08, 2018 at 10:42:14PM +0100, Ahmad Fatoum wrote: > In a DSA setup, transmitted packets may be timestamped more than once causing > ptp4l to fail, > as it expects only a single Tx timestamp to be looped back to the socket's > error queue. Right, so this is a limitation of the kernel and not an issue with linuxptp. The kernel does not support MAC and PHY (or switch!) time stamps all on the same interface. If your PHC DSA switch is connected to a MAC that also can be a PHC, then you must disable the MAC PHC function at compile time. (In some cases, this is a Kconfig option, otherwise you'll have to patch your MAC driver.) Thanks, Richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v2 09/10] tmv: Add converters for hardware timestamps
On 08/03/18 04:46, Richard Cochran wrote: On Thu, Mar 01, 2018 at 06:12:27PM +, Michael Brown wrote: Add converters between hardware timestamps and the internal representation, and remove code that directly manipulates the timespec within a hardware timestamp. Although I can see the point of this, still I really dislike this patch. The method names are icky: hwts_sw_to_tmv? Also, it changes too much at once for my taste. I'm happy to rework to more granular patches. Can you give me some idea of what names will be acceptable? I was trying to fit within the current naming scheme as closely as possible, but I'm very happy to redo it with whatever names you prefer. If new, high resolution time stamps will be coming from the kernel, then we definitely will need a better abstraction. But we should talk about what that new form will look like first. I was hoping to get your input on that anyway. :) One idea is to extend struct scm_timestamping to append a fractional nanosecond field for the hardware timestamp only. This would produce a layout that is backwards compatible with older userspace, which would simply ignore the fractional part (assuming that it does a minimum-length rather than exact-length check on cmsg_len). Does this sound sensible? Thanks, Michael -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH v2 08/10] tmv: Move struct hw_timestamp from msg.h to tmv.h
On 08/03/18 04:39, Richard Cochran wrote: but is used in various places that care about the internal time representation. Move this definition to tmv.h as a more natural home. I'm not taking this patch because a) its not technically needed and b) I disagree about what is more natural. The idea behind the header files is: - pdt.h Primitive data types according to 1588 - ddt.h Derived data types (1588) - ds.h Data sets (1588) - msg.h Message types - tmv.h Internal time value representation The message structure includes the protocol fields, the src/dst address (if any), the TLVs, and the time stamp as provided by the networking stack. The HW time stamp is intimately connected to the message data, and so that is where the data structure belongs, IMHO. OK. From memory, this patch was required to solve a circular dependency that would otherwise appear in a subsequent patch. I'll recheck. Michael -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [PATCH RFC V2 08/11] port: Implement the NetSync Monitor protocol.
On Thu, Mar 08, 2018 at 08:07:26AM +, Anders Selhammer wrote: > I reviewed it in outlook, but now when I open it in windows 10 built in > client, it all look as it should. I strongly suggest getting a different email client. If your MTA is exchange, then you will have to create an outside email account, because exchange cannot send plain text messages correctly. See: linux/Documentation/process/email-clients.rst (Actually Gmail does work if you use the IMAP service. It is the web interface that does not work for sending patches.) > Is it possible to add the link to the patch in the mail archive in the end of > the mail also? No, simply because the archive URL is not known at the time of transmission. Thanks, Richard -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
