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

Reply via email to