svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Alan Somers]

Cool.  Thanks for looking into it.

On Wed, Sep 6, 2017 at 3:15 PM, Maxim Sobolev <sobomax at freebsd.org> wrote:
> Alan, I doubt SO_BINTIME / SO_TIMESTAMP ever worked in that scenario. The
> reason for that is size/layout of the bintime (and other structs) is
> different on amd64 as compared to i386 and I don't see any conversion going
> on in the freebsd32_recvmsg().
>
>                  i386  x86_64
> sizeof(timeval)     8      16
> sizeof(bintime)    12      16
> sizeof(timespec)    8      16
>
> Thereby, first the buffer supplied by the i386 app is not going to be
> sufficient (causing MSG_CTRUNC). Or even if the app on the receiving end
> overcommits for whatever reason, it's not going to be able parse the
> returned structures correctly. This is actually the case with the
> udp_pingpong, that is also not working properly in emulation mode:
>
> [tools/regression/sockets/udp_pingpong]$ ./udp_pingpong
> Testing send()/recv() via IPv4: OK
> Testing send()/recvmsg(), setsockopt(SO_TIMESTAMP, 1) via IPv4:
> udp_pingpong: A2B trip time is not positive
>
> Therefore, the i386 emulation code needs to be extended to actually parse
> into cmghdr structure(s) and to do a proper type conversion between 32 and
> 64 bit versions of the struct timeval, struct bintime and struct timespec.
>
> I have a patch in works to get it fixed, stay tuned.
>
> -Max
>
> On Mon, Sep 4, 2017 at 7:09 PM, Maxim Sobolev <sobomax at freebsd.org> wrote:
>>
>> Sure, I'll check that out. Thanks for heads up.
>>
>> -Max
>>
>> On Sun, Sep 3, 2017 at 8:18 PM, Alan Somers <asomers at freebsd.org> wrote:
>>>
>>> On Mon, Jan 16, 2017 at 10:46 AM, Maxim Sobolev <sobomax at freebsd.org>
>>> wrote:
>>> > Author: sobomax
>>> > Date: Mon Jan 16 17:46:38 2017
>>> > New Revision: 312296
>>> > URL: https://svnweb.freebsd.org/changeset/base/312296
>>> >
>>> > Log:
>>> >   Add a new socket option SO_TS_CLOCK to pick from several different
>>> > clock
>>> >   sources to return timestamps when SO_TIMESTAMP is enabled. Two
>>> > additional
>>> >   clock sources are:
>>> >
>>> >   o nanosecond resolution realtime clock (equivalent of
>>> > CLOCK_REALTIME);
>>> >   o nanosecond resolution monotonic clock (equivalent of
>>> > CLOCK_MONOTONIC).
>>> >
>>> >   In addition to this, this option provides unified interface to get
>>> > bintime
>>> >   (equivalent of using SO_BINTIME), except it also supported with IPv6
>>> > where
>>> >   SO_BINTIME has never been supported. The long term plan is to
>>> > depreciate
>>> >   SO_BINTIME and move everything to using SO_TS_CLOCK.
>>> >
>>> >   Idea for this enhancement has been briefly discussed on the Net
>>> > session
>>> >   during dev summit in Ottawa last June and the general input was
>>> > positive.
>>> >
>>> >   This change is believed to benefit network benchmarks/profiling as
>>> > well
>>> >   as other scenarios where precise time of arrival measurement is
>>> > necessary.
>>> >
>>> >   There are two regression test cases as part of this commit: one
>>> > extends unix
>>> >   domain test code (unix_cmsg) to test new SCM_XXX types and another
>>> > one
>>> >   implementis totally new test case which exchanges UDP packets between
>>> > two
>>> >   processes using both conventional methods (i.e. calling
>>> > clock_gettime(2)
>>> >   before recv(2) and after send(2)), as well as using
>>> > setsockopt()+recv() in
>>> >   receive path. The resulting delays are checked for sanity for all
>>> > supported
>>> >   clock types.
>>> >
>>> >   Reviewed by:    adrian, gnn
>>> >   Differential Revision:  https://reviews.freebsd.org/D9171
>>>
>>> While the new SCM_TIMESTAMP code works fine on both amd64 and i386, it
>>> doesn't work on amd64 under 32-bit emulation.  That is, programs that
>>> use SCM_TIMESTAMP built for i386 will fail when run on an amd64
>>> machine.  I don't know whether this commit introduced that bug; on
>>> stable-10 SCM_TIMESTAMP doesn't appear to work at all on i386.  But
>>> sobomax, since you're obviously familiar with this code, would you
>>> mind taking a look?
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222039
>>>
>>> -Alan
>>>
>>
>