Hi Miroslav, > -----Original Message----- > From: Miroslav Lichvar [mailto:mlich...@redhat.com] > Sent: Tuesday, February 07, 2017 6:02 AM > To: netdev@vger.kernel.org > Cc: Richard Cochran <richardcoch...@gmail.com>; Jiri Benc > <jb...@redhat.com>; Keller, Jacob E <jacob.e.kel...@intel.com>; Denny Page > <dennyp...@me.com>; Willem de Bruijn <will...@google.com> > Subject: Extending socket timestamping API for NTP > > I'd like to propose some changes and new options for the timestamping > interface that I think would be useful for NTP implementations and > maybe also other applications. Before I or someone else tries to > implement them, do you think they would actually make sense and fit > well in the current code? > > 1) new rx_filter for NTP > > Some NICs can't timestamp all received packets and are currently > unusable for NTP with HW timestamping. The new filter would allow > NTP support in new NICs and adding support to existing NICs with > firmware/driver updates. The filter would apply to IPv4 and IPv6 > UDP packets received from or sent to the port number 123.
The main problem here is that most hardware that *can't* timestamp all packets is pretty limited to timestamping only PTP frames. It's possible with firmware upgrades this could be worked around, but I do not know if it would actually happen. Still, it can't really hurt too much to add a new filter, and those drivers which can support it already should be easy to implement. > > Should be the current drivers of HW that can timestamp all packets > updated to fall back to HWTSTAMP_FILTER_ALL? Generally, the drivers I am aware of that support timestamping all packets do so for any filter request, rather than actually limiting the timestamping. > > 2) new SO_TIMESTAMPING option to receive from the error queue only > user data as was passed to sendmsg() instead of Ethernet frames > > Parsing Ethernet and IP headers (especially IPv6 options) is not > fun and SOF_TIMESTAMPING_OPT_ID is not always practical, e.g. in > applications which process messages from the error queue > asynchronously and don't bind/connect their sockets. This would be useful for application writing. > > 3) target address in msg_name of messages from the error queue > > With 2) and unconnected sockets, there needs to be a way to get the > address to which the packet was sent. Is it ok to always fill > msg_name, or does it need to be a new option? I'm not sure. > > 4) allow sockets to use both SW and HW TX timestamping at the same time > > When using a socket which is not bound to a specific interface, it > would be nice to get transmit SW timestamps when HW timestamps are > missing. I suspect it's difficult to predict if a HW timestamp will > be available. Maybe it would be acceptable to get from the error > queue two messages per transmission if the interface supports both > SW and HW timestamping? This seems useful, but not sure how best to implement it. > Thoughts? > > -- > Miroslav Lichvar
