Re: [PATCH 1/1] IB/iser: Remove hard coded values for cqe and send_wr

Or Gerlitz
2014-10-20T08:05:33Z

On Sun, Oct 19, 2014 at 6:50 PM, Sagi Grimberg <sagig-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> wrote:
> On 10/16/2014 8:31 AM, Or Gerlitz wrote:
>>
>> On Thu, Oct 16, 2014 at 1:41 AM, Minh Duc Tran <MinhDuc.Tran-laKkSmNT4hbQT0dZR+AlfA@public.gmane.org>
>> wrote:
>>>
>>> With the HW and fw profile we are running with the ocrdma currently, it's
>>> 8k per CQ. This number could change if we run on different hw or fw
>>> profile.
>>
>>
>> OK. So CQEs per CQ wise, there's nothing in the ocrdma (sw/fw/fw)
>> which is extremely different. The more major difference is the
>> relatively small numbers
>> of CQs per device you can support on your driver.
>>
>> Sorry for being a bit short and not explaining everything, I'm on LPC
>> 2014 so a bit busy... but AFAI-See-This,
>> here's the list of TODO items here:
>>
>> 1. change the the number of CQs to be min(num_cpus, 1/2 of what the
>> device can support)
>> 2. add the # of SCSI commands per session and y/s immediate data is
>> supported for this session to ep_connect_with_params
>>
>> Sagi, agree?
>>
>> #1 is pretty easy and we actually have it ready for 3.19
> Maybe even 3.18?

It doesn't fix anything, I don't really see the point.

>> #2 should be easy too, Max, please add it to your TODO for the ep
>> connect changes
>>
>
> I don't think we need it in ep_connect.
> We can create CQs/QPs with min(desired, device_support) and just keep
> the sizes and adjust session cmds_max at session creation time, and max
> QPs per CQ.

By "desired" you mean a hard coded maximum on the session cmds_max as
we have today (512)?

> What I am concerned about is that we don't enforce max QPs per
> CQ. we have never seen this overrun - but no reason why it wouldn't
> happen. I have it on my todo list, but we need to take care of it soon.
> This issue would be somewhat relaxed if we got rid of the artificial
> ISER_MAX_CQ.

I haven't seen this coming into play too. But I tend to agree that
once we go for the larger # of CQs, we should be @ a more robust
state.