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.
Thank you for the review! My reasoning was that the metrics_num should reside
in the same cache line as the metrics_stats (metrics_stats can contain up to 6
metrics so its max length is 48B).
In addition, the struct ena_stats_srd was added in a later patch, so I will
run pahole and verify which order of these three fields gives the best results.
BTW, we are starting a cache optimization task now that should address all
these issues, this is indeed one of our main structures, so it will definitely
get modified later.
