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 */