* Re: RDMA developer gatherings around Kernel Summit and Linux Plumbers in Santa Fe
From: Christoph Lameter @ 2016-10-05 7:45 UTC (permalink / raw)
To: Atchley, Scott
Cc: Christoph Hellwig, Linux RDMA Mailing List,
ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
Jason Gunthorpe,
john.fleck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Doug Ledford,
Coulter, Susan K, shewa-YOWKrPYUwWM@public.gmane.org
In-Reply-To: <7BAAE610-98A0-47FC-993B-77401AA32F4A-1Heg1YXhbW8@public.gmane.org>
The point of the session will be to allow communication about the
different viewpoints on the subject matter of Dual Licensing. Maybe we can
come to some agreements that will allow us to move forward in a better way
with this. More communication may also help to clear up a couple of issues
and complaints. I certainly wish that Christoph Hellwig would be there to
talk about his views and also Susan Coulter as representing the OFA point
of view.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RDMA developer gatherings around Kernel Summit and Linux Plumbers in Santa Fe
From: Christoph Lameter @ 2016-10-05 7:42 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Weiny, Ira, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Jason Gunthorpe, Fleck, John, Doug Ledford,
skc-YOWKrPYUwWM@public.gmane.org,
shewa-YOWKrPYUwWM@public.gmane.org
In-Reply-To: <20161005060650.GA9282-2ukJVAZIZ/Y@public.gmane.org>
On Wed, 5 Oct 2016, Leon Romanovsky wrote:
> On Tue, Oct 04, 2016 at 06:36:56PM +0000, Weiny, Ira wrote:
> > Christoph,
> >
> > I just want to be sure that the Tuesday session at LPC is located at the Community Convention Center:
> >
> > Sante Fe Community Convention Center
> > 201 W. Marcy Street
> > Santa Fe, New Mexico 87501
> > United States
> >
> > Or is that also at the Hilton?
>
> It should be at the LPC location.
> https://linuxplumbersconf.org/2016/ocw/events/LPC2016/schedule#day_2016_11_01
> https://linuxplumbersconf.org/2016/ocw/events/LPC2016/tracks/609
Correct. Sorry did not notice it before. The LPC and thus the RDMA
workshop is at the convention centre.
We are looking for topics that people are interested in discussing and for
volunteers that can lead these discussions. Will give it a few days and
if we do not have enough then we will begin asking key people to take on
certain subjects.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller
From: Christoph Hellwig @ 2016-10-05 6:37 UTC (permalink / raw)
To: Parav Pandit
Cc: Tejun Heo, Leon Romanovsky, Jason Gunthorpe, Christoph Hellwig,
Matan Barak, cgroups, linux-doc, Linux Kernel Mailing List,
linux-rdma, Li Zefan, Johannes Weiner, Doug Ledford, Liran Liss,
Hefty, Sean, Haggai Eran, Jonathan Corbet, james.l.morris, serge,
Or Gerlitz, Andrew Morton, linux-security-module
In-Reply-To: <CAG53R5VqQ6UzsuzcovsD+ufv3HaEQEbUpaf3kDo4zLOrAf__8A@mail.gmail.com>
FYI, the patches look fine to me:
Acked-by: Christoph Hellwig <hch@lst.de>
but we're past the merge window for 4.9 now unfortunately.
^ permalink raw reply
* Re: [PATCH] ibacm: move Documentation to Documentation/
From: Leon Romanovsky @ 2016-10-05 6:14 UTC (permalink / raw)
To: Hefty, Sean
Cc: Jason Gunthorpe, Christoph Hellwig, Christoph Hellwig,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373AB092424-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 968 bytes --]
On Mon, Oct 03, 2016 at 06:04:09PM +0000, Hefty, Sean wrote:
> > > > Who is merging patches that are submitted to the mailing list?
> > > > AFAIK, I don't have write access to the repo.
> >
> > Doug and Leon - however I belive Leon is on a break right now.
> >
> > Sean, do you want write access too?
>
> Either way, really. I could merge in changes to ibacm and librdmacm, but those haven't gotten many updates recently. So, if Doug is already going to pull in mailing list patches for verbs, I'm fine with him pulling those changes in as well.
I was OOO in last days and didn't handle anything :).
In a day or two, I'll get an access to properly mark status
of the patches in patchworks and will be more responsive.
Thanks
>
> - Sean
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: RQ overflow seen running isert traffic
From: Sagi Grimberg @ 2016-10-05 6:14 UTC (permalink / raw)
To: Potnuri Bharat Teja; +Cc: swise, target-devel, nab, linux-rdma
In-Reply-To: <20160927070157.GA13140@chelsio.com>
> Hi Sagi,
Hey Baharat,
Sorry for the late response, its the holiday
season in Israel...
> I've been trying to understand the isert functionality with respect to
> RDMA Receive Queue sizing and Queue full handling. Here is the problem
> is see with iw_cxgb4:
>
> After running few minutes of iSER traffic with iw_cxgb4, I am seeing
> post receive failures due to receive queue full returning -ENOMEM.
> In case of iw_cxgb4 the RQ size is 130 with qp attribute max_recv_wr = 129,
> passed down by isert to iw_cxgb4.isert decides on max_recv_wr as 129 based
> on (ISERT_QP_MAX_RECV_DTOS = ISCSI_DEF_XMIT_CMDS_MAX = 128) + 1.
That's correct.
>
> My debug suggests that at some point isert tries to post more than
> 129 receive WRs into the RQ and fails as the queue is full already. From
> the code most of the recv wr are posted only after a recieve completion,
> but few datain operations(isert_put_datain()) are done independent of
> receive completions.
Interesting. I suspect that this issue haven't come up is that
the devices I used to test with allocate the send/recv queues in
the next power of 2 (which would be 256) which was enough to hide
this I guess...
We repost the recv buffer under the following conditions:
1. We are queueing data + response (datain) or just response (dataout)
and we are done with the recv buffer.
2. We got a unsolicited dataout.
Can you please turn off unsolicited dataouts and see if this
still happen? (InitialR2T=Yes)
> In fact the last WR failed to post in to RQ is from
> isert_put_datain() through target_complete_ok_work(). CQ stats at the
> time of failure shows the cq polled to empty.
That is strange, each scsi command should trigger iscsit_queue_data_in
just once. Can you provide evidence of a command that triggers it more
than once?
Another possible reason is that we somehow get to put_data_in and
put_response for the same command (which we should never do because
we handle the response in put_data_in).
Thanks for reporting.
Sagi.
^ permalink raw reply
* Re: RDMA developer gatherings around Kernel Summit and Linux Plumbers in Santa Fe
From: Leon Romanovsky @ 2016-10-05 6:06 UTC (permalink / raw)
To: Weiny, Ira
Cc: Christoph Lameter,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Jason Gunthorpe, Fleck, John, Doug Ledford,
skc-YOWKrPYUwWM@public.gmane.org,
shewa-YOWKrPYUwWM@public.gmane.org
In-Reply-To: <2807E5FD2F6FDA4886F6618EAC48510E24EF39A6-8k97q/ur5Z2krb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3301 bytes --]
On Tue, Oct 04, 2016 at 06:36:56PM +0000, Weiny, Ira wrote:
> Christoph,
>
> I just want to be sure that the Tuesday session at LPC is located at the Community Convention Center:
>
> Sante Fe Community Convention Center
> 201 W. Marcy Street
> Santa Fe, New Mexico 87501
> United States
>
> Or is that also at the Hilton?
It should be at the LPC location.
https://linuxplumbersconf.org/2016/ocw/events/LPC2016/schedule#day_2016_11_01
https://linuxplumbersconf.org/2016/ocw/events/LPC2016/tracks/609
>
> Thanks,
> Ira
>
> > -----Original Message-----
> > From: Christoph Lameter [mailto:cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org]
> > Sent: Tuesday, October 04, 2016 2:16 AM
> > To: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Cc: Weiny, Ira <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; Jason Gunthorpe
> > <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>; Fleck, John <john.fleck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>;
> > leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>; skc-YOWKrPYUwWM@public.gmane.org;
> > shewa-YOWKrPYUwWM@public.gmane.org
> > Subject: RDMA developer gatherings around Kernel Summit and Linux
> > Plumbers in Santa Fe
> >
> > We now have confirmation about the meetings related to the KS and LPC.
> > The events will be held at the:
> >
> > Hilton Santa Fe
> > 100 Sandoval St.
> > Santa Fe, NM 87501
> > Phone: (505)988-2811
> >
> > We meet specifically on the subject matter of RDMA two days:
> >
> > - RDMA workshop on Tuesday, 1st of November
> >
> > Meeting in Sweeney B 9am till 5pm.
> > See
> > http://linuxplumbersconf.org/2016/ocw/events/LPC2016/tracks/609
> >
> > This is part of the Kernel Summit and the Linux Plumbers
> > Conference. Only open to KS and LPC attendees with an invitation.
> >
> > - RDMA Summit on Saturday the 5th of November
> >
> > Meeting in the Canyon Ballroom 9am till 4pm.
> >
> > This event is sponsored by the Open Fabrics Alliance and will be
> > open to all
> >
> >
> > We think the workshop could be focusing more on the technical topics (some
> > of which could be carried over to Saturday if necessary because we have
> > more time then. The "Summit" would also be including management issues,
> > long range plans and OFA related material. We will summarize what
> > happened on Tuesday for those who were not able to participate earlier.
> >
> > Each day we thought we could cover 6 subjects. 3 in the morning 3 in the
> > afternoon.
> >
> > Initial ideas for sessions:
> >
> > Workshop:
> > - New ioctl ABI and issues related to that
> > - Consolidated libraries. Closer integration of librdmacm to
> > libibverbs etc.
> > - Using standard network tools/techniques for IB interfaces.
> > - Debuggability and tracing (also can standard tools help here?)
> > - State of Multicast support
> > - Containers and RDMA
> >
> > Summit:
> > - Licensing (GPL vs. Dual licensed)
> > - Integration with other subsystems (GPUs, network, PCI etc ...)
> > - Roadmap and future of RDMA
> > - Leftover issues and TODO for consolidated library.
> > - Submission process for multi-subsystem drivers (f.e ROCE)
> >
> >
> > Feedback would be appreciated so that we can workout an agenda that is
> > useful for all participants.
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Purchase Inquiry
From: eric @ 2016-10-05 5:23 UTC (permalink / raw)
--
Good day,
Im Eric Cantona from MSGMED Trades Limited, Holland. I got a
recommendation of you from one of your customer, we are interested in
making some good order from your company.
please send us more information about your company for our ref.
1). Best FOB Prices with clear photos of your latest catalog
2). Lead-time (? days) for pre production samples.
3). Payment term ( LC or TT )
4). MOQ,ETD & ETA to Port Holland.
Have a wonderful day .
Best Regards,
Eric Cantona
Purchase Manager
TRADES Holland, S.L
301/302, Al Garhoud
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 4/7] blk-mq: Introduce blk_quiesce_queue() and blk_resume_queue()
From: Ming Lei @ 2016-10-05 4:32 UTC (permalink / raw)
To: Bart Van Assche
Cc: Jens Axboe, Christoph Hellwig, James Bottomley,
Martin K. Petersen, Mike Snitzer, Doug Ledford, Keith Busch,
linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <a11bb09a-6207-f4a8-cfd4-4fe5627c1700-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
On Wed, Oct 5, 2016 at 12:16 PM, Bart Van Assche
<bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> wrote:
> On 10/01/16 15:56, Ming Lei wrote:
>>
>> If we just call the rcu/srcu read lock(or the mutex) around .queue_rq(),
>> the
>> above code needn't to be duplicated any more.
>
>
> Hello Ming,
>
> Can you have a look at the attached patch? That patch uses an srcu read lock
> for all queue types, whether or not the BLK_MQ_F_BLOCKING flag has been set.
That is much cleaner now.
> Additionally, I have dropped the QUEUE_FLAG_QUIESCING flag. Just like
> previous versions, this patch has been tested.
I think the flag of QUEUE_FLAG_QUIESCING is still needed because we
have to set this flag to prevent new coming .queue_rq() from being run,
and synchronize_srcu() won't wait for completion of that at all (see
section of 'Update-Side Primitives' in [1]).
[1] https://lwn.net/Articles/202847/
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 4/7] blk-mq: Introduce blk_quiesce_queue() and blk_resume_queue()
From: Bart Van Assche @ 2016-10-05 4:16 UTC (permalink / raw)
To: Ming Lei
Cc: Jens Axboe, Christoph Hellwig, James Bottomley,
Martin K. Petersen, Mike Snitzer, Doug Ledford, Keith Busch,
linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-rdma@vger.kernel.org, linux-nvme@lists.infradead.org
In-Reply-To: <CACVXFVMY19vuDjsECg2uX0_y_K7DUaaGqXPX9PYiBy5sfXmAEw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 466 bytes --]
On 10/01/16 15:56, Ming Lei wrote:
> If we just call the rcu/srcu read lock(or the mutex) around .queue_rq(), the
> above code needn't to be duplicated any more.
Hello Ming,
Can you have a look at the attached patch? That patch uses an srcu read
lock for all queue types, whether or not the BLK_MQ_F_BLOCKING flag has
been set. Additionally, I have dropped the QUEUE_FLAG_QUIESCING flag.
Just like previous versions, this patch has been tested.
Thanks,
Bart.
[-- Attachment #2: 0001-blk-mq-Introduce-blk_mq_quiesce_queue.patch --]
[-- Type: text/x-patch, Size: 5211 bytes --]
>From 25f02ed7ab7b2308fd18b89d180c0c613e55d416 Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche@sandisk.com>
Date: Tue, 27 Sep 2016 10:52:36 -0700
Subject: [PATCH] blk-mq: Introduce blk_mq_quiesce_queue()
blk_mq_quiesce_queue() waits until ongoing .queue_rq() invocations
have finished. This function does *not* wait until all outstanding
requests have finished (this means invocation of request.end_io()).
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Ming Lei <tom.leiming@gmail.com>
Cc: Hannes Reinecke <hare@suse.com>
Cc: Johannes Thumshirn <jthumshirn@suse.de>
---
block/blk-mq.c | 40 ++++++++++++++++++++++++++++++++++------
include/linux/blk-mq.h | 3 +++
include/linux/blkdev.h | 1 +
3 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index d8c45de..38ae685 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -115,6 +115,23 @@ void blk_mq_unfreeze_queue(struct request_queue *q)
}
EXPORT_SYMBOL_GPL(blk_mq_unfreeze_queue);
+/**
+ * blk_mq_quiesce_queue() - wait until all ongoing queue_rq calls have finished
+ *
+ * Note: this function does not prevent that the struct request end_io()
+ * callback function is invoked. Additionally, it is not prevented that
+ * new queue_rq() calls occur unless the queue has been stopped first.
+ */
+void blk_mq_quiesce_queue(struct request_queue *q)
+{
+ struct blk_mq_hw_ctx *hctx;
+ unsigned int i;
+
+ queue_for_each_hw_ctx(q, hctx, i)
+ synchronize_srcu(&hctx->queue_rq_srcu);
+}
+EXPORT_SYMBOL_GPL(blk_mq_quiesce_queue);
+
void blk_mq_wake_waiters(struct request_queue *q)
{
struct blk_mq_hw_ctx *hctx;
@@ -789,11 +806,13 @@ static void __blk_mq_run_hw_queue(struct blk_mq_hw_ctx *hctx)
LIST_HEAD(rq_list);
LIST_HEAD(driver_list);
struct list_head *dptr;
- int queued;
+ int queued, srcu_idx;
if (unlikely(test_bit(BLK_MQ_S_STOPPED, &hctx->state)))
return;
+ srcu_idx = srcu_read_lock(&hctx->queue_rq_srcu);
+
WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) &&
cpu_online(hctx->next_cpu));
@@ -885,6 +904,8 @@ static void __blk_mq_run_hw_queue(struct blk_mq_hw_ctx *hctx)
**/
blk_mq_run_hw_queue(hctx, true);
}
+
+ srcu_read_unlock(&hctx->queue_rq_srcu, srcu_idx);
}
/*
@@ -1298,7 +1319,7 @@ static blk_qc_t blk_mq_make_request(struct request_queue *q, struct bio *bio)
const int is_flush_fua = bio->bi_opf & (REQ_PREFLUSH | REQ_FUA);
struct blk_map_ctx data;
struct request *rq;
- unsigned int request_count = 0;
+ unsigned int request_count = 0, srcu_idx;
struct blk_plug *plug;
struct request *same_queue_rq = NULL;
blk_qc_t cookie;
@@ -1341,7 +1362,7 @@ static blk_qc_t blk_mq_make_request(struct request_queue *q, struct bio *bio)
blk_mq_bio_to_request(rq, bio);
/*
- * We do limited pluging. If the bio can be merged, do that.
+ * We do limited plugging. If the bio can be merged, do that.
* Otherwise the existing request in the plug list will be
* issued. So the plug list will have one request at most
*/
@@ -1361,9 +1382,12 @@ static blk_qc_t blk_mq_make_request(struct request_queue *q, struct bio *bio)
blk_mq_put_ctx(data.ctx);
if (!old_rq)
goto done;
- if (!blk_mq_direct_issue_request(old_rq, &cookie))
- goto done;
- blk_mq_insert_request(old_rq, false, true, true);
+
+ srcu_idx = srcu_read_lock(&data.hctx->queue_rq_srcu);
+ if (blk_mq_direct_issue_request(old_rq, &cookie) != 0)
+ blk_mq_insert_request(old_rq, false, true, true);
+ srcu_read_unlock(&data.hctx->queue_rq_srcu, srcu_idx);
+
goto done;
}
@@ -1659,6 +1683,8 @@ static void blk_mq_exit_hctx(struct request_queue *q,
if (set->ops->exit_hctx)
set->ops->exit_hctx(hctx, hctx_idx);
+ cleanup_srcu_struct(&hctx->queue_rq_srcu);
+
blk_mq_unregister_cpu_notifier(&hctx->cpu_notifier);
blk_free_flush_queue(hctx->fq);
sbitmap_free(&hctx->ctx_map);
@@ -1741,6 +1767,8 @@ static int blk_mq_init_hctx(struct request_queue *q,
flush_start_tag + hctx_idx, node))
goto free_fq;
+ init_srcu_struct(&hctx->queue_rq_srcu);
+
return 0;
free_fq:
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index 368c460d..b2ccd3c 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -3,6 +3,7 @@
#include <linux/blkdev.h>
#include <linux/sbitmap.h>
+#include <linux/srcu.h>
struct blk_mq_tags;
struct blk_flush_queue;
@@ -41,6 +42,8 @@ struct blk_mq_hw_ctx {
struct blk_mq_tags *tags;
+ struct srcu_struct queue_rq_srcu;
+
unsigned long queued;
unsigned long run;
#define BLK_MQ_MAX_DISPATCH_ORDER 7
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index c47c358..8259d87 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -824,6 +824,7 @@ extern void __blk_run_queue(struct request_queue *q);
extern void __blk_run_queue_uncond(struct request_queue *q);
extern void blk_run_queue(struct request_queue *);
extern void blk_run_queue_async(struct request_queue *q);
+extern void blk_mq_quiesce_queue(struct request_queue *q);
extern int blk_rq_map_user(struct request_queue *, struct request *,
struct rq_map_data *, void __user *, unsigned long,
gfp_t);
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net-next 0/7] qed*: Add qedr infrastructure support,Re: [PATCH net-next 0/7] qed*: Add qedr infrastructure support
From: Doug Ledford @ 2016-10-05 3:09 UTC (permalink / raw)
To: David Miller
Cc: Yuval.Mintz, netdev, linux-rdma, Ram.Amrani, Michal.Kalderon,
Ariel.Elior
In-Reply-To: <20161004.195945.1239283105752882824.davem@davemloft.net>
[-- Attachment #1.1: Type: text/plain, Size: 370 bytes --]
On 10/4/2016 7:59 PM, David Miller wrote:
> From: Doug Ledford <dledford@redhat.com>
> Date: Tue, 4 Oct 2016 08:04:20 -0400
>
>> Are you going to merge this in 4.9 or is this going into net-next?
>
> 4.9, it will go into the pull request I send to Linus later today.
>
Got it, thanks.
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 0/7] qed*: Add qedr infrastructure support,Re: [PATCH net-next 0/7] qed*: Add qedr infrastructure support
From: David Miller @ 2016-10-04 23:59 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA
Cc: Yuval.Mintz-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Ram.Amrani-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8,
Michal.Kalderon-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8,
Ariel.Elior-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8
In-Reply-To: <ad89ec53-2355-e466-0ceb-92da51cc2a62-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
From: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date: Tue, 4 Oct 2016 08:04:20 -0400
> Are you going to merge this in 4.9 or is this going into net-next?
4.9, it will go into the pull request I send to Linus later today.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: RDMA developer gatherings around Kernel Summit and Linux Plumbers in Santa Fe
From: Weiny, Ira @ 2016-10-04 18:36 UTC (permalink / raw)
To: Christoph Lameter,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Jason Gunthorpe, Fleck, John,
leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Doug Ledford,
skc-YOWKrPYUwWM@public.gmane.org,
shewa-YOWKrPYUwWM@public.gmane.org
In-Reply-To: <alpine.DEB.2.20.1610040344500.11122-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
Christoph,
I just want to be sure that the Tuesday session at LPC is located at the Community Convention Center:
Sante Fe Community Convention Center
201 W. Marcy Street
Santa Fe, New Mexico 87501
United States
Or is that also at the Hilton?
Thanks,
Ira
> -----Original Message-----
> From: Christoph Lameter [mailto:cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org]
> Sent: Tuesday, October 04, 2016 2:16 AM
> To: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Weiny, Ira <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; Jason Gunthorpe
> <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>; Fleck, John <john.fleck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>;
> leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>; skc-YOWKrPYUwWM@public.gmane.org;
> shewa-YOWKrPYUwWM@public.gmane.org
> Subject: RDMA developer gatherings around Kernel Summit and Linux
> Plumbers in Santa Fe
>
> We now have confirmation about the meetings related to the KS and LPC.
> The events will be held at the:
>
> Hilton Santa Fe
> 100 Sandoval St.
> Santa Fe, NM 87501
> Phone: (505)988-2811
>
> We meet specifically on the subject matter of RDMA two days:
>
> - RDMA workshop on Tuesday, 1st of November
>
> Meeting in Sweeney B 9am till 5pm.
> See
> http://linuxplumbersconf.org/2016/ocw/events/LPC2016/tracks/609
>
> This is part of the Kernel Summit and the Linux Plumbers
> Conference. Only open to KS and LPC attendees with an invitation.
>
> - RDMA Summit on Saturday the 5th of November
>
> Meeting in the Canyon Ballroom 9am till 4pm.
>
> This event is sponsored by the Open Fabrics Alliance and will be
> open to all
>
>
> We think the workshop could be focusing more on the technical topics (some
> of which could be carried over to Saturday if necessary because we have
> more time then. The "Summit" would also be including management issues,
> long range plans and OFA related material. We will summarize what
> happened on Tuesday for those who were not able to participate earlier.
>
> Each day we thought we could cover 6 subjects. 3 in the morning 3 in the
> afternoon.
>
> Initial ideas for sessions:
>
> Workshop:
> - New ioctl ABI and issues related to that
> - Consolidated libraries. Closer integration of librdmacm to
> libibverbs etc.
> - Using standard network tools/techniques for IB interfaces.
> - Debuggability and tracing (also can standard tools help here?)
> - State of Multicast support
> - Containers and RDMA
>
> Summit:
> - Licensing (GPL vs. Dual licensed)
> - Integration with other subsystems (GPUs, network, PCI etc ...)
> - Roadmap and future of RDMA
> - Leftover issues and TODO for consolidated library.
> - Submission process for multi-subsystem drivers (f.e ROCE)
>
>
> Feedback would be appreciated so that we can workout an agenda that is
> useful for all participants.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller
From: Parav Pandit @ 2016-10-04 18:19 UTC (permalink / raw)
To: Tejun Heo
Cc: Leon Romanovsky, Jason Gunthorpe, Christoph Hellwig, Matan Barak,
cgroups-u79uwXL29TY76Z2rM5mHXA, linux-doc-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Li Zefan, Johannes Weiner, Doug Ledford, Liran Liss, Hefty, Sean,
Haggai Eran, Jonathan Corbet,
james.l.morris-QHcLZuEGTsvQT0dZR+AlfA,
serge-A9i7LUbDfNHQT0dZR+AlfA, Or Gerlitz, Andrew Morton,
linux-security-module-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAG53R5WMuojhzFGmqk6nHfypd9Hq4dGsWRKjtUyMZ=RezU-LhQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Doug,
I am still waiting for Leon to provide his comments if any on rdma cgroup.
>From other email context, he was on vacation last week.
While we wait for his comments, I wanted to know your view of this
patchset in 4.9 merge window.
To summarize the discussion that happened in two threads.
[1] Ack by Tejun, asking for review from rdma list
[2] quick review by Christoph on patch-v11 (patch 12 has only typo corrections)
[3] Christoph's ack on architecture of rdma cgroup and fitting it with ABI
[4] My response on Matan's query on RSS indirection table
[5] Response from Intel on their driver support for Matan's query
[6] Christoph's point on architecture, which we are following in new
ABI and current ABI
I have reviewed recent patch [7] from Matan where I see IB verbs
objects are still handled through common path as suggested by
Christoph.
I do not see any issues with rdma cgroup patchset other than it requires rebase.
Am I missing something?
Can you please help me - What would be required to merge it to 4.9?
[1] https://lkml.org/lkml/2016/8/31/494
[2] https://lkml.org/lkml/2016/8/25/146
[3] https://lkml.org/lkml/2016/9/10/175
[4] https://lkml.org/lkml/2016/9/14/221
[5] https://lkml.org/lkml/2016/9/19/571
[6] http://www.spinics.net/lists/linux-rdma/msg40337.html
[7] email subject: [RFC ABI V4 0/7] SG-based RDMA ABI Proposal
Regards,
Parav Pandit
On Wed, Sep 21, 2016 at 9:32 PM, Parav Pandit <pandit.parav-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi Tejun,
>
> On Wed, Sep 21, 2016 at 7:56 PM, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> Hello, Parav.
>>
>> On Wed, Sep 21, 2016 at 10:13:38AM +0530, Parav Pandit wrote:
>>> We have completed review from Tejun, Christoph.
>>> HFI driver folks also provided feedback for Intel drivers.
>>> Matan's also doesn't have any more comments.
>>>
>>> If possible, if you can also review, it will be helpful.
>>>
>>> I have some more changes unrelated to cgroup in same files in both the git tree.
>>> Pushing them now either results into merge conflict later on for
>>> Doug/Tejun, or requires rebase and resending patch.
>>> If you can review, we can avoid such rework.
>>
>> My impression of the thread was that there doesn't seem to be enough
>> of consensus around how rdma resources should be defined. Is that
>> part agreed upon now?
>>
>
> We ended up discussing few points on different thread [1].
>
> There was confusion on how some non-rdma/non-IB drivers would work
> with rdma cgroup from Matan.
> Christoph explained how they don't fit in the rdma subsystem and
> therefore its not prime target to addess.
> Intel driver maintainer Denny also acknowledged same on [2].
> IB compliant drivers of Intel support rdma cgroup as explained in [2].
> With that usnic and Intel psm drivers falls out of rdma cgroup support
> as they don't fit very well in the verbs definition.
>
> [1] https://www.spinics.net/lists/linux-rdma/msg40340.html
> [2] http://www.spinics.net/lists/linux-rdma/msg40717.html
>
> I will wait for Leon's review comments if he has different view on architecture.
> Back in April when I met face-to-face to Leon and Haggai, Leon was in
> support to have kernel defined the rdma resources as suggested by
> Christoph and Tejun instead of IB/RDMA subsystem.
> I will wait for his comments if his views have changed with new uAPI
> taking shape.
^ permalink raw reply
* Re: iscsi_trx going into D state
From: Robert LeBlanc @ 2016-10-04 16:39 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Hannes Reinecke, Johannes Thumshirn,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161004114642.GA2377-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Do you want me to try this patch or wait for some of the suggestions
Christoph brought up to be Incorporated?
----------------
Robert LeBlanc
PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
On Tue, Oct 4, 2016 at 5:46 AM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> On Tue, Oct 04, 2016 at 11:11:18AM +0200, Hannes Reinecke wrote:
>> Hmm. Looking at the code it looks as we might miss some calls to
>> 'complete'. Can you try with the attached patch?
>
> That only looks slightly better than the original. What this really
> needs is a waitqueue and and waitevent on sess->ncon. Although
> that will need a bit more refactoring around that code. There also
> are a few more ovbious issues around it, e.g. iscsit_close_connection
> needs to use atomic_dec_and_test on sess->nconn instead of having
> separate atomic_dec and atomic_read calls, and a lot of the 0 or 1
> atomic_ts in this code should be replaced with atomic bitops.
>
> Btw, there also was a fix from Lee in this area that added a missing
> wakeup, make sure your tree already has that.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: RDMA developer gatherings around Kernel Summit and Linux Plumbers in Santa Fe
From: Atchley, Scott @ 2016-10-04 15:26 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Christoph Lameter, Linux RDMA Mailing List,
ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
Jason Gunthorpe,
john.fleck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Doug Ledford,
Coulter, Susan K, shewa-YOWKrPYUwWM@public.gmane.org
In-Reply-To: <20161004124513.GA12483-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> On Oct 4, 2016, at 8:45 AM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
>
>> Summit:
>> - Licensing (GPL vs. Dual licensed)
>
> So we're finally going to bring OFA in front of an anti-trust code
> to bring down their silly Dual licensing requirement for their members.
> Can't see any other reason why this would be brought up again, as they
> obviously can't force anyone else under a dual licensing scheme
> requirement for Linux code.
What is the purpose of this comment?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] IB/srp: export reset-host via sysfs
From: Gioh Kim @ 2016-10-04 15:22 UTC (permalink / raw)
To: Bart Van Assche, dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <af0d75ef-734d-2cdf-05d8-bf4cd9c59ef9-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
On 04.10.2016 16:24, Bart Van Assche wrote:
> On 10/04/16 07:00, Gioh Kim wrote:
>> Standard SCSI device has host_reset sysfs interface.
>> This patch exports the host_reset interface for upper layer.
>>
>> Signed-off-by: Gioh Kim <gi-oh.kim-EIkl63zCoXaH+58JC4qpiA@public.gmane.org>
>> ---
>> drivers/infiniband/ulp/srp/ib_srp.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
>> b/drivers/infiniband/ulp/srp/ib_srp.c
>> index 3322ed7..92e6c3f 100644
>> --- a/drivers/infiniband/ulp/srp/ib_srp.c
>> +++ b/drivers/infiniband/ulp/srp/ib_srp.c
>> @@ -2628,6 +2628,15 @@ static int srp_reset_device(struct scsi_cmnd
>> *scmnd)
>> return SUCCESS;
>> }
>>
>> +static int srp_scsi_host_reset(struct Scsi_Host *shost, int reset_type)
>> +{
>> + struct srp_target_port *target = host_to_target(shost);
>> +
>> + shost_printk(KERN_EMERG, target->scsi_host, PFX "SRP reset_host
>> called\n");
>> +
>> + return srp_reconnect_rport(target->rport);
>> +}
>> +
>> static int srp_reset_host(struct scsi_cmnd *scmnd)
>> {
>> struct srp_target_port *target =
>> host_to_target(scmnd->device->host);
>> @@ -2858,6 +2867,7 @@ static struct scsi_host_template srp_template = {
>> .use_clustering = ENABLE_CLUSTERING,
>> .shost_attrs = srp_host_attrs,
>> .track_queue_depth = 1,
>> + .host_reset = srp_scsi_host_reset,
>> };
>
> Hello Gioh,
>
> A patch description should not only explain what is changed but also
> why a change is considered useful. Why do you think it would be useful
> to allow users to trigger a call of srp_reconnect_rport() through
> sysfs instead of using the functionality that is already available
> through sysfs, namely removing a SCSI host and reconnecting?
Hello Bart,
It's my mistake to miss 0000-cover-letter.patch file including description.
I'm testing SCSI devices which are exported by the remote servers via IB
network. I know that SCSI error handling mechanism calls reset-host when
something wrong happens. But the SCSI error handling tries sending ABORT
commands and other actions before resetting host. I found that those
ABORT commands could generate more stress on the remove server. So I
need to reset SCSI host (which mean reconnecting) when the remote server
starts to become slow or have some problem to handle IO.
And I think I can use some utilities for SCSI device, such like sg3
utils, to handle srp connection.
Thank you for your reply.
Best regards,
Gioh Kim
>
> Bart.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] IB/srp: export reset-host via sysfs
From: Bart Van Assche @ 2016-10-04 14:24 UTC (permalink / raw)
To: Gioh Kim, dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1475589609-26451-1-git-send-email-gi-oh.kim-EIkl63zCoXaH+58JC4qpiA@public.gmane.org>
On 10/04/16 07:00, Gioh Kim wrote:
> Standard SCSI device has host_reset sysfs interface.
> This patch exports the host_reset interface for upper layer.
>
> Signed-off-by: Gioh Kim <gi-oh.kim-EIkl63zCoXaH+58JC4qpiA@public.gmane.org>
> ---
> drivers/infiniband/ulp/srp/ib_srp.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c
> index 3322ed7..92e6c3f 100644
> --- a/drivers/infiniband/ulp/srp/ib_srp.c
> +++ b/drivers/infiniband/ulp/srp/ib_srp.c
> @@ -2628,6 +2628,15 @@ static int srp_reset_device(struct scsi_cmnd *scmnd)
> return SUCCESS;
> }
>
> +static int srp_scsi_host_reset(struct Scsi_Host *shost, int reset_type)
> +{
> + struct srp_target_port *target = host_to_target(shost);
> +
> + shost_printk(KERN_EMERG, target->scsi_host, PFX "SRP reset_host called\n");
> +
> + return srp_reconnect_rport(target->rport);
> +}
> +
> static int srp_reset_host(struct scsi_cmnd *scmnd)
> {
> struct srp_target_port *target = host_to_target(scmnd->device->host);
> @@ -2858,6 +2867,7 @@ static struct scsi_host_template srp_template = {
> .use_clustering = ENABLE_CLUSTERING,
> .shost_attrs = srp_host_attrs,
> .track_queue_depth = 1,
> + .host_reset = srp_scsi_host_reset,
> };
Hello Gioh,
A patch description should not only explain what is changed but also why
a change is considered useful. Why do you think it would be useful to
allow users to trigger a call of srp_reconnect_rport() through sysfs
instead of using the functionality that is already available through
sysfs, namely removing a SCSI host and reconnecting?
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC] IB/srp: export reset-host via sysfs
From: Gioh Kim @ 2016-10-04 14:00 UTC (permalink / raw)
To: bart.vanassche, dledford, sean.hefty, hal.rosenstock
Cc: linux-rdma, linux-kernel, Gioh Kim
Standard SCSI device has host_reset sysfs interface.
This patch exports the host_reset interface for upper layer.
Signed-off-by: Gioh Kim <gi-oh.kim@profitbricks.com>
---
drivers/infiniband/ulp/srp/ib_srp.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c
index 3322ed7..92e6c3f 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -2628,6 +2628,15 @@ static int srp_reset_device(struct scsi_cmnd *scmnd)
return SUCCESS;
}
+static int srp_scsi_host_reset(struct Scsi_Host *shost, int reset_type)
+{
+ struct srp_target_port *target = host_to_target(shost);
+
+ shost_printk(KERN_EMERG, target->scsi_host, PFX "SRP reset_host called\n");
+
+ return srp_reconnect_rport(target->rport);
+}
+
static int srp_reset_host(struct scsi_cmnd *scmnd)
{
struct srp_target_port *target = host_to_target(scmnd->device->host);
@@ -2858,6 +2867,7 @@ static struct scsi_host_template srp_template = {
.use_clustering = ENABLE_CLUSTERING,
.shost_attrs = srp_host_attrs,
.track_queue_depth = 1,
+ .host_reset = srp_scsi_host_reset,
};
static int srp_sdev_count(struct Scsi_Host *host)
--
2.5.0
^ permalink raw reply related
* [PULL REQUEST] Please pull rdma.git
From: Doug Ledford @ 2016-10-04 13:50 UTC (permalink / raw)
To: Torvalds, Linus, linux-rdma
[-- Attachment #1.1: Type: text/plain, Size: 7017 bytes --]
Hi Linus,
This is the first pull request of the 4.9 merge window for the RDMA
subsystem. It is only the hfi1 driver. It had dependencies on code
that only landed late in the 4.7-rc cycle (around 4.7-rc7), so putting
this with my other for-next code would have create an ugly merge of lot
of 4.7-rc stuff. For that reason, it's being submitted individually.
It's been through 0day and linux-next. I'll be sending a different
topic branch through linux-next today and will make a new pull request
once you've picked this one up. I expect there will be three or four
pull requests this cycle as I'm somewhat splitting things up into these
broad groups:
1) hfi1 driver update (needed late 4.7-rc code)
2) hns-roce driver (new driver, still waiting on last few patch
approvals from netdev@)
3) rest of the core stack (needs to wait until after DaveM's tree has
been pulled because it needed to be based on his net-next tree from
around 4.7-rc4)
4) there are four other brand new drivers on the list undergoing review,
and it's possible some of them might complete review in time to be sent,
if so, they will be separate pull requests
Here's the boilerplate for this pull request:
The following changes since commit e4618d40eb3dc1a6d1f55f7150ea25bb23ab410a:
IB/rdmavt: Don't vfree a kzalloc'ed memory region (2016-09-16 14:14:23
-0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git
tags/for-linus
for you to fetch changes up to 61347fa6087884305ea4a3a04501839fdb68dc76:
IB/rdmavt: Trivial function comment corrected. (2016-10-03 10:55:27 -0400)
----------------------------------------------------------------
First pull request of the 4.9 merge window
- Updates to hfi1 driver
----------------------------------------------------------------
Dean Luick (6):
IB/hfi1: Move serdes tune inside link start function
IB/hfi1: Extend i2c timeout
IB/hfi1: Act on external device timeout
IB/hfi1: Restore EPROM read ability
IB/hfi1: Add ability to read platform config from the EPROM
IB/hfi1: Use EPROM platform configuration read
Dennis Dalessandro (3):
IB/qib: Remove qpt_mask global
IB/hfi1: Cleanup tasklet refs in comments
IB/hfi1: Remove unused variable from devdata
Harish Chegondi (2):
IB/hfi1: Fix the count of user packets submitted to an SDMA engine
IB/hfi1: Adjust hardware buffering parameter
Jakub Pawlak (1):
IB/hfi1: Fix resource release in context allocation
Jianxin Xiong (2):
IB/hfi1: Increase default settings of max_cqes and max_qps
IB/hfi1: Update SMA ingress checks for response packets
Mike Marciniszyn (12):
IB/rdmavt: Add functions to get and release QP references
IB/rdmavt, IB/qib, IB/hfi1: Use new QP put get routines
IB/core: Add ib headers for general use
IB/qib,IB/hfi: Use core common header file
IB/rdmavt: Correct sparse annotation
IB/hfi1: Move iowait_init() to priv allocate
IB/rdmavt: Move reset calldown to reset path
IB/rdmavt: Add qp init function
IB/rdmavt, IB/hfi1: Add lockdep asserts for lock debug
IB/hfi1: Consolidate pio control masks into single definition
IB/hfi1: Fix defered ack race with qp destroy
IB/hfi1: Fix trace of atomic ack
Parav Pandit (1):
IB/rdmavt: Trivial function comment corrected.
Sebastian Sanchez (3):
IB/hfi1: Remove filtering of Set(PkeyTable) in HFI SMA
IB/hfi1: Do not read more than a SGE length
IB/hfi1: Combine shift copy and byte copy for SGE reads
Tadeusz Struk (6):
IB/hfi1: Fix locking scheme for affinity settings
IB/hfi1: Add sysfs interface for affinity setup
IB/hfi1: Add a new VL sysfs attribute for sdma engines
IB/hfi1: Add irq affinity notification handler
IB/hfi1: Add new debugfs sdma_cpu_list file
IB/hfi1: Document new sysfs entries for hfi1 driver
Tymoteusz Kielan (1):
IB/hfi1: Fix user-space buffers mapping with IOMMU enabled
Documentation/infiniband/sysfs.txt | 30 +++
drivers/infiniband/hw/hfi1/affinity.c | 203 ++++++++++++----
drivers/infiniband/hw/hfi1/affinity.h | 3 +-
drivers/infiniband/hw/hfi1/chip.c | 57 +++--
drivers/infiniband/hw/hfi1/chip.h | 8 +-
drivers/infiniband/hw/hfi1/common.h | 8 -
drivers/infiniband/hw/hfi1/debugfs.c | 38 +++
drivers/infiniband/hw/hfi1/driver.c | 35 ++-
drivers/infiniband/hw/hfi1/eprom.c | 185 +++++++++++++++
drivers/infiniband/hw/hfi1/eprom.h | 4 +-
drivers/infiniband/hw/hfi1/file_ops.c | 59 +++--
drivers/infiniband/hw/hfi1/hfi.h | 22 +-
drivers/infiniband/hw/hfi1/init.c | 45 ++--
drivers/infiniband/hw/hfi1/mad.c | 7 -
drivers/infiniband/hw/hfi1/pio.c | 20 +-
drivers/infiniband/hw/hfi1/pio.h | 2 +-
drivers/infiniband/hw/hfi1/pio_copy.c | 246 +++++--------------
drivers/infiniband/hw/hfi1/platform.c | 32 ++-
drivers/infiniband/hw/hfi1/qp.c | 32 +--
drivers/infiniband/hw/hfi1/qsfp.c | 2 +-
drivers/infiniband/hw/hfi1/rc.c | 146 ++++++------
drivers/infiniband/hw/hfi1/ruc.c | 10 +-
drivers/infiniband/hw/hfi1/sdma.c | 377
+++++++++++++++++++++++++++++-
drivers/infiniband/hw/hfi1/sdma.h | 13 +-
drivers/infiniband/hw/hfi1/sysfs.c | 103 +++++++-
drivers/infiniband/hw/hfi1/trace.c | 31 +--
drivers/infiniband/hw/hfi1/trace_ctxts.h | 13 +-
drivers/infiniband/hw/hfi1/trace_ibhdrs.h | 14 +-
drivers/infiniband/hw/hfi1/trace_rx.h | 4 +-
drivers/infiniband/hw/hfi1/uc.c | 15 +-
drivers/infiniband/hw/hfi1/ud.c | 61 +++--
drivers/infiniband/hw/hfi1/user_sdma.c | 40 ++--
drivers/infiniband/hw/hfi1/verbs.c | 60 +++--
drivers/infiniband/hw/hfi1/verbs.h | 93 +-------
drivers/infiniband/hw/hfi1/verbs_txreq.c | 2 +-
drivers/infiniband/hw/qib/qib.h | 2 +-
drivers/infiniband/hw/qib/qib_driver.c | 7 +-
drivers/infiniband/hw/qib/qib_iba7322.c | 2 +-
drivers/infiniband/hw/qib/qib_qp.c | 13 +-
drivers/infiniband/hw/qib/qib_rc.c | 73 +++---
drivers/infiniband/hw/qib/qib_ruc.c | 4 +-
drivers/infiniband/hw/qib/qib_uc.c | 6 +-
drivers/infiniband/hw/qib/qib_ud.c | 6 +-
drivers/infiniband/hw/qib/qib_verbs.c | 16 +-
drivers/infiniband/hw/qib/qib_verbs.h | 94 +-------
drivers/infiniband/sw/rdmavt/qp.c | 119 ++++++----
include/rdma/ib_hdrs.h | 178 ++++++++++++++
include/rdma/rdmavt_qp.h | 19 ++
48 files changed, 1660 insertions(+), 899 deletions(-)
create mode 100644 include/rdma/ib_hdrs.h
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: RDMA developer gatherings around Kernel Summit and Linux Plumbers in Santa Fe
From: Christoph Hellwig @ 2016-10-04 12:45 UTC (permalink / raw)
To: Christoph Lameter
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
ira.weiny-ral2JQCrhuEAvxtiuMwx3w, Jason Gunthorpe,
john.fleck-ral2JQCrhuEAvxtiuMwx3w, leon-DgEjT+Ai2ygdnm+yROfE0A,
Doug Ledford, skc-YOWKrPYUwWM, shewa-YOWKrPYUwWM
In-Reply-To: <alpine.DEB.2.20.1610040344500.11122-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
> Summit:
> - Licensing (GPL vs. Dual licensed)
So we're finally going to bring OFA in front of an anti-trust code
to bring down their silly Dual licensing requirement for their members.
Can't see any other reason why this would be brought up again, as they
obviously can't force anyone else under a dual licensing scheme
requirement for Linux code.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: PROBLEM: nvmet rxe : Kernel oops when running nvmf IO over rdma_rxe
From: Stephen Bates @ 2016-10-04 12:42 UTC (permalink / raw)
To: Sagi Grimberg
Cc: linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, hch-jcswGhMUV9g,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, monis-VPRAkNaXOzVWk0Htik3J/w,
yonatanc-VPRAkNaXOzVWk0Htik3J/w
In-Reply-To: <e50c485a-00b0-e896-34de-856714fcb454-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
Thanks for taking a look at this Sagi. BTW I did see the nvme connect
seemed pretty stable but I will do some longer waits between the
connect and the IO steps to see if I get a panic...
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from drivers/nvme/target/nvmet-rdma.ko...done.
> (gdb) l *(nvmet_rdma_free_rsps+0x80)
> 0xa20 is in nvmet_rdma_free_rsps (drivers/nvme/target/rdma.c:430).
> 425 int i, nr_rsps = queue->recv_queue_size * 2;
> 426
> 427 for (i = 0; i < nr_rsps; i++) {
> 428 struct nvmet_rdma_rsp *rsp = &queue->rsps[i];
> 429
> 430 list_del(&rsp->free_list);
> 431 nvmet_rdma_free_rsp(ndev, rsp);
> 432 }
> 433 kfree(queue->rsps);
> 434 }
> (gdb)
> --
Oh I did addr2line on the [<ffffffff814537b9>]
nvmet_rdma_free_queue+0x49/0x90 at the top of the Call Trace. I see
you looked up the RIP line (which probably makes more sense ;-)).
>
> Anyway, this looks like a use-after-free condition. The strange thing
> is that we don't see any queues being freed twice (we have a print
> there)...
>
> I suspect that either we have some problems with the draining logic in
> rxe or, we uncovered a bug in nvmet-rdma that is triggered with rxe on
> a VM (back when I tested this I didn't get this, so things must have
> changed...)
OK I will see if I can get more information on what we might be using
after the free and report back. If anyone on the RXE side has any
ideas please chip in ;-).
Cheers
Stephen
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 0/7] qed*: Add qedr infrastructure support
From: Doug Ledford @ 2016-10-04 12:04 UTC (permalink / raw)
To: David Miller, Yuval.Mintz
Cc: netdev, linux-rdma, Ram.Amrani, Michal.Kalderon, Ariel.Elior
In-Reply-To: <20161003.232446.1827173235395776859.davem@davemloft.net>
[-- Attachment #1.1: Type: text/plain, Size: 2088 bytes --]
On 10/3/2016 11:24 PM, David Miller wrote:
> From: Yuval Mintz <Yuval.Mintz@caviumnetworks.com>
> Date: Sat, 1 Oct 2016 21:59:54 +0300
>
>> In the last couple of weeks we've been sending RFCs for the qedr
>> driver - the RoCE driver for QLogic FastLinQ 4xxxx line of adapters.
>> Latest RFC can be found at [1].
>>
>> At Doug's advice [2], we've decided to split the series into two:
>> - first part contains the qed backbone that's necessary for all the
>> configurations relating to the qedr driver, as well as the qede
>> infrastructure that is used for communication between the qedr and qede.
>> - Second part consists of the actual qedr driver and introduces almost
>> no changes to qed/qede.
>>
>> This is the first of said two parts. The second half would be sent
>> later this week.
>>
>> The only 'oddity' in the devision are the Kconfig options -
>> As this series introduces both LL2 and QEDR-based logic in qed/qede,
>> I wanted to add the CONFIG_INFINIBAND_QEDR option here [with default n].
>> Otherwise, a lot of the code introduced would be dead-code [won't even
>> be compiled] until qedr is accepted.
>> As a result I've placed the config option in an odd place - under
>> qlogic's Kconfig. The second series would then remove that option
>> and add it in its correct place under the infiniband Kconfig.
>> [I'm fine with pushing it there to begin with, but I didn't want to
>> 'contaminate' non-qlogic configuration files with half-baked options].
>>
>> Dave - I don't think you were E-mailed with Doug's suggestion.
>> I think the notion was to have the two halves accepted side-by-side,
>> but actually the first has no dependency issues, so it's also
>> possible to simply take this first to net-next, and push the qedr
>> into rdma once it's merged. But it's basically up to you and Doug;
>> We'd align with whatever suits you best.
>
> I'll take this, series applied, thanks.
>
Are you going to merge this in 4.9 or is this going into net-next?
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: iscsi_trx going into D state
From: Christoph Hellwig @ 2016-10-04 11:46 UTC (permalink / raw)
To: Hannes Reinecke
Cc: Johannes Thumshirn, Robert LeBlanc, linux-rdma, linux-scsi
In-Reply-To: <5cfc7eb8-c59d-4b7a-3dee-99e17d72f251@suse.de>
On Tue, Oct 04, 2016 at 11:11:18AM +0200, Hannes Reinecke wrote:
> Hmm. Looking at the code it looks as we might miss some calls to
> 'complete'. Can you try with the attached patch?
That only looks slightly better than the original. What this really
needs is a waitqueue and and waitevent on sess->ncon. Although
that will need a bit more refactoring around that code. There also
are a few more ovbious issues around it, e.g. iscsit_close_connection
needs to use atomic_dec_and_test on sess->nconn instead of having
separate atomic_dec and atomic_read calls, and a lot of the 0 or 1
atomic_ts in this code should be replaced with atomic bitops.
Btw, there also was a fix from Lee in this area that added a missing
wakeup, make sure your tree already has that.
^ permalink raw reply
* RDMA developer gatherings around Kernel Summit and Linux Plumbers in Santa Fe
From: Christoph Lameter @ 2016-10-04 9:16 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: ira.weiny-ral2JQCrhuEAvxtiuMwx3w, Jason Gunthorpe,
john.fleck-ral2JQCrhuEAvxtiuMwx3w, leon-DgEjT+Ai2ygdnm+yROfE0A,
Doug Ledford, skc-YOWKrPYUwWM, shewa-YOWKrPYUwWM
We now have confirmation about the meetings related to the KS and LPC. The
events will be held at the:
Hilton Santa Fe
100 Sandoval St.
Santa Fe, NM 87501
Phone: (505)988-2811
We meet specifically on the subject matter of RDMA two days:
- RDMA workshop on Tuesday, 1st of November
Meeting in Sweeney B 9am till 5pm.
See http://linuxplumbersconf.org/2016/ocw/events/LPC2016/tracks/609
This is part of the Kernel Summit and the Linux Plumbers
Conference. Only open to KS and LPC attendees with an invitation.
- RDMA Summit on Saturday the 5th of November
Meeting in the Canyon Ballroom 9am till 4pm.
This event is sponsored by the Open Fabrics Alliance and will be
open to all
We think the workshop could be focusing more on the technical topics (some
of which could be carried over to Saturday if necessary because we have
more time then. The "Summit" would also be including management issues,
long range plans and OFA related material. We will summarize what
happened on Tuesday for those who were not able to participate earlier.
Each day we thought we could cover 6 subjects. 3 in the morning 3 in the
afternoon.
Initial ideas for sessions:
Workshop:
- New ioctl ABI and issues related to that
- Consolidated libraries. Closer integration of librdmacm to
libibverbs etc.
- Using standard network tools/techniques for IB interfaces.
- Debuggability and tracing (also can standard tools help here?)
- State of Multicast support
- Containers and RDMA
Summit:
- Licensing (GPL vs. Dual licensed)
- Integration with other subsystems (GPUs, network, PCI etc ...)
- Roadmap and future of RDMA
- Leftover issues and TODO for consolidated library.
- Submission process for multi-subsystem drivers (f.e ROCE)
Feedback would be appreciated so that we can workout an agenda that is
useful for all participants.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: iscsi_trx going into D state
From: Hannes Reinecke @ 2016-10-04 9:11 UTC (permalink / raw)
To: Johannes Thumshirn, Robert LeBlanc
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161004075545.j52mg3a2jckrchlp-qw2SdCWA0PpjqqEj2zc+bA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3080 bytes --]
On 10/04/2016 09:55 AM, Johannes Thumshirn wrote:
> On Fri, Sep 30, 2016 at 11:14:57AM -0600, Robert LeBlanc wrote:
>> We are having a reoccurring problem where iscsi_trx is going into D
>> state. It seems like it is waiting for a session tear down to happen
>> or something, but keeps waiting. We have to reboot these targets on
>> occasion. This is running the 4.4.12 kernel and we have seen it on
>> several previous 4.4.x and 4.2.x kernels. There is no message in dmesg
>> or /var/log/messages. This seems to happen with increased frequency
>> when we have a disruption in our Infiniband fabric, but can happen
>> without any changes to the fabric (other than hosts rebooting).
>>
>> # ps aux | grep iscsi | grep D
>> root 4185 0.0 0.0 0 0 ? D Sep29 0:00 [iscsi_trx]
>> root 18505 0.0 0.0 0 0 ? D Sep29 0:00 [iscsi_np]
>>
>> # cat /proc/4185/stack
>> [<ffffffff814cc999>] target_wait_for_sess_cmds+0x49/0x1a0
>> [<ffffffffa087292b>] isert_wait_conn+0x1ab/0x2f0 [ib_isert]
>> [<ffffffff814f0de2>] iscsit_close_connection+0x162/0x840
>> [<ffffffff814df8df>] iscsit_take_action_for_connection_exit+0x7f/0x100
>> [<ffffffff814effc0>] iscsi_target_rx_thread+0x5a0/0xe80
>> [<ffffffff8109c6f8>] kthread+0xd8/0xf0
>> [<ffffffff8172004f>] ret_from_fork+0x3f/0x70
>> [<ffffffffffffffff>] 0xffffffffffffffff
>>
>> # cat /proc/18505/stack
>> [<ffffffff814f0c71>] iscsit_stop_session+0x1b1/0x1c0
>> [<ffffffff814e2436>] iscsi_check_for_session_reinstatement+0x1e6/0x270
>> [<ffffffff814e4df0>] iscsi_target_check_for_existing_instances+0x30/0x40
>> [<ffffffff814e4f40>] iscsi_target_do_login+0x140/0x640
>> [<ffffffff814e62dc>] iscsi_target_start_negotiation+0x1c/0xb0
>> [<ffffffff814e402b>] iscsi_target_login_thread+0xa9b/0xfc0
>> [<ffffffff8109c6f8>] kthread+0xd8/0xf0
>> [<ffffffff8172004f>] ret_from_fork+0x3f/0x70
>> [<ffffffffffffffff>] 0xffffffffffffffff
>>
>> What can we do to help get this resolved?
>>
>> Thanks,
>>
>> ----------------
>> Robert LeBlanc
>> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> Hi,
> I've encountered the same issue and found a hack to fix it at [1] but I think
> the correct way for handling this issue would be like you said to tear down
> the session in case a TASK ABORT times out. Unfortunately I'm not really
> familiar with the target code myself so I mainly use this reply to get me into
> the Cc loop.
>
> [1] http://marc.info/?l=linux-scsi&m=147282568910535&w=2
>
>
Hmm. Looking at the code it looks as we might miss some calls to
'complete'. Can you try with the attached patch?
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare-l3A5Bk7waGM@public.gmane.org +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
[-- Attachment #2: 0001-iscsi_target-sanitze-sess_wait_on_completion.patch --]
[-- Type: text/x-patch, Size: 2490 bytes --]
>From d481d8c27df8c09ea3798ce4a7217a26c3533161 Mon Sep 17 00:00:00 2001
From: Hannes Reinecke <hare-l3A5Bk7waGM@public.gmane.org>
Date: Tue, 4 Oct 2016 11:05:46 +0200
Subject: [PATCH] iscsi_target: sanitze sess_wait_on_completion
When closing a session we only should set 'sess_wait_on_completion'
if we are actually calling wait_for_completion(). And we should indeed
call 'complete' in these cases, too.
And add some WARN_ON() if we mess up with calculating the number
of completions, too.
Signed-off-by: Hannes Reinecke <hare-IBi9RG/b67k@public.gmane.org>
---
drivers/target/iscsi/iscsi_target.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/target/iscsi/iscsi_target.c b/drivers/target/iscsi/iscsi_target.c
index 39b928c..313724c 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -4287,6 +4287,7 @@ int iscsit_close_connection(
if (!atomic_read(&sess->session_reinstatement) &&
atomic_read(&sess->session_fall_back_to_erl0)) {
spin_unlock_bh(&sess->conn_lock);
+ WARN_ON(atomic_read(&sess->sleep_on_sess_wait_comp));
iscsit_close_session(sess);
return 0;
@@ -4557,7 +4558,6 @@ int iscsit_free_session(struct iscsi_session *sess)
int is_last;
spin_lock_bh(&sess->conn_lock);
- atomic_set(&sess->sleep_on_sess_wait_comp, 1);
list_for_each_entry_safe(conn, conn_tmp, &sess->sess_conn_list,
conn_list) {
@@ -4585,7 +4585,10 @@ int iscsit_free_session(struct iscsi_session *sess)
if (atomic_read(&sess->nconn)) {
spin_unlock_bh(&sess->conn_lock);
+ atomic_inc(&sess->sleep_on_sess_wait_comp);
wait_for_completion(&sess->session_wait_comp);
+ atomic_dec(&sess->sleep_on_sess_wait_comp);
+ WARN_ON(atomic_read(&sess->sleep_on_sess_wait_comp));
} else
spin_unlock_bh(&sess->conn_lock);
@@ -4603,8 +4606,6 @@ void iscsit_stop_session(
int is_last;
spin_lock_bh(&sess->conn_lock);
- if (session_sleep)
- atomic_set(&sess->sleep_on_sess_wait_comp, 1);
if (connection_sleep) {
list_for_each_entry_safe(conn, conn_tmp, &sess->sess_conn_list,
@@ -4636,7 +4637,10 @@ void iscsit_stop_session(
if (session_sleep && atomic_read(&sess->nconn)) {
spin_unlock_bh(&sess->conn_lock);
+ atomic_inc(&sess->sleep_on_sess_wait_comp);
wait_for_completion(&sess->session_wait_comp);
+ atomic_dec(&sess->sleep_on_sess_wait_comp);
+ WARN_ON(atomic_read(&sess->sleep_on_sess_wait_comp);
} else
spin_unlock_bh(&sess->conn_lock);
}
--
2.6.6
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox