On Tue, 24 Oct 2023 13:21:27 +0300
<shaib...@amazon.com> wrote:
>> struct ena_offloads {
>> uint32_t tx_offloads;
>> uint32_t rx_offloads;
>> @@ -329,6 +346,7 @@ struct ena_adapter {
>> */
>> uint64_t metrics_stats[ENA_MAX_CUSTOMER_METRICS] __rte_cache_aligned;
>> uint16_t metrics_num;
>> + struct ena_stats_srd srd_stats __rte_cache_aligned;
>> };
> If metrics_num was before the metrics_stats[] you would save some space.
Hi, I checked it with pahole and both ways provide same structure size and
overall same padding size (14B):
uint64_t metrics_stats[6]
__attribute__((__aligned__(64))); /* 181952 48 */
uint16_t metrics_num; /* 182000 2 */
/* XXX 14 bytes hole, try to pack */
/* --- cacheline 2844 boundary (182016 bytes) --- */
struct ena_stats_srd srd_stats __attribute__((__aligned__(64)));
/* 182016 40 */
/* size: 182080, cachelines: 2845, members: 40 */
/* sum members: 181910, holes: 9, sum holes: 146 */
Vs:
uint16_t metrics_num
__attribute__((__aligned__(64))); /* 181952 2 */
/* XXX 6 bytes hole, try to pack */
uint64_t metrics_stats[6]; /* 181960 48 */
/* XXX 8 bytes hole, try to pack */
/* --- cacheline 2844 boundary (182016 bytes) --- */
struct ena_stats_srd srd_stats __attribute__((__aligned__(64)));
/* 182016 40 */
/* size: 182080, cachelines: 2845, members: 40 */
/* sum members: 181910, holes: 10, sum holes: 146 */
