From owner-freebsd-net@freebsd.org Sat Nov 19 18:14:02 2016 Return-Path: Delivered-To: freebsd-net@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 ECC01C4BC95 for ; Sat, 19 Nov 2016 18:14:02 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C08E51C6B for ; Sat, 19 Nov 2016 18:14:02 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-io0-x234.google.com with SMTP id j65so10060358iof.0 for ; Sat, 19 Nov 2016 10:14:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=d90ErHqCFaat5TiHBF9c86veiJzIQcn4gHOqhHHPJE8=; b=BgpdEo6fhQmF3JzD3VuNi+ylkr138JKyEXcOtZFf1hxn5re6UkdXs8t3og2uUsI9CU qxpBS4f11EmSQ7dOivS8RDfrsKPAD51CrSn3uBD41nUMcTyW2akJtOGwf3Jo89UoLK3O ObRKMTebe/vKMSh8hQf4c6BU53NxBCarBfqsd2OY7Tiiis1s6dPCNXUTVE27SEp8TfSu JhlMO1qH/YX1h5ahtFDoXGM92SVfX4bbM218CDWrM4JLYDoT8XydL8syLn6eXvdhcxra o6nM6YsCtPdGOhJP4JOtId63ovOncZfSaKGPv4HTvBNdAjdpa70VZCqxItdhPKEJZ+63 YKfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=d90ErHqCFaat5TiHBF9c86veiJzIQcn4gHOqhHHPJE8=; b=lFWTJ7h6JKV4IbZ1yZe1u1iulEVV+U40KSknY5y/J7O0PDuZh4fCOrgOydg4xJka6V 4lJjUECYULiEUsMEWyx74ImOJPcVQjU7yT8bBQfV37B+ni0MxFjlIYfX6i3/Qrwq/YwB YRuRndSMJTRgI2RxVUr5Lo1v4SF/+y2ZaqvL2DfN0TcpOXWMueMUVriLUxpsPDgSLrub enP9PP8mHCe3e3jHutGCva+0lEoXtBnxpxMgH9Ah+si6xwCa1zSQnvgbiAa/+I9V5nKb v8Z8lqjk6a4xLVwg+vmh066BSirL6ffUpe6b3H2PW3SNB4BVimX4vAzI8n3yzhd6Wcn0 OQ+Q== X-Gm-Message-State: AKaTC02YPj0tFvW2GDI/oCkQ1my0tzOz0f/c7doQ3Lp3+0eBnVVS7GiXUCBQfYn+Plw+j+QbM7IiBrIX6+gSubbb X-Received: by 10.107.13.137 with SMTP id 131mr4629573ion.122.1479579241381; Sat, 19 Nov 2016 10:14:01 -0800 (PST) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.73.102 with HTTP; Sat, 19 Nov 2016 10:14:00 -0800 (PST) From: Maxim Sobolev Date: Sat, 19 Nov 2016 10:14:00 -0800 X-Google-Sender-Auth: 2M5FVZF3N3_QVMOd0ebnSE5ikDQ Message-ID: Subject: Re: Adding SO_CLOCK (replacing SO_BINTIME?). To: freebsd-hackers@freebsd.org, FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2016 18:14:03 -0000 OK, after some more consideration, I'd probably go with scraping SO_BINTIME (FreeBSD private thing) and replacing it with SO_CLOCK which then would take type of clock as an argument, i.e.: int val = SO_CLOCK_MONOTONIC; setsockopt(fd, SO_CLOCK, &val, sizeof(val)); or int val = SO_CLOCK_BINTIME; setsockopt(fd, SO_CLOCK, &val, sizeof(val)); Default value being SO_CLOCK_REALTIME. Then SO_TIMESTAMP could be just the on/off trigger so that there is consistency. We can keep SO_BINTIME around for binary compatibility too at least on the binary level by moving it into a kernel private name space. Regardless of this, I think so_options needs to be bumped up to match what user interface can accommodate (int, not short), makes no sense to "save"* 2 bytes per socket in 2016. The diff is here, reviewers are welcome. https://reviews.freebsd.org/D8582 -Max *) yes, I know it's not really saved perhaps due to alignment and such, hence "". On Wed, Nov 16, 2016 at 5:38 PM, Maxim Sobolev wrote: > Hi folks, we are working on some extra socket options, which is getting > monotinic timestamps instead of realtime. That might be extremely useful in > the Real World[tm] situations. > > Before looking at the code closely I've considered SO_TIMESTAMP_MT. But > then and I've found that are are out of space already there are 16 options > and all 16 seems to be actually referenced in the code. Would there be any > objections to doubling that? The userland interfaces seems to be already > "int", so we are talking about just some minor KABI breakage. > > Alternative approach would be to merge SO_TIMESTAMP and SO_BINTIME, which > is FreeBSD-specific anyways into just SO_TIMESTAMP, so that one can do > something like: > > int val = SO_TS_BINTIME; > setsockopt(fd, SOL_SOCKET, SO_TIMESTAMP, &val, sizeof(val)); > > Then we can also have SO_TS_MONOTONIC, SO_TS_UPTIME etc. > > That second approach would be a bit heavy on third-party apps that might > be using SO_BINTIME already, but some guards could be placed in to make > such software to blow up in a meaningful fashion when trying to use > SO_BINTIME. > > Third option would be to leave SO_BINTIME alone and just make SO_TIMESTAMP > accept some magic value as SO_TS_MONOTONIC. That is probably the easiest, > but also creates some documentation challenge to explain why mechanism for > requesting "bintime" variant is different from "monotonic". > > My preference would be (2), since SO_BINTIME is historic relic and it > should be just value for the SO_TIMESTAMP, not a separate option. > > Thanks! > > -Maxim > P.S. On somewhat unrelated note I've also noticed that tcp_var > uses u_short for its copy, is it my design or just some overlook? I don't > see why would we want to use two different types for essentially the same > thing. This is just calling for all sorts of weird bugs due to implied > sign(edness) of resulting expressions. > P.P.S. Please keep me on the CC, I am not subscribed to those two lists. >