| Message ID | 20230414160105.172125-4-kuba@kernel.org (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net: skbuff: hide some bitfield members | expand |
On 4/14/23 09:01, Jakub Kicinski wrote: > alloc_cpu is currently between 4 byte fields, so it's almost > guaranteed to create a 2B hole. It has a knock on effect of > creating a 4B hole after @end (and @end and @tail being in > different cachelines). > > None of this matters hugely, but for kernel configs which > don't enable all the features there may well be a 2B hole > after the bitfield. Move alloc_cpu there. > > Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h index 45c3044e8123..fd6344aca94a 100644 --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -991,6 +991,8 @@ struct sk_buff { __u16 tc_index; /* traffic control index */ #endif + u16 alloc_cpu; + union { __wsum csum; struct { @@ -1014,7 +1016,6 @@ struct sk_buff { unsigned int sender_cpu; }; #endif - u16 alloc_cpu; #ifdef CONFIG_NETWORK_SECMARK __u32 secmark; #endif
alloc_cpu is currently between 4 byte fields, so it's almost guaranteed to create a 2B hole. It has a knock on effect of creating a 4B hole after @end (and @end and @tail being in different cachelines). None of this matters hugely, but for kernel configs which don't enable all the features there may well be a 2B hole after the bitfield. Move alloc_cpu there. Signed-off-by: Jakub Kicinski <kuba@kernel.org> --- include/linux/skbuff.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)