From owner-svn-src-head@freebsd.org Tue Nov 7 17:39:38 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A81EE5F659; Tue, 7 Nov 2017 17:39:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0904379B18; Tue, 7 Nov 2017 17:39:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id vA7HdQnq098169 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 7 Nov 2017 19:39:26 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vA7HdQnq098169 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vA7HdQUM098168; Tue, 7 Nov 2017 19:39:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 7 Nov 2017 19:39:26 +0200 From: Konstantin Belousov To: John Baldwin Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r325506 - in head: sbin/ifconfig sys/net sys/sys Message-ID: <20171107173926.GP2566@kib.kiev.ua> References: <201711070929.vA79TFTc096109@repo.freebsd.org> <2707886.I9a5Fez8At@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2707886.I9a5Fez8At@ralph.baldwin.cx> User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 17:39:38 -0000 On Tue, Nov 07, 2017 at 09:06:52AM -0800, John Baldwin wrote: > On Tuesday, November 07, 2017 09:29:15 AM Konstantin Belousov wrote: > > Author: kib > > Date: Tue Nov 7 09:29:14 2017 > > New Revision: 325506 > > URL: https://svnweb.freebsd.org/changeset/base/325506 > > > > Log: > > Add a place for a driver to report rx timestamps in nanoseconds from > > boot for the received packets. > > > > The rcv_tstmp field overlaps the place of Ln header length indicators, > > not used by received packets. The basic pkthdr rearrangement change > > in sys/mbuf.h was provided by gallatin. > > > > There are two accompanying M_ flags: M_TSTMP means that there is the > > timestamp (and it was generated by hardware). > > > > Another flag M_TSTMP_HPREC indicates that the timestamp is > > high-precision. Practically M_TSTMP_HPREC means that hardware > > provided additional precision comparing with the stamps when the flag > > is not set. E.g., for ConnectX all packets are stamped by hardware > > when PCIe transaction to write out the completion descriptor is > > performed, but PTP packet are stamped on port. For Intel cards, when > > PTP assist is enabled, only PTP packets are stamped in the limited > > number of registers, so if Intel cards ever start support this > > mechanism, they would always set M_TSTMP | M_TSTMP_HPREC if hardware > > timestamp is present for the given packet. > > > > Add IFCAP_HWRXTSTMP interface capability to indicate the support for > > hardware rx timestamping, and ifconfig(8) command to toggle it. > > Hmm, other NICs (Chelsio T4 and later for example) support timestamps that > aren't in nanoseconds but some other frequency (which are themselves useful). > It would be nice to have a more flexible interface that supports not only ns > timestamps. Perhaps a way to expose a direct hardware timestamp as a > "number" without a specific frequency? ConnectX does not provide ns-clocked counter either. It is some internal clock driven by a cristal with > 100MHz frequency. There is no much space in the pkthdr, and the request to provide the timestamp was in the context where the wall clock or some closely related timer is needed. Of course, I can put raw hardware timestamp into the packet header, but only instead of the reduced value. Then the consumer of the timestamp would need to find the interface which received the packet and call its method to convert ? We have only one consumer in tree (SO_TIMESTAMP) and perhaps one possible another consumer (TCP) for this data, both of which require wall clock, so would need to call into the method. Also please see the discussion in the referenced review about accuracy of the convertion. Important example are Intel cards where is only limited number of latched registers, and only PtP packets are stamped. This (and some quirk in ConnectX) explains the high-precision flag.