On Wed, Mar 7, 2018 at 12:24 AM, Richard Cochran <richardcoch...@gmail.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.
