On 10/16/2014 8:31 AM, Or Gerlitz wrote:
On Thu, Oct 16, 2014 at 1:41 AM, Minh Duc Tran <MinhDuc.Tran@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
