Date: Wed, 6 Sep 2017 15:31:34 -0600 From: Alan Somers <asomers@freebsd.org> To: Maxim Sobolev <sobomax@freebsd.org> Cc: "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: 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 Message-ID: <CAOtMX2jOogy8=HDx2AycW0KrXDe0Bg2LrRC%2BgkZJNzpu4MRycw@mail.gmail.com> In-Reply-To: <CAH7qZfubY5sazakrnkaz5B_5dysUFGz903api8fEiceCHYiD5Q@mail.gmail.com> References: <201701161746.v0GHkcPX071529@repo.freebsd.org> <CAOtMX2h8_c1c_7esYCAWd4gQsy6botDHFWxRCQr=%2Bv67uZOTeg@mail.gmail.com> <CAH7qZfuRqnwwGaHf%2B47fK9cGsmndwRskLgHW54hkDNzbRMmY9Q@mail.gmail.com> <CAH7qZfubY5sazakrnkaz5B_5dysUFGz903api8fEiceCHYiD5Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Cool. Thanks for looking into it. On Wed, Sep 6, 2017 at 3:15 PM, Maxim Sobolev <sobomax@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@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@freebsd.org> wrote: >>> >>> On Mon, Jan 16, 2017 at 10:46 AM, Maxim Sobolev <sobomax@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 >>> >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2jOogy8=HDx2AycW0KrXDe0Bg2LrRC%2BgkZJNzpu4MRycw>