On Mon, Nov 23, 2015 at 06:35:28PM -0800, Caitlin Bestler wrote:
> Is it possible for an IB HCA to transmit a response on a QP and not
> in that packet or a previous packet acknowledge something that it
> has delivered to the user?
AFAIK, the rules of ack coalescing do not interact with the send
On 11/23/2015 4:00 PM, Jason Gunthorpe wrote:
On Mon, Nov 23, 2015 at 03:30:42PM -0800, Caitlin Bestler wrote:
The receive completion can be safely assumed to indicate transmit
completion over a reliable connection unless your peer has gone
completely bonkers and is replying to a c
On Mon, 2015-11-23 at 23:27 +0800, Ming Lei wrote:
> On Mon, Nov 23, 2015 at 11:20 PM, Laurent Dufour
> wrote:
> > >
> > > Reverting above commit on top if 4.4-rc1 seems to fix the problem for me.
> >
> > That's what I mentioned earlier ;)
> >
> > Now Ming send an additional patch with seems to
On Mon, 23 Nov 2015, Ondrej Zary wrote:
>
> PDMA seems to be broken in multiple ways. NCR5380_pread cannot process
> less than 128 bytes. In fact, 53C400 datasheet says that it's HW
> limitation: non-modulo-128-byte transfers should use PIO.
>
> Adding
> transfersize = round_down(tran
On 11/23/2015 7:00 PM, Jason Gunthorpe wrote:
On Mon, Nov 23, 2015 at 03:30:42PM -0800, Caitlin Bestler wrote:
The receive completion can be safely assumed to indicate transmit
completion over a reliable connection unless your peer has gone
completely bonkers and is replying to a com
On Mon, Nov 23, 2015 at 07:34:53PM -0500, Tom Talpey wrote:
> Been there, seen that. Bluescreened on it, mysteriously.
Yes, me too :(
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http:
On Mon, Nov 23, 2015 at 03:30:42PM -0800, Caitlin Bestler wrote:
>The receive completion can be safely assumed to indicate transmit
>completion over a reliable connection unless your peer has gone
>completely bonkers and is replying to a command that it did not
>receive.
Perhaps iW
On Mon, Nov 23, 2015 at 02:33:05PM -0800, Bart Van Assche wrote:
> On 11/23/2015 02:18 PM, Jason Gunthorpe wrote:
> >On Mon, Nov 23, 2015 at 01:54:05PM -0800, Bart Van Assche wrote:
> >What I don't see is how SRP handles things when the
> >sendq fills up, ie the case where __srp_get_tx_iu() == NULL
On Sunday 22 November 2015 00:32:31 Finn Thain wrote:
>
> On Sat, 21 Nov 2015, Ondrej Zary wrote:
>
> > On Saturday 21 November 2015 02:58:57 Finn Thain wrote:
> >
> > >
> > > I gather that your setup here is a QUANTUM LP240S target with Domex
> > > 3181 (DTC-436) card and g_NCR5380 module. I'
On 11/23/2015 02:18 PM, Jason Gunthorpe wrote:
On Mon, Nov 23, 2015 at 01:54:05PM -0800, Bart Van Assche wrote:
What I don't see is how SRP handles things when the
sendq fills up, ie the case where __srp_get_tx_iu() == NULL. It looks
like the driver starts to panic and generates printks. I can't
On Mon, Nov 23, 2015 at 01:54:05PM -0800, Bart Van Assche wrote:
> Not really ... Please have a look at the SRP initiator source code. What the
> SRP initiator does is to poll the send queue before sending a new
> SCSI
I see that. What I don't see is how SRP handles things when the
sendq fills up
On 11/23/2015 01:28 PM, Jason Gunthorpe wrote:
On Mon, Nov 23, 2015 at 01:04:25PM -0800, Bart Van Assche wrote:
Considerable time ago the send queue in the SRP initiator driver was
modified from signaled to non-signaled to reduce the number of interrupts
triggered by the SRP initiator driver. T
On Mon, Nov 23, 2015 at 01:04:25PM -0800, Bart Van Assche wrote:
> Considerable time ago the send queue in the SRP initiator driver was
> modified from signaled to non-signaled to reduce the number of interrupts
> triggered by the SRP initiator driver. The SRP initiator driver polls the
> send que
On 11/23/2015 12:37 PM, Jason Gunthorpe wrote:
On Sat, Nov 14, 2015 at 08:13:44AM +0100, Christoph Hellwig wrote:
On Fri, Nov 13, 2015 at 03:06:36PM -0700, Jason Gunthorpe wrote:
Looking at that thread and then at the patch a bit more..
+void ib_process_cq_direct(struct ib_cq *cq)
[..]
+
On Mon, Nov 23, 2015 at 01:01:36PM -0700, Jason Gunthorpe wrote:
> Okay, having now read the whole thing, I think I see the flow now. I don't
> see any holes in the above, other than it is doing a bit more work
> than it needs in some edges cases because it doesn't know if the CQ is
> actually empt
On Sat, Nov 14, 2015 at 08:13:44AM +0100, Christoph Hellwig wrote:
> On Fri, Nov 13, 2015 at 03:06:36PM -0700, Jason Gunthorpe wrote:
> > Looking at that thread and then at the patch a bit more..
> >
> > +void ib_process_cq_direct(struct ib_cq *cq)
> > [..]
> > + __ib_process_cq(cq, INT_MAX);
>
On Sat, Nov 14, 2015 at 08:08:49AM +0100, Christoph Hellwig wrote:
> On Fri, Nov 13, 2015 at 11:25:13AM -0700, Jason Gunthorpe wrote:
> > For instance, like this, not fulling draining the cq and then doing:
> >
> > > + completed = __ib_process_cq(cq, budget);
> > > + if (completed < budget) {
> >
target_core_sbc's compare_and_write functionality suffers from taking
data at the wrong memory location when writing a CAW request to disk.
Given the following sample LIO subtopology,
% targetcli ls /loopback/
o- loopback . [1 Target]
o- naa.6001405ebb8df14a
On 11/23/2015 08:10 AM, Hannes Reinecke wrote:
On 11/20/2015 11:58 PM, Bart Van Assche wrote:
On 11/20/2015 02:52 AM, Hannes Reinecke wrote:
One thing, though: I don't really agree with Barts objection that
moving to a workqueue would tie in too many resources.
Thing is, I'm not convinces tha
On 11/20/2015 11:58 PM, Bart Van Assche wrote:
> On 11/20/2015 02:52 AM, Hannes Reinecke wrote:
>> One thing, though: I don't really agree with Barts objection that
>> moving to a workqueue would tie in too many resources.
>> Thing is, I'm not convinces that using a work queue is allocating
>> too
On Mon, Nov 23, 2015 at 11:20 PM, Laurent Dufour
wrote:
>>
>> Reverting above commit on top if 4.4-rc1 seems to fix the problem for me.
>
> That's what I mentioned earlier ;)
>
> Now Ming send an additional patch with seems to fix the bug introduced
> through the commit bdced438acd8. When testing
On Mon, 23 Nov 2015 10:46:20 +0800
Ming Lei wrote:
> Hi Mark,
>
> On Mon, Nov 23, 2015 at 9:50 AM, Mark Salter wrote:
> > On Mon, 2015-11-23 at 08:36 +0800, Ming Lei wrote:
> >> On Mon, Nov 23, 2015 at 7:20 AM, Mark Salter wrote:
> >> > On Sun, 2015-11-22 at 00:56 +0800, Ming Lei wrote:
> >> >
On 23/11/2015 16:13, Pratyush Anand wrote:
> On 23/11/2015:02:57:19 PM, Laurent Dufour wrote:
>> On 23/11/2015 00:20, Mark Salter wrote:
>>> On Sun, 2015-11-22 at 00:56 +0800, Ming Lei wrote:
On Sat, 21 Nov 2015 12:30:14 +0100
Laurent Dufour wrote:
> On 20/11/2015 13:10, Michael
On 23/11/2015:02:57:19 PM, Laurent Dufour wrote:
> On 23/11/2015 00:20, Mark Salter wrote:
> > On Sun, 2015-11-22 at 00:56 +0800, Ming Lei wrote:
> >> On Sat, 21 Nov 2015 12:30:14 +0100
> >> Laurent Dufour wrote:
> >>
> >>> On 20/11/2015 13:10, Michael Ellerman wrote:
> On Thu, 2015-11-19 at
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Sagi Grimberg
> Sent: Monday, November 23, 2015 4:36 AM
> To: Steve Wise; 'Christoph Hellwig'; linux-r...@vger.kernel.org
> Cc: bart.vanass...@sandisk.com; ax...@fb.
> -Original Message-
> From: Sagi Grimberg [mailto:sa...@dev.mellanox.co.il]
> Sent: Monday, November 23, 2015 4:29 AM
> To: Steve Wise; 'Christoph Hellwig'; linux-r...@vger.kernel.org
> Cc: bart.vanass...@sandisk.com; ax...@fb.com; linux-scsi@vger.kernel.org;
> linux-ker...@vger.kernel.
On Mon, Nov 23, 2015 at 12:35:44PM +0200, Sagi Grimberg wrote:
>
>> So Maybe we should have:
>> void ib_drain_qp(struct ib_qp *qp)
>
> Christoph suggested that this flushing would be taken care
> of by rdma_disconnect which sounds even better I think..
Note that will only work once we've converted
On 23/11/2015 00:20, Mark Salter wrote:
> On Sun, 2015-11-22 at 00:56 +0800, Ming Lei wrote:
>> On Sat, 21 Nov 2015 12:30:14 +0100
>> Laurent Dufour wrote:
>>
>>> On 20/11/2015 13:10, Michael Ellerman wrote:
On Thu, 2015-11-19 at 00:23 -0800, Christoph Hellwig wrote:
> It's pretty mu
So Maybe we should have:
void ib_drain_qp(struct ib_qp *qp)
Christoph suggested that this flushing would be taken care
of by rdma_disconnect which sounds even better I think..
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.ke
That won't work for iWARP. Is this code new? I didn't see any errors that
would result from this code when I tested iSER over
cxgb4 with the old iwarp support patches.
Steve,
I think I figured out why this works with iWARP.
For iWARP, rdma_disconnect() calls iw_cm_disconnect() with abrupt
30 matches
Mail list logo
