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

[Sagi Grimberg <sagig-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]

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?

>
> #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.

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.

Sagi.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html