From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-f195.google.com ([209.85.217.195]:35666 "EHLO mail-ua0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933897AbeCGRCA (ORCPT ); Wed, 7 Mar 2018 12:02:00 -0500 Received: by mail-ua0-f195.google.com with SMTP id c40so1891124uae.2 for ; Wed, 07 Mar 2018 09:02:00 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20180307052410.m2yqmokrivjlwcjz@localhost> References: <20180307011230.24001-1-jesus.sanchez-palencia@intel.com> <20180307011230.24001-9-jesus.sanchez-palencia@intel.com> <1520391209.109662.33.camel@gmail.com> <20180307052410.m2yqmokrivjlwcjz@localhost> From: Willem de Bruijn Date: Wed, 7 Mar 2018 12:01:19 -0500 Message-ID: Subject: Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if_late params To: Richard Cochran Cc: Eric Dumazet , Jesus Sanchez-Palencia , Network Development , Jamal Hadi Salim , Cong Wang , =?UTF-8?B?SmnFmcOtIFDDrXJrbw==?= , Vinicius Gomes , intel-wired-lan@lists.osuosl.org, anna-maria@linutronix.de, Henrik Austad , Thomas Gleixner , John Stultz , Levi Pearson , Eric Dumazet , Willem de Bruijn , Miroslav Lichvar Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org List-ID: On Wed, Mar 7, 2018 at 12:24 AM, Richard Cochran wrote: > On Tue, Mar 06, 2018 at 06:53:29PM -0800, Eric Dumazet wrote: >> This is adding 32+1 bits to sk_buff, and possibly holes in this very >> very hot (and already too fat) structure. >> >> Do we really need 32 bits for a clockid_t ? > > Probably we can live with fewer bits. > > For clock IDs with a positive sign, the max possible clock value is 16. > > For clock IDs with a negative sign, IIRC, three bits are for the type > code (we have also posix timers packed like this) and the are for the > file descriptor. So maybe we could use 16 bits, allowing 12 bits or > so for encoding the FD. > > The downside would be that this forces the application to make sure > and open the dynamic posix clock early enough before the FD count gets > too high. The same choices are probably made for all packets on a given socket. Unless skb->sk gets scrubbed in some transmit paths, then these be set as sockopt instead of cmsg. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Willem de Bruijn Date: Wed, 7 Mar 2018 12:01:19 -0500 Subject: [Intel-wired-lan] [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and drop_if_late params In-Reply-To: <20180307052410.m2yqmokrivjlwcjz@localhost> References: <20180307011230.24001-1-jesus.sanchez-palencia@intel.com> <20180307011230.24001-9-jesus.sanchez-palencia@intel.com> <1520391209.109662.33.camel@gmail.com> <20180307052410.m2yqmokrivjlwcjz@localhost> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: On Wed, Mar 7, 2018 at 12:24 AM, Richard Cochran wrote: > On Tue, Mar 06, 2018 at 06:53:29PM -0800, Eric Dumazet wrote: >> This is adding 32+1 bits to sk_buff, and possibly holes in this very >> very hot (and already too fat) structure. >> >> Do we really need 32 bits for a clockid_t ? > > Probably we can live with fewer bits. > > For clock IDs with a positive sign, the max possible clock value is 16. > > For clock IDs with a negative sign, IIRC, three bits are for the type > code (we have also posix timers packed like this) and the are for the > file descriptor. So maybe we could use 16 bits, allowing 12 bits or > so for encoding the FD. > > The downside would be that this forces the application to make sure > and open the dynamic posix clock early enough before the FD count gets > too high. The same choices are probably made for all packets on a given socket. Unless skb->sk gets scrubbed in some transmit paths, then these be set as sockopt instead of cmsg.