diff for duplicates of <1489527119.2676.15.camel@sandisk.com> diff --git a/a/1.txt b/N1/1.txt index 3f6b19f..2055f36 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,26 +1,25 @@ -On Mon, 2017-03-13 at 10:24 +0200, Sagi Grimberg wrote: +On Mon, 2017-03-13@10:24 +0200, Sagi Grimberg wrote: > > Before this patch > > the completions from each CQ were processed sequentially. That's a big > > change so I think this should be mentioned clearly in the header above > > ib_process_cq_direct(). ->=20 +> > Note that I now see that the cq lock is not sufficient for mutual > exclusion here because we're referencing cq->wc array outside of it. ->=20 +> > There are three options I see here: > 1. we'll need to allocate a different wc array for polling mode, > perhaps a smaller one? > 2. Export __ib_process_cq (in some form) with an option to pass in a wc > array. > 3. Simply not support non-selective polling but it seems like a shame... ->=20 +> > Any thoughts? I doubt it is possible to come up with an algorithm that recognizes whether or not two different ib_process_cq() calls are serialized. So the -ib_process_cq() caller will have to provide that information. How about add= -ing +ib_process_cq() caller will have to provide that information. How about adding an ib_wc array argument to ib_process_cq() and modifying __ib_process_cq() such that it uses that array if specified and cq->wc otherwise? -Bart.= +Bart. diff --git a/a/content_digest b/N1/content_digest index fa7e9e3..9532ce5 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -2,41 +2,35 @@ "ref\01489065402-14757-7-git-send-email-sagi@grimberg.me\0" "ref\01489077040.2597.3.camel@sandisk.com\0" "ref\0f4ade02b-9d17-20ae-f910-47c718f2a5bd@grimberg.me\0" - "From\0Bart Van Assche <Bart.VanAssche@sandisk.com>\0" - "Subject\0Re: [PATCH rfc 06/10] IB/cq: Don't force IB_POLL_DIRECT poll context for ib_process_cq_direct\0" + "From\0Bart.VanAssche@sandisk.com (Bart Van Assche)\0" + "Subject\0[PATCH rfc 06/10] IB/cq: Don't force IB_POLL_DIRECT poll context for ib_process_cq_direct\0" "Date\0Tue, 14 Mar 2017 21:32:12 +0000\0" - "To\0linux-nvme@lists.infradead.org <linux-nvme@lists.infradead.org>" - linux-rdma@vger.kernel.org <linux-rdma@vger.kernel.org> - linux-block@vger.kernel.org <linux-block@vger.kernel.org> - target-devel@vger.kernel.org <target-devel@vger.kernel.org> - " sagi@grimberg.me <sagi@grimberg.me>\0" "\00:1\0" "b\0" - "On Mon, 2017-03-13 at 10:24 +0200, Sagi Grimberg wrote:\n" + "On Mon, 2017-03-13@10:24 +0200, Sagi Grimberg wrote:\n" "> > Before this patch\n" "> > the completions from each CQ were processed sequentially. That's a big\n" "> > change so I think this should be mentioned clearly in the header above\n" "> > ib_process_cq_direct().\n" - ">=20\n" + "> \n" "> Note that I now see that the cq lock is not sufficient for mutual\n" "> exclusion here because we're referencing cq->wc array outside of it.\n" - ">=20\n" + "> \n" "> There are three options I see here:\n" "> 1. we'll need to allocate a different wc array for polling mode,\n" "> perhaps a smaller one?\n" "> 2. Export __ib_process_cq (in some form) with an option to pass in a wc\n" "> array.\n" "> 3. Simply not support non-selective polling but it seems like a shame...\n" - ">=20\n" + "> \n" "> Any thoughts?\n" "\n" "I doubt it is possible to come up with an algorithm that recognizes whether\n" "or not two different ib_process_cq() calls are serialized. So the\n" - "ib_process_cq() caller will have to provide that information. How about add=\n" - "ing\n" + "ib_process_cq() caller will have to provide that information. How about adding\n" "an ib_wc array argument to ib_process_cq() and modifying __ib_process_cq()\n" "such that it uses that array if specified and cq->wc otherwise?\n" "\n" - Bart.= + Bart. -50abfe7a633515881ebc62f15f6372ddeef9cf2fc449609f615cbd6d622813d3 +411d000c45d6d35356852ebf587cdcec2e443a1db34e8583e0fd64a2f4311875
diff --git a/a/1.txt b/N2/1.txt index 3f6b19f..2e155e6 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -3,24 +3,23 @@ On Mon, 2017-03-13 at 10:24 +0200, Sagi Grimberg wrote: > > the completions from each CQ were processed sequentially. That's a big > > change so I think this should be mentioned clearly in the header above > > ib_process_cq_direct(). ->=20 +> > Note that I now see that the cq lock is not sufficient for mutual > exclusion here because we're referencing cq->wc array outside of it. ->=20 +> > There are three options I see here: > 1. we'll need to allocate a different wc array for polling mode, > perhaps a smaller one? > 2. Export __ib_process_cq (in some form) with an option to pass in a wc > array. > 3. Simply not support non-selective polling but it seems like a shame... ->=20 +> > Any thoughts? I doubt it is possible to come up with an algorithm that recognizes whether or not two different ib_process_cq() calls are serialized. So the -ib_process_cq() caller will have to provide that information. How about add= -ing +ib_process_cq() caller will have to provide that information. How about adding an ib_wc array argument to ib_process_cq() and modifying __ib_process_cq() such that it uses that array if specified and cq->wc otherwise? -Bart.= +Bart. diff --git a/a/content_digest b/N2/content_digest index fa7e9e3..7fa7f80 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -17,26 +17,25 @@ "> > the completions from each CQ were processed sequentially. That's a big\n" "> > change so I think this should be mentioned clearly in the header above\n" "> > ib_process_cq_direct().\n" - ">=20\n" + "> \n" "> Note that I now see that the cq lock is not sufficient for mutual\n" "> exclusion here because we're referencing cq->wc array outside of it.\n" - ">=20\n" + "> \n" "> There are three options I see here:\n" "> 1. we'll need to allocate a different wc array for polling mode,\n" "> perhaps a smaller one?\n" "> 2. Export __ib_process_cq (in some form) with an option to pass in a wc\n" "> array.\n" "> 3. Simply not support non-selective polling but it seems like a shame...\n" - ">=20\n" + "> \n" "> Any thoughts?\n" "\n" "I doubt it is possible to come up with an algorithm that recognizes whether\n" "or not two different ib_process_cq() calls are serialized. So the\n" - "ib_process_cq() caller will have to provide that information. How about add=\n" - "ing\n" + "ib_process_cq() caller will have to provide that information. How about adding\n" "an ib_wc array argument to ib_process_cq() and modifying __ib_process_cq()\n" "such that it uses that array if specified and cq->wc otherwise?\n" "\n" - Bart.= + Bart. -50abfe7a633515881ebc62f15f6372ddeef9cf2fc449609f615cbd6d622813d3 +803d98a8fdf09f4ff77aa01af0038ce0c5477348bf6987a54e02886def19439e
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.