Re: [PATCH 3/9] IB: add a helper to safely drain a QP

On 11/18/2015 8:06 AM, Christoph Hellwig wrote: On Wed, Nov 18, 2015 at 01:32:19PM +0200, Sagi Grimberg wrote: Christoph, Given the discussion around this patch I think it would be a good idea remove it from the patchset since it's not mandatory for the CQ abstraction. I think that we should

Re: [PATCH] IB/ipoib: CSUM support in connected mode

On Thu, Jul 30, 2015 at 03:58:13PM +0200, Yann Droneaud wrote: > Hi, > > Le jeudi 30 juillet 2015 à 04:46 -0700, Yuval Shaia a écrit : > > This enhancement suggest the usage of IB CRC instead of CSUM in IPoIB > > CM. IPoIB CM uses RC (Reliable Connection) which guarantees the > > corruption

[PATCH 1/1] Fix deadlock when running run_iter_bw_infinitely

The test uses a signal-handler to periodically print a line of report. Snip libc info: 24.4.6 Signal Handling and Nonreentrant Functions Handler functions usually don't do very much. The best practice is to write a handler that does nothing but set an external variable that the program checks

Re: [PATCH 3/9] IB: add a helper to safely drain a QP

Christoph, Given the discussion around this patch I think it would be a good idea remove it from the patchset since it's not mandatory for the CQ abstraction. I think that we should take it with Steve to come up with a complete solution for this bit. Thoughts? -- To unsubscribe from this list:

Re: [PATCH for-next 10/10] IB/iser: Support the remote invalidation exception

AFAIR, in the past there weren't explicit means to do that. What's makes iscsi tcp eligible to support bidi's that we don't have @ iser? In theory, nothing. In practice, iser is missing customer demands, iser targets that support bidi and testing... If someone cared enough about it then I

Re: [PATCH] IB/ipoib: CSUM support in connected mode

