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 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
Hi Bart,
I like these changes modulo the minor comments we had.
One thing that is missing is generation multiqueue-aware tags at the
blk-mq level, which should be as simple as always adding a queue
prefix in the tag allocation code. Did you consider switching srp
to use the block layer provided
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 Fri, Sep 19, 2014 at 09:05:53PM +0300, Sagi Grimberg wrote:
I think this patch should be squashed with passing LLD hctx patch (in
whatever form it ends up).
Agreed.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
On Sun, Jul 27, 2014 at 12:11:11PM +0300, Boaz Harrosh wrote:
If you have a tree that you want me to test I will be glad too.
From this thread I'm confused as to what patches you want me to
test? please point me to a tree you need testing. You can bug me
any time, any tree. I will be happy to
Hi Anish,
the scsi side changes looks fine to me. Unless you have major updates
to the scsi driver for 3.17 that could cause conflicts I'm fine with
merging the whole series in through the networking tree.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a
On Wed, Jul 16, 2014 at 08:32:59AM +, Anish Bhatt wrote:
We don't have any specific changes queued for 3.17, but the next update
requires a similar change to cxgb4. I'm okay submitting that to net-next if it
is okay with you.
That sounds fine to me.
--
To unsubscribe from this list: send
Sagi,
can you send an update for the core-for-3.17 tree to pass a
dma_direction or the scsi data buffer to scsi_transfer_length so we can
make safe for bidi usage in the future?
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to
Mike, I'd prefer a fix on top of the core-for-3.16 branch in my
scsi-queue tree, which already has the fix from Martin.
I also really don't like these three confusing helpers:
+static inline unsigned scsi_transfer_length(struct scsi_cmnd *scmd)
+{
+ return
Sagi's patch was not correct because scsi_in was hardcoded to the transfer
len when bidi was used.
Right, should have condition that in the direction. something like:
transfer_length = sc-sc_data_direction == DMA_TO_DEVICE ?
scsi_out(sc)-length : scsi_in(sc)-length;
would probably hit
On Wed, Jun 25, 2014 at 01:32:39PM +0300, Sagi Grimberg wrote:
So I tested a bidirectional command using:
$ sg_raw --infile=/root/filex --send=1024 --request=1024
--outfile=/root/filex /dev/bsg/7:0:0:0 53 00 00 00 00 00 00 00 02 00
And I see:
kernel: session1: iscsi_prep_scsi_cmd_pdu iscsi
On Tue, Jun 24, 2014 at 08:53:25AM -0400, Martin K. Petersen wrote:
Oh, I see. So things break because iSCSI uses scsi_transfer_length()
where the scatterlist length was used in the past.
How about this?
This fixes the regression for me.
--
To unsubscribe from this list: send the line
On Tue, Jun 24, 2014 at 04:08:25PM +0300, Sagi Grimberg wrote:
Oh, I see. So things break because iSCSI uses scsi_transfer_length()
where the scatterlist length was used in the past.
Ohhh, didn't notice this one and sent out a duplicate...
The patch looks good to me obviously.
Can you
On Tue, Jun 24, 2014 at 11:08:54AM -0500, Michael Christie wrote:
static inline unsigned scsi_transfer_length(struct scsi_cmnd *scmd)
{
- unsigned int xfer_len = blk_rq_bytes(scmd-request);
+ unsigned int xfer_len = scsi_out(scmd)-length;
unsigned int prot_op =
On Tue, Jun 24, 2014 at 07:27:46PM +0300, Sagi Grimberg wrote:
This condition only matters in the bidi case, which is not relevant for the
PI case.
I suggested to condition that in libiscsi (posted in the second thread,
copy-paste below).
Although I do agree that scsi_transfer_length() helper
This patch causes a regression when using the iscsi initiator over
TCP for me. When mounting a newly created ext4 filesystem I get the
following BUG:
[ 31.611803] BUG: unable to handle kernel NULL pointer dereference at
000c
[ 31.613563] IP: [8197b38d]
On Thu, Apr 24, 2014 at 11:55:08PM -0600, Jason Gunthorpe wrote:
Official OFA OFED is now strictly backports from a given kernel
verison, and TBH, is not widely used now that everything is included
in the modern distros.
The vendor 'OFEDs' remain a big pile. I'm not even sure source is
On Thu, Apr 24, 2014 at 12:54:40PM +0300, sagi grimberg wrote:
Well, I feel the same way (although less harsh about it), I would
prefer to have it all inbox.
As I see it, OFED is useful for costumers who want to upgrade RDMA
functionality (or get Tech previews)
without upgrading their distro
On Mon, Apr 21, 2014 at 06:02:14PM -0400, Chuck Lever wrote:
ALLPHYSICAL is not a safe memory registration mode because it
permits NFS servers to write anywhere in a client's memory. NFS
server bugs could result in client memory being overwritten.
This can be useful for embedded systems
On Mon, Mar 03, 2014 at 12:02:33PM -0500, Chuck Lever wrote:
All HCAs in 3.13 (and rxe) can support either MTHCA_FMR or FRMR or both.
Wendy?s HCA supports only ALLPHYSICAL.
Is Wendy planning to submit her HCA driver ASAP? If not there's not
reason to keep ALLPHYSICAL either.
Does it make
On Sat, Jun 25, 2011 at 11:42:31AM +0200, Bart Van Assche wrote:
The default for max_channel is already zero, so strictly speaking it
is not necessary to set max_channel in srp_target_create(). I choose
to set it anyway to make the intent clear that currently ib_srp only
supports channel == 0
+ccflags-y:= -Idrivers/target
Why do you need the ccflags? Everything needed should be under
include/target, and if not that needs to be fixed.
+#include linux/kthread.h
+#include linux/string.h
+#include linux/delay.h
+#include linux/atomic.h
+#include scsi/libsas.h
401 - 423 of 423 matches
Mail list logo
