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 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
On Mon, Oct 6, 2014 at 4:16 AM, Bart Van Assche bvanass...@acm.org 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
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
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
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 with
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
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 hold
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 init time
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 both
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_hw_ctx
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
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
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
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
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
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
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
Improve performance by using multiple RDMA/RC channels per SCSI host
for communicating with an SRP target.
Signed-off-by: Bart Van Assche bvanass...@acm.org
---
Documentation/ABI/stable/sysfs-driver-ib_srp | 25 +-
drivers/infiniband/ulp/srp/ib_srp.c | 337 ---
On Fri, Sep 19, 2014 at 9:00 PM, Bart Van Assche bvanass...@acm.org wrote:
Improve performance by using multiple RDMA/RC channels per SCSI host
for communicating with an SRP target.
Signed-off-by: Bart Van Assche bvanass...@acm.org
---
Documentation/ABI/stable/sysfs-driver-ib_srp | 25 +-
On 09/19/14 16:28, Ming Lei wrote:
On Fri, Sep 19, 2014 at 9:00 PM, Bart Van Assche bvanass...@acm.org wrote:
@@ -2643,7 +2754,8 @@ static struct scsi_host_template srp_template = {
.proc_name = DRV_NAME,
.slave_configure=
On Fri, Sep 19, 2014 at 11:21 PM, Bart Van Assche bvanass...@acm.org wrote:
On 09/19/14 16:28, Ming Lei wrote:
On Fri, Sep 19, 2014 at 9:00 PM, Bart Van Assche bvanass...@acm.org
wrote:
@@ -2643,7 +2754,8 @@ static struct scsi_host_template srp_template = {
.proc_name
On 09/19/14 17:27, Ming Lei wrote:
On Fri, Sep 19, 2014 at 11:21 PM, Bart Van Assche bvanass...@acm.org wrote:
On 09/19/14 16:28, Ming Lei wrote:
On Fri, Sep 19, 2014 at 9:00 PM, Bart Van Assche bvanass...@acm.org
wrote:
@@ -2643,7 +2754,8 @@ static struct scsi_host_template srp_template =
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 bvanass...@acm.org wrote:
On 09/19/14 16:28, Ming Lei wrote:
On Fri, Sep 19, 2014 at 9:00 PM, Bart Van Assche bvanass...@acm.org
wrote:
@@ -2643,7 +2754,8 @@
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 bvanass...@acm.org
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 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 bvanass...@acm.org
wrote:
On 09/19/14 16:28, Ming Lei wrote:
On Fri, Sep
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
27 matches
Mail list logo