On Thu, Jul 30, 2015 at 07:03:22PM -0700, Bart Van Assche wrote: > On 07/30/15 13:09, Yuval Shaia wrote: > >On Thu, Jul 30, 2015 at 09:38:54AM -0700, Bart Van Assche wrote: > >>On 07/30/2015 04:46 AM, Yuval Shaia wrote: > >>> struct ipoib_cm_data { > >>> __be32 qpn; /* High byte MUST be ignored

Re: [PATCH 3/9] IB: add a helper to safely drain a QP

On 17/11/2015 19:06, Bart Van Assche wrote: On 11/15/2015 01:34 AM, Sagi Grimberg wrote: This is taken from srp, and srp drains using a recv wr due to a race causing a use-after-free condition in srp which re-posts a recv buffer in the recv completion handler. Hello Sagi, Would it be

Re: [PATCH 4/9] srpt: chain RDMA READ/WRITE requests

On 18/11/2015 03:17, Bart Van Assche wrote: On 11/13/2015 05:46 AM, Christoph Hellwig wrote: -ret = ib_post_send(ch->qp, , _wr); -if (ret) -break; +if (i == n_rdma - 1) { +/* only get completion event for the last rdma read */ +if

Re: [PATCH 5/9] srpt: use the new CQ API

On Tue, Nov 17, 2015 at 11:38:48AM -0800, Bart Van Assche wrote: > On 11/13/2015 05:46 AM, Christoph Hellwig wrote: >> [ ... ] > > This patch contains two logical changes: > - Conversion to the new CQ API. > - Removal of the ib_srpt_compl thread. > > Had it been considered to implement these

Re: [PATCH for-next 10/10] IB/iser: Support the remote invalidation exception

On Wed, Nov 18, 2015 at 03:33:01PM +0200, Or Gerlitz wrote: > Sagi, it works in TGT and AFAIR with the initiator too. > > Looking on this paper of Pete Wyckoff [1] I see that he says that > few changes to the initiator were needed, not sure which. Or, can you please stop it? Fortunately

Re: [PATCH 3/9] IB: add a helper to safely drain a QP

On Wed, Nov 18, 2015 at 01:32:19PM +0200, Sagi Grimberg wrote: > Christoph, > > Given the discussion around this patch I think it would > be a good idea remove it from the patchset since it's not > mandatory for the CQ abstraction. I think that we should > take it with Steve to come up with a

Re: [PATCH for-next 10/10] IB/iser: Support the remote invalidation exception

On Wed, Nov 18, 2015 at 03:58:48PM +0200, Or Gerlitz wrote: > > Fortunately neither the iSER target or initiator ever support the > > nightmare called bidi commands, > > I honestly don't know why you call it nightmare nor what make you > make that strong assertion. Beause I actually had to deal

Re: [PATCH 2/9] IB: add a proper completion queue abstraction

On Tue, Nov 17, 2015 at 09:52:58AM -0800, Bart Van Assche wrote: > On 11/13/2015 05:46 AM, Christoph Hellwig wrote: >> + * context and does not ask from completion interrupts from the HCA. > > Should this perhaps be changed into "for" ? Yes. > >> + */ >> +void

Re: [PATCH 4/9] srpt: chain RDMA READ/WRITE requests

On Tue, Nov 17, 2015 at 05:17:35PM -0800, Bart Van Assche wrote: > Chaining RDMA requests is a great idea. But it seems to me that this patch > is based on the assumption that posting multiple RDMA requests either > succeeds as a whole or fails as a whole. Sorry but I'm not sure that the >

Re: [PATCH 6/9] srp: use the new CQ API

On Tue, Nov 17, 2015 at 11:56:39AM -0800, Bart Van Assche wrote: > On 11/13/2015 05:46 AM, Christoph Hellwig wrote: >> +static void srp_inv_rkey_done(struct ib_cq *cq, struct ib_wc *wc) >> +{ >> +srp_handle_qp_err(cq, wc, "INV RKEY"); >> +} > > >> [ ... ] > > >> +static void

Re: [PATCH for-next 10/10] IB/iser: Support the remote invalidation exception

Sagi, it works in TGT and AFAIR with the initiator too. Looking on this paper of Pete Wyckoff [1] I see that he says that few changes to the initiator were needed, not sure which. I see. I wasn't aware that TGT supports bidi. However, AFAICT the initiator support was never fully introduced

[PATCH v3 00/22] kthread: Use kthread worker API more widely

My intention is to make it easier to manipulate and maintain kthreads. Especially, I want to replace all the custom main cycles with a generic one. Also I want to make the kthreads sleep in a consistent state in a common place when there is no work. My first attempt was with a brand new API

Re: [PATCH for-next 10/10] IB/iser: Support the remote invalidation exception

On Wed, Nov 18, 2015 at 1:38 PM, Sagi Grimberg wrote: >> AFAIR, in the past there weren't explicit means to do that. >> What's makes iscsi tcp eligible to support bidi's that we don't have @ iser? > In theory, nothing. In practice, iser is missing customer demands, iser

[PATCH v3 18/22] IB/fmr_pool: Convert the cleanup thread into kthread worker API

Kthreads are currently implemented as an infinite loop. Each has its own variant of checks for terminating, freezing, awakening. In many cases it is unclear to say in which state it is and sometimes it is done a wrong way. The plan is to convert kthreads into kthread_worker or workqueues API. It

Re: [PATCH v3 00/22] kthread: Use kthread worker API more widely

On Wed, Nov 18, 2015 at 02:25:05PM +0100, Petr Mladek wrote: > My intention is to make it easier to manipulate and maintain kthreads. > Especially, I want to replace all the custom main cycles with a > generic one. Also I want to make the kthreads sleep in a consistent > state in a common place

Re: [PATCH 1/9] move blk_iopoll to limit and make it generally available

On Tue, Nov 17, 2015 at 09:16:28AM -0800, Bart Van Assche wrote: > How about renaming blk_iopoll into blk_poll ? That way the name still > refers to the block layer. And although the current implementation performs > polling from IRQ context future implementations maybe will allow polling >

Re: [PATCH for-next 08/10] iser-target: Support the remote invalidation exception

On 11/16/2015 6:37 PM, Sagi Grimberg wrote: struct isert_conn *conn; @@ -209,6 +210,7 @@ struct isert_conn { struct work_struct release_work; struct ib_recv_wr beacon; boollogout_posted; + bool