[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF=yD-J+3y_RNiW791eW+5i=6Op_0jmM1G8fHiKuKXDqtb8XjA@mail.gmail.com>
Date: Wed, 7 Mar 2018 12:01:19 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Richard Cochran <richardcochran@...il.com>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
Jesus Sanchez-Palencia <jesus.sanchez-palencia@...el.com>,
Network Development <netdev@...r.kernel.org>,
Jamal Hadi Salim <jhs@...atatu.com>,
Cong Wang <xiyou.wangcong@...il.com>,
Jiří Pírko <jiri@...nulli.us>,
Vinicius Gomes <vinicius.gomes@...el.com>,
intel-wired-lan@...ts.osuosl.org, anna-maria@...utronix.de,
Henrik Austad <henrik@...tad.us>,
Thomas Gleixner <tglx@...utronix.de>,
John Stultz <john.stultz@...aro.org>,
Levi Pearson <levi.pearson@...man.com>,
Eric Dumazet <edumazet@...gle.com>,
Willem de Bruijn <willemb@...gle.com>,
Miroslav Lichvar <mlichvar@...hat.com>
Subject: Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and
drop_if_late params
On Wed, Mar 7, 2018 at 12:24 AM, Richard Cochran
<richardcochran@...il.com> 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.
Powered by blists - more mailing lists