[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180307052410.m2yqmokrivjlwcjz@localhost>
Date: Tue, 6 Mar 2018 21:24:11 -0800
From: Richard Cochran <richardcochran@...il.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Jesus Sanchez-Palencia <jesus.sanchez-palencia@...el.com>,
netdev@...r.kernel.org, jhs@...atatu.com, xiyou.wangcong@...il.com,
jiri@...nulli.us, vinicius.gomes@...el.com,
intel-wired-lan@...ts.osuosl.org, anna-maria@...utronix.de,
henrik@...tad.us, tglx@...utronix.de, john.stultz@...aro.org,
levi.pearson@...man.com, edumazet@...gle.com, willemb@...gle.com,
mlichvar@...hat.com
Subject: Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and
drop_if_late params
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.
Thanks,
Richard
Powered by blists - more mailing lists