[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54f580a7-e94a-04b9-1472-5c543ad03f57@mellanox.com>
Date: Thu, 27 Jun 2019 05:25:23 +0000
From: Yamin Friedman <yaminf@...lanox.com>
To: Sagi Grimberg <sagi@...mberg.me>,
Saeed Mahameed <saeedm@...lanox.com>,
"David S. Miller" <davem@...emloft.net>,
Doug Ledford <dledford@...hat.com>,
Jason Gunthorpe <jgg@...lanox.com>
CC: Leon Romanovsky <leonro@...lanox.com>,
Or Gerlitz <ogerlitz@...lanox.com>,
Tal Gilboa <talgi@...lanox.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
Max Gurtovoy <maxg@...lanox.com>
Subject: Re: [for-next V2 08/10] linux/dim: Implement rdma_dim
On 6/26/2019 1:02 AM, Sagi Grimberg wrote:
>
>> +void rdma_dim(struct dim *dim, u64 completions)
>> +{
>> + struct dim_sample *curr_sample = &dim->measuring_sample;
>> + struct dim_stats curr_stats;
>> + u32 nevents;
>> +
>> + dim_update_sample_with_comps(curr_sample->event_ctr + 1,
>> + curr_sample->pkt_ctr,
>> + curr_sample->byte_ctr,
>> + curr_sample->comp_ctr + completions,
>> + &dim->measuring_sample);
>
> If this is the only caller, why add pkt_ctr and byte_ctr at all?
We wanted to keep the API general enough that if someone wants to
implement a different algorithm using the dim library they will be able
to use all the possible statistics. I agree though that in the rdma_dim
function there is no point in making it seem like they are relevant
parameters.
Powered by blists - more mailing lists