On Tue, 2014-10-21 at 00:13 +0300, Or Gerlitz wrote:
> On Mon, Oct 20, 2014 at 6:29 PM, Chris Moore wrote:
> > The following code is in isert_conn_setup_qp() in ib_isert.c:
> >
> > /*
> >* FIXME: Use devattr.max_sge - 2 for max_send_sge as
> >* work-around for RDMA
On 10/22/2014 7:29 AM, Minh Duc Tran wrote:
Not just that one liner change. The change is about 10 lines and very simple.
It should take you about 30 seconds to read it. We need the whole patch to fix
two problems:
1) the create CQ failure due to requested CQ entries too large.
2) the creat
>On 10/22/2014 12:11 AM, Minh Duc Tran wrote:
>> Hi Or,
>>
>>> So just to recaphere.
>>> With your driver maximal attributes of 8K CQEs per CQ and 32 CQs per
>>> device, do/what we need to change s.t that the iser initiator functional
>>> with it's current code is functional on 3.18-rc1?
>> Yes,
On 10/22/2014 12:11 AM, Minh Duc Tran wrote:
Hi Or,
So just to recaphere.
With your driver maximal attributes of 8K CQEs per CQ and 32 CQs per device,
do/what we need to change s.t that the iser initiator functional with it's
current code is functional on 3.18-rc1?
Yes, I've just verified th
Hi Or,
>So just to recaphere.
>With your driver maximal attributes of 8K CQEs per CQ and 32 CQs per device,
>do/what we need to change s.t that the iser initiator functional with it's
>current code is functional on 3.18-rc1?
Yes, I've just verified the patch with 3.18-rc1 on both ocrdma and mlx
On 10/20/2014 8:36 AM, Minh Duc Tran wrote:
Hi Sagi,
I've created a new patch over the 21 iser patches you have mentioned early in
this thread. It is pasted at the end of this email.
If I understand correctly, this patch will be applied along with Or's TODO list.
ISER_MAX_RX_CQ_LEN
On 10/21/2014 5:20 PM, Eli Cohen wrote:
On Sun, Oct 19, 2014 at 10:34:04PM +0300, Sagi Grimberg wrote:
+mlx5_ib_warn(dev, "\n");
Will the warning generated by this code allow a user to find out which
code triggered that warning ?
Not at all - and it should be fixed. wil
On 10/21/2014 5:22 PM, Or Gerlitz wrote:
Are you hitting an ability to create a CQ?
inability
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/21/2014 12:09 AM, Or Gerlitz wrote:
So I was wrong, sorry... you were talking on CQEs not CQs. I think
Sagi has some proposal on how to harden the code that deals with
setting the size of CQs, let me talk to him.
So just to recaphere.
With your driver maximal attributes of 8K CQEs per CQ
On Sun, Oct 19, 2014 at 10:34:04PM +0300, Sagi Grimberg wrote:
> >
> > > +mlx5_ib_warn(dev, "\n");
> >
> >Will the warning generated by this code allow a user to find out which
> >code triggered that warning ?
>
> Not at all - and it should be fixed. will do.
>
This macro exp
On Mon, Oct 13, 2014 at 11:32:09AM +0300, Sagi Grimberg wrote:
> >
> >>+static void set_indir_umr_segment(struct mlx5_wqe_umr_ctrl_seg *umr,
> >>+ struct ib_send_wr *wr)
> >>+{
> >>+u64 mask;
> >>+u32 list_len = wr->wr.indir_reg.indir_list_len;
> >>+
> >>+memset(umr, 0,
On 10/21/2014 4:26 AM, Vladimir Koushnir wrote:
> if for some reason SM LID recorded in PortInfo of the node is different
> from our SM LID, it is safer to send client reregister notification to this
> node
> to trigger reregistration of the node in Master SM.
>
> This scenario may occur when Sta
On 10/20/2014 6:08 PM, Bart Van Assche wrote:
On 10/19/14 17:19, Sagi Grimberg wrote:
In case last argument of the connection string is
processed as a string (destination gid for example).
Signed-off-by: Sagi Grimberg
---
drivers/infiniband/ulp/srp/ib_srp.c |2 +-
1 files changed, 1 ins
On 10/21/2014 1:54 PM, Bart Van Assche wrote:
On 10/21/14 11:32, Sagi Grimberg wrote:
Since you didn't give any comments on the API itself should I conclude
that you find it clear and you agree with it?
Mostly. The only aspect of which I think that it is missing in the API
is the alignment req
On 10/21/14 11:32, Sagi Grimberg wrote:
Since you didn't give any comments on the API itself should I conclude
that you find it clear and you agree with it?
Mostly. The only aspect of which I think that it is missing in the API
is the alignment requirement for the addresses in
ib_indir_reg_li
On 10/20/2014 10:46 AM, Bart Van Assche wrote:
On 10/19/14 21:34, Sagi Grimberg wrote:
On 10/14/2014 8:41 AM, Bart Van Assche wrote:
> +struct ib_indir_reg_list *
> +mlx5_ib_alloc_indir_reg_list(struct ib_device *device,
> + unsigned int max_indir_list_len)
There are three k
On 10/7/2014 4:07 PM, Bart Van Assche wrote:
Improve performance by using multiple RDMA/RC channels per SCSI
host for communication with an SRP target. About the
implementation:
- Introduce a loop over all channels in the code that uses
target->ch.
- Set the SRP_MULTICHAN_MULTI flag during log
On 10/20/2014 3:56 PM, Bart Van Assche wrote:
On 10/19/14 19:36, Sagi Grimberg wrote:
On 10/7/2014 4:07 PM, Bart Van Assche wrote:
* comp_vector, a number in the range 0..n-1 specifying the
- MSI-X completion vector. Some HCA's allocate multiple (n)
- MSI-X vectors p
On 10/21/2014 11:49 AM, Christoph Hellwig wrote:
On Mon, Oct 20, 2014 at 02:01:25PM +0200, Bart Van Assche wrote:
On 10/19/14 18:12, Sagi Grimberg wrote:
On 10/7/2014 4:04 PM, Bart Van Assche wrote:
-req = blk_queue_find_tag(sdev->request_queue, tag);
+req = blk_queue_find_
On Mon, Oct 20, 2014 at 02:15:07PM +0200, Bart Van Assche wrote:
> How about renaming this function into shost_sdev_count() and moving its
> declaration to and its implementation to
> drivers/scsi/scsi_lib.c ?
I'd prefer to defer this until we have an actual need for it elsewhere.
--
To unsubscr
On Mon, Oct 20, 2014 at 02:01:25PM +0200, Bart Van Assche wrote:
> On 10/19/14 18:12, Sagi Grimberg wrote:
> >On 10/7/2014 4:04 PM, Bart Van Assche wrote:
> >>-req = blk_queue_find_tag(sdev->request_queue, tag);
> >>+req = blk_queue_find_tag(sdev->request_queue, tag);
> >
> >Why
On Mon, Oct 20, 2014 at 01:47:53PM +0200, Bart Van Assche wrote:
> The only reason why patches 10/12 and 11/12 are separate patches
> is to reduce the size of individual patches and hence to make it
> easier to review these patches. If everyone agrees I'm fine with
> folding patch 11/12 into patch
On Mon, Oct 20, 2014 at 01:57:21PM +0200, Bart Van Assche wrote:
> That pr_err() statement was convenient while debugging the multiqueue code
> in the SRP initiator driver but can be left out. Would you agree with
> leaving the above three lines of debug code out instead of adding an
> additional a
if for some reason SM LID recorded in PortInfo of the node is different
from our SM LID, it is safer to send client reregister notification to this node
to trigger reregistration of the node in Master SM.
This scenario may occur when Standby SM loses connectivity to the Master SM and
becomes
Mast
24 matches
Mail list logo
