Hi,
On 03/06/2018 06:53 PM, Eric Dumazet wrote:
> On Tue, 2018-03-06 at 17:12 -0800, Jesus Sanchez-Palencia wrote:
>> Extend SO_TXTIME APIs with new per-packet parameters: a clockid_t and
>> a drop_if_late flag. With this commit the API becomes:
>>
>>
>
> * diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> * index d8340e6e8814..951969ceaf65 100644
> * --- a/include/linux/skbuff.h
> * +++ b/include/linux/skbuff.h
> * @@ -788,6 +788,9 @@ struct sk_buff {
> * __u8 tc_redirected:1;
> * __u8 tc_from_ingress:1;
> * #endif
> * + __u8 tc_drop_if_late:1;
> * +
> * + clockid_t txtime_clockid;
> *
> * #ifdef CONFIG_NET_SCHED
> * __u16 tc_index; /* traffic
> control index */
>
>
> This is adding 32+1 bits to sk_buff, and possibly holes in this very
> very hot (and already too fat) structure.
I should have mentioned on the commit msg, but the tc_drop_if_late is actually
filling a 1 bit hole that was already there.
>
> Do we really need 32 bits for a clockid_t ?
There is a 2 bytes hole just after tc_index, so a u16 clockid would fit
perfectly without increasing the skbuffs size / cachelines any further.
>From Richard's reply, it seems safe to just change the definition here if we
make it explicit on the SCM_CLOCKID documentation the caveat about the max
possible fd count for dynamic clocks.
How does that sound?
Thanks,
Jesus
