On 10/13/14 10:17, Sagi Grimberg wrote:
On 10/7/2014 3:51 PM, Bart Van Assche wrote:
On 09/23/14 18:32, Sagi Grimberg wrote:
Since you don't seem to negotiate/declare multichannel with the target,
did you test this code with some target implementations other than SCST
that happen to be out ther
On 10/7/2014 3:51 PM, Bart Van Assche wrote:
On 09/23/14 18:32, Sagi Grimberg wrote:
Since you don't seem to negotiate/declare multichannel with the target,
did you test this code with some target implementations other than SCST
that happen to be out there?
(replying to an e-mail of two weeks
On Mon, Oct 6, 2014 at 4:16 AM, Bart Van Assche wrote:
> On 10/02/14 19:30, Christoph Hellwig wrote:
>> Also if we want to merge scsi LLDDs that can take advantage of
>> multiqueue support it would probably be best if I take this via the SCSI
>> tree.
> Sending these patches to you is fine with m
On 09/23/14 18:32, Sagi Grimberg wrote:
Since you don't seem to negotiate/declare multichannel with the target,
did you test this code with some target implementations other than SCST
that happen to be out there?
(replying to an e-mail of two weeks ago)
Hello Sagi,
I have just verified that t
On 10/02/14 19:30, Christoph Hellwig wrote:
Also if we want to merge scsi LLDDs that can take advantage of
multiqueue support it would probably be best if I take this via the SCSI
tree.
Sending these patches to you is fine with me, at least if Roland agrees.
Bart.
--
To unsubscribe from this
On 2014-10-03 07:01, Bart Van Assche wrote:
On 10/02/14 18:55, Jens Axboe wrote:
Sure, that's fine as well, but the function needs a more descriptive
name. I try to think of it like I have never looked at the code and need
to write a driver, it's a lot easier if the functions are named
appropria
On 10/02/14 18:55, Jens Axboe wrote:
> Sure, that's fine as well, but the function needs a more descriptive
> name. I try to think of it like I have never looked at the code and need
> to write a driver, it's a lot easier if the functions are named
> appropriately. Seeing blk_mq_rq_tag() and even w
On Thu, Oct 02, 2014 at 06:45:55PM +0200, Bart Van Assche wrote:
> Would it be acceptable to let blk_mq_rq_tag() always return the
> hardware context number and the per-hctx tag ? Block and SCSI LLD
> drivers that do not need the hardware context number can still use
> rq->tag. Drivers that need
On 10/02/2014 10:45 AM, Bart Van Assche wrote:
> On 10/01/14 18:54, Jens Axboe wrote:
>> Lets get rid of the blk_mq_tag struct and just have it be an u32 or
>> something. We could potentially typedef it, but I'd prefer to just have
>> it be an unsigned 32-bit int.
>>
>> Probably also need some in
On 10/01/14 18:54, Jens Axboe wrote:
> Lets get rid of the blk_mq_tag struct and just have it be an u32 or
> something. We could potentially typedef it, but I'd prefer to just have
> it be an unsigned 32-bit int.
>
> Probably also need some init time safety checks that 16-bits is enough
> to ho
On Wed, Oct 01, 2014 at 10:54:28AM -0600, Jens Axboe wrote:
> Lets get rid of the blk_mq_tag struct and just have it be an u32 or
> something. We could potentially typedef it, but I'd prefer to just have it
> be an unsigned 32-bit int.
Agreed.
--
To unsubscribe from this list: send the line "unsub
On 2014-10-01 10:08, Bart Van Assche wrote:
On 09/19/14 17:38, Jens Axboe wrote:
ctx was meant to be private, unfortunately it's leaked a bit into other
parts of block/. But it's still private within that, at least.
Lets not add more stuff to struct request, it's already way too large.
We could
On 09/19/14 17:38, Jens Axboe wrote:
> ctx was meant to be private, unfortunately it's leaked a bit into other
> parts of block/. But it's still private within that, at least.
>
> Lets not add more stuff to struct request, it's already way too large.
> We could add an exported
>
> struct blk_mq_h
On 9/24/2014 4:38 PM, Sagi Grimberg wrote:
On 9/24/2014 4:13 PM, Bart Van Assche wrote:
On 24/09/2014 6:22, Sagi Grimberg wrote:
Since SRP_LOGIN_REQ/RESP has some free bits why not declare it and
activate it when both sides *says* they support it? I'd be much calmer
knowing we're on the safe si
On 9/24/2014 4:13 PM, Bart Van Assche wrote:
On 24/09/2014 6:22, Sagi Grimberg wrote:
Since SRP_LOGIN_REQ/RESP has some free bits why not declare it and
activate it when both sides *says* they support it? I'd be much calmer
knowing we're on the safe side on this...
Hello Sagi,
Since more than
On 24/09/2014 6:22, Sagi Grimberg wrote:
Since SRP_LOGIN_REQ/RESP has some free bits why not declare it and
activate it when both sides *says* they support it? I'd be much calmer
knowing we're on the safe side on this...
Hello Sagi,
Since more than ten years the SRP protocol is an official ANS
On 9/23/2014 10:02 PM, Bart Van Assche wrote:
On 23/09/2014 10:32, Sagi Grimberg wrote:
On 9/19/2014 4:00 PM, Bart Van Assche wrote:
Improve performance by using multiple RDMA/RC channels per SCSI host
for communicating with an SRP target.
Hey Bart,
Since you don't seem to negotiate/declare
On 23/09/2014 10:32, Sagi Grimberg wrote:
On 9/19/2014 4:00 PM, Bart Van Assche wrote:
Improve performance by using multiple RDMA/RC channels per SCSI host
for communicating with an SRP target.
Hey Bart,
Since you don't seem to negotiate/declare multichannel with the target,
did you test thi
On 9/19/2014 4:00 PM, Bart Van Assche wrote:
Improve performance by using multiple RDMA/RC channels per SCSI host
for communicating with an SRP target.
Hey Bart,
Since you don't seem to negotiate/declare multichannel with the target,
did you test this code with some target implementations oth
On Fri, Sep 19, 2014 at 11:33:15AM -0600, Jens Axboe wrote:
> That'd be fine as well. The mapping is cheap, though, but it would make
> sense to have an appropriate way to just pass it in like it happens for
> ->queue_rq() for native blk-mq drivers.
I think just passing the hw_ctx is fine. But I
On 09/19/2014 11:30 AM, Sagi Grimberg wrote:
> On 9/19/2014 6:38 PM, Jens Axboe wrote:
>> On 09/19/2014 09:35 AM, Bart Van Assche wrote:
>>> On 09/19/14 17:27, Ming Lei wrote:
On Fri, Sep 19, 2014 at 11:21 PM, Bart Van Assche
wrote:
> On 09/19/14 16:28, Ming Lei wrote:
>>
>>
On 9/19/2014 6:38 PM, Jens Axboe wrote:
> On 09/19/2014 09:35 AM, Bart Van Assche wrote:
>> On 09/19/14 17:27, Ming Lei wrote:
>>> On Fri, Sep 19, 2014 at 11:21 PM, Bart Van Assche
>>> wrote:
On 09/19/14 16:28, Ming Lei wrote:
>
> On Fri, Sep 19, 2014 at 9:00 PM, Bart Van Assche
>>>
On 09/19/2014 09:35 AM, Bart Van Assche wrote:
> On 09/19/14 17:27, Ming Lei wrote:
>> On Fri, Sep 19, 2014 at 11:21 PM, Bart Van Assche wrote:
>>> On 09/19/14 16:28, Ming Lei wrote:
On Fri, Sep 19, 2014 at 9:00 PM, Bart Van Assche
wrote:
>
> @@ -2643,7 +2754,8 @@ static st
On 09/19/14 17:27, Ming Lei wrote:
> On Fri, Sep 19, 2014 at 11:21 PM, Bart Van Assche wrote:
>> On 09/19/14 16:28, Ming Lei wrote:
>>>
>>> On Fri, Sep 19, 2014 at 9:00 PM, Bart Van Assche
>>> wrote:
@@ -2643,7 +2754,8 @@ static struct scsi_host_template srp_template = {
On Fri, Sep 19, 2014 at 11:21 PM, Bart Van Assche wrote:
> On 09/19/14 16:28, Ming Lei wrote:
>>
>> On Fri, Sep 19, 2014 at 9:00 PM, Bart Van Assche
>> wrote:
>>>
>>> @@ -2643,7 +2754,8 @@ static struct scsi_host_template srp_template = {
>>> .proc_name = DRV_NAME,
>
On 09/19/14 16:28, Ming Lei wrote:
On Fri, Sep 19, 2014 at 9:00 PM, Bart Van Assche wrote:
@@ -2643,7 +2754,8 @@ static struct scsi_host_template srp_template = {
.proc_name = DRV_NAME,
.slave_configure= srp_slave_configure,
.info
On Fri, Sep 19, 2014 at 9:00 PM, Bart Van Assche wrote:
> Improve performance by using multiple RDMA/RC channels per SCSI host
> for communicating with an SRP target.
>
> Signed-off-by: Bart Van Assche
> ---
> Documentation/ABI/stable/sysfs-driver-ib_srp | 25 +-
> drivers/infiniband/ulp/srp/ib
Improve performance by using multiple RDMA/RC channels per SCSI host
for communicating with an SRP target.
Signed-off-by: Bart Van Assche
---
Documentation/ABI/stable/sysfs-driver-ib_srp | 25 +-
drivers/infiniband/ulp/srp/ib_srp.c | 337 ---
drivers/infiniband/
28 matches
Mail list logo
