* Re: [PATCH v6 02/16] IB/pvrdma: Add user-level shared functions
From: Leon Romanovsky @ 2016-10-05 13:42 UTC (permalink / raw)
To: Adit Ranadive
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
pv-drivers-pghWNbHTmq7QT0dZR+AlfA, jhansen-pghWNbHTmq7QT0dZR+AlfA,
asarwade-pghWNbHTmq7QT0dZR+AlfA,
georgezhang-pghWNbHTmq7QT0dZR+AlfA,
bryantan-pghWNbHTmq7QT0dZR+AlfA
In-Reply-To: <515c704574423b16feb4c3d97847156623a8d042.1475458407.git.aditr-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]
On Sun, Oct 02, 2016 at 07:10:22PM -0700, Adit Ranadive wrote:
> We share some common structures with the user-level driver. This patch adds
> those structures and shared functions to traverse the QP/CQ rings.
>
> Reviewed-by: Yuval Shaia <yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Jorgen Hansen <jhansen-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> Reviewed-by: George Zhang <georgezhang-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Aditya Sarwade <asarwade-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Bryan Tan <bryantan-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Adit Ranadive <aditr-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
> ---
> Changes v5->v6:
> - Removed the pvrdma-uapi.h file and moved common structures into
> pvrdma-abi.h.
> - Moved enums and structs common to user-level and kernel driver into
> pvrdma-abi.h.
> - Changed _exp_ to _ex_ for extended structures.
>
> Changes v4->v5:
> - Moved pvrdma_uapi.h and pvrdma_user.h into common UAPI folder.
> - Renamed to pvrdma-uapi.h and pvrdma-abi.h respectively.
> - Prefixed unsigned vars with __.
>
> Changes v3->v4:
> - Moved pvrdma_sge into pvrdma_uapi.h
> ---
> include/uapi/rdma/Kbuild | 2 +
> include/uapi/rdma/pvrdma-abi.h | 289 +++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 291 insertions(+)
> create mode 100644 include/uapi/rdma/pvrdma-abi.h
>
> diff --git a/include/uapi/rdma/Kbuild b/include/uapi/rdma/Kbuild
> index ac62908..04357ba 100644
> --- a/include/uapi/rdma/Kbuild
> +++ b/include/uapi/rdma/Kbuild
> @@ -8,3 +8,5 @@ header-y += rdma_netlink.h
> header-y += rdma_user_cm.h
> header-y += hfi/
> header-y += rdma_user_rxe.h
> +header-y += pvrdma-abi.h
> +header-y += pvrdma-uapi.h
You forgot to drop this line.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: RDMA developer gatherings around Kernel Summit and Linux Plumbers in Santa Fe
From: Christoph Hellwig @ 2016-10-05 13:18 UTC (permalink / raw)
To: Atchley, Scott
Cc: Christoph Hellwig, 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: <BED3F60E-08E7-4C29-8A52-E7F879BE46A4-1Heg1YXhbW8@public.gmane.org>
[snipped the marketing BS and getting straight to the point..]
> 5. The only one in this thread trying to force a license of others is not the OFA.
That is not the case. OFA has been constantly pushing through various
channels to force Dual licensing of RDMA related code contribute to the
Linux kernel.
Can you please confirm on behalf of the OFA board that OFA will stop
bullying Linux kernel contributors or otherwise try to influence
licensing of code contributed to the Linux kernel that has not been
developed by the OFA.
Once we have that sorted out I think we're all in violent agreement.
--
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-05 13:02 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: <20161005083218.GA16922-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> On Oct 5, 2016, at 4:32 AM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
>
> Could someone elaborate what the OFA position is? Right now the only
> thing I know is that they are a) forcing their members to Dual license
> code nd have b) some sort of weird idea that they could also force this
> on others in some way.
Although I am sitting on the OFA board as the representative of my organization, I do not speak for the OFA. These are my observations:
1. The OFA is an organization to promote the standardization of alternative network technologies. Prior to the OFA, vendors created specialized hardware with specialized software stacks tailored to HPC. Examples include QSnet/Quadrics, GM/Myrinet MX/Myrinet, Cray Portals/SeaStar, Cray GNI/Gemini/Aries, IBM BG[LPQ], etc. The OFA evolved from the InfiniBand/Verbs trade group in order to promote additional technologies (e.g. iWarp, RoCE, PSM, etc).
2. The OFA organization, made up of various members, has rules to govern itself. Most members are also competitors. They cooperate on standards because everyone benefits by avoiding the fragmentation of the prior state of affairs (see item 1). Because they are competitors, changes are difficult and/or slow because people have to build consensus. Other members are consumers, for example the organization I represent, and we want standards and competition. The former allows us to get better products from the latter.
3. The members that contribute the most to the OFA in terms of money, staff time, and code are the vendors. They wrote much of the code that was contributed and they chose dual license, as is their right. I assume (because I do not know) that they did so to avoid writing two (or three) stacks for Linux and non-Linux environments.
4. OFA has a rule that code developed on its behalf be dual-license. They do not _force_ this on members because members decided this or they joined knowing that this was the rule. OFA cannot force anyone to join so therefore they cannot force anyone to adopt a dual-license. As mentioned in item 2, OFA members can modify their rules via an established process. If you want to change the rule, join OFA and convince the members.
5. The only one in this thread trying to force a license of others is not the OFA.
> I personally think that a) is not helpful to the adoption of RDMA
> technologies in Linux, and that b) is obviously a complete non-started
> as confirmed multiple times, which isn't just my own opinion.
If one is not a member, the OFA cannot force anything. I do not see dual-license as a hindrance to Linux kernel use or adoption. Perhaps you can help me understand better.
> Based on that I really don't understand what the point of this
> discussion is, unless OFA really needs help with an internal discussion
> to get rid of a). If Christoph really wants me to help with a) please
> do it during Plumbers as I won't be around on Saturday.
--
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] i40iw: Remove macros I40IW_STAG_KEY_FROM_STAG and I40IW_STAG_INDEX_FROM_STAG
From: Leon Romanovsky @ 2016-10-05 12:57 UTC (permalink / raw)
To: Thomas Huth
Cc: Faisal Latif, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Chien Tin Tung,
Mustafa Ismail, Shiraz Saleem, Tatyana Nikolova, Doug Ledford,
Sean Hefty, Hal Rosenstock
In-Reply-To: <1475668538-12914-1-git-send-email-thuth-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 641 bytes --]
On Wed, Oct 05, 2016 at 01:55:38PM +0200, Thomas Huth wrote:
> The macros I40IW_STAG_KEY_FROM_STAG and I40IW_STAG_INDEX_FROM_STAG are
> apparently bad - they are using the logical "&&" operation which
> does not make sense here. It should have been a bitwise "&" instead.
> Since the macros seem to be completely unused, let's simply remove
> them so that nobody accidentially uses them in the future. And while
> we're at it, also remove the unused macro I40IW_CREATE_STAG.
>
> Signed-off-by: Thomas Huth <thuth-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Thanks,
Reviewed-by: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH rdma-core] Improve global COPYING files
From: Leon Romanovsky @ 2016-10-05 12:49 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Doug Ledford
In-Reply-To: <20160923173421.GB13920-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2766 bytes --]
On Fri, Sep 23, 2016 at 11:34:21AM -0600, Jason Gunthorpe wrote:
> On Fri, Sep 23, 2016 at 08:10:03PM +0300, Leon Romanovsky wrote:
>
> > I sure that this question will sound dumb for you, but can we unify all
> > code under OFA's licenses (dual-license)? I don't feel comfortable with
> > this multi-license situation.
>
> It is an excellent question.
>
> To do this we would need the OFA to talk to each of the member
> companies and get them to sign some kind of legal change of copyright
> document. Assuming all of the member companies agree, and all the
> member companies are the exhaustive copyright owners then the code can
> be placed under a single uniform license.
>
> As I understand it all OFA members were required to agree to use a
> specific licensing scheme, including specific license text when they
> signed the OFA membership agreement. What we are seeing here is that
> the corporate legal side agreed to something but the developers made
> small errors along the way, and those errors were later copied by
> other developers and spread widely. So the OFA has a basis for
> requests of this nature.
>
> For instance, a legal statement from Mellanox that all code they
> contributed is available under the GPLv2 or *either* MIT or FreeBSD
> license varient would allow immediately placing all Mellanox
> copyrighted code under the single Default License. I expect this is
> what Mellanox intended to do anyhow, the fact that ibverbs and all
> their providers had an error in the COPYING file is simply
> an unfortunate mistake.
>
> These sorts of license issues are typical in historical code bases. I
> would say we are in pretty good shape, from what I can tell absolutely
> everything is unambiguously licensed under at least the GPLv2, or a
> compatible license.
>
> Almost everything is alternatively licensed under some kind of BSD
> license. The notable exception is ipathverbs and rxe. It is also
> unfortunate we have so many BSD variants.
>
> Further, almost all C code is licensed under the dual GPLv2/OpenIB.org
> (MIT) license. The kernel is similar, almost all C code is using the
> MIT variant. Hence my desire to make that the license for new code in
> the tree.
>
> I would say this is a pretty good result.
>
> My ultimate suggestion is that we push the non-default copyright into
> the impacted files, eg add short licenses headers to the man pages,
> etc, and then delete the extraneous COPYING files once every single
> file has a correct license statement. From that point we can look at
> switching individual files based on the above Legal process to the
> Default License, or just leave them as is - a historical quirk.
It looks like a lot of work to do and it can be handled by anyone.
Can OPA handle this?
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] i40iw: Remove macros I40IW_STAG_KEY_FROM_STAG and I40IW_STAG_INDEX_FROM_STAG
From: Thomas Huth @ 2016-10-05 11:55 UTC (permalink / raw)
To: Faisal Latif, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Chien Tin Tung, Mustafa Ismail, Shiraz Saleem, Tatyana Nikolova,
Doug Ledford, Sean Hefty, Hal Rosenstock
The macros I40IW_STAG_KEY_FROM_STAG and I40IW_STAG_INDEX_FROM_STAG are
apparently bad - they are using the logical "&&" operation which
does not make sense here. It should have been a bitwise "&" instead.
Since the macros seem to be completely unused, let's simply remove
them so that nobody accidentially uses them in the future. And while
we're at it, also remove the unused macro I40IW_CREATE_STAG.
Signed-off-by: Thomas Huth <thuth-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
drivers/infiniband/hw/i40iw/i40iw_user.h | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/infiniband/hw/i40iw/i40iw_user.h b/drivers/infiniband/hw/i40iw/i40iw_user.h
index 276bcef..0d91667 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_user.h
+++ b/drivers/infiniband/hw/i40iw/i40iw_user.h
@@ -96,12 +96,6 @@ enum i40iw_device_capabilities_const {
#define i40iw_physical_fragment u64
#define i40iw_address_list u64 *
-#define I40IW_CREATE_STAG(index, key) (((index) << 8) + (key))
-
-#define I40IW_STAG_KEY_FROM_STAG(stag) ((stag) && 0x000000FF)
-
-#define I40IW_STAG_INDEX_FROM_STAG(stag) (((stag) && 0xFFFFFF00) >> 8)
-
#define I40IW_MAX_MR_SIZE 0x10000000000L
struct i40iw_qp_uk;
--
1.8.3.1
--
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 related
* Re: [PATCH rdma-core] Add a .travis.yml file
From: Leon Romanovsky @ 2016-10-05 11:51 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Doug Ledford
In-Reply-To: <1475105337-18002-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]
On Wed, Sep 28, 2016 at 05:28:57PM -0600, Jason Gunthorpe wrote:
> Necessary to use the Travis CI service.
>
> Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> ---
> .travis.yml | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
> create mode 100644 .travis.yml
>
> Now that travis is enabled on repo, we need a yml file to make it run.
>
> Here is a basic one.
>
> I don't test with distros as old as precise and I don't expect that glibc to
> be new enough to build this (eg missing timerfd, O_CLOEXEC, etc), and the
> cmake certainly isn't. So we use the trusty 'beta' environment and install
> gcc 6.2.
I'm using 16.04 and it has gcc 5.4.0 as a default. Don't you think that
6.2 is too "new" for us and other distributions?
➜ linux-rdma git:(master) gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller
From: Leon Romanovsky @ 2016-10-05 11:22 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Parav Pandit, Tejun Heo, Jason Gunthorpe, 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: <20161005063735.GC3086@lst.de>
[-- Attachment #1: Type: text/plain, Size: 248 bytes --]
On Wed, Oct 05, 2016 at 08:37:35AM +0200, Christoph Hellwig wrote:
> 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.
IMHO, it still can make it.
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCHv12 0/3] rdmacg: IB/core: rdma controller support
From: Leon Romanovsky @ 2016-10-05 11:22 UTC (permalink / raw)
To: Parav Pandit
Cc: cgroups, linux-doc, linux-kernel, linux-rdma, tj, lizefan, hannes,
dledford, hch, liranl, sean.hefty, jgunthorpe, haggaie, corbet,
james.l.morris, serge, ogerlitz, matanb, akpm,
linux-security-module
In-Reply-To: <1472632647-1525-1-git-send-email-pandit.parav@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]
On Wed, Aug 31, 2016 at 02:07:24PM +0530, Parav Pandit wrote:
> rdmacg: IB/core: rdma controller support
>
> Patch is generated and tested against below Doug's linux-rdma
> git tree.
>
> URL: git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git
> Branch: master
>
> Patchset is also compiled and tested against below Tejun's cgroup tree
> using cgroup v2 mode.
> URL: git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git
> Branch: master
>
> Overview:
> Currently user space applications can easily take away all the rdma
> device specific resources such as AH, CQ, QP, MR etc. Due to which other
> applications in other cgroup or kernel space ULPs may not even get chance
> to allocate any rdma resources. This results into service unavailibility.
>
> RDMA cgroup addresses this issue by allowing resource accounting,
> limit enforcement on per cgroup, per rdma device basis.
>
> RDMA uverbs layer will enforce limits on well defined RDMA verb
> resources without any HCA vendor device driver involvement.
>
> RDMA uverbs layer will not do limit enforcement of HCA hw vendor
> specific resources. Instead rdma cgroup provides set of APIs
> through which vendor specific drivers can do resource accounting
> by making use of rdma cgroup.
Hi Parav,
I want to propose an extension to the RDMA cgroup which can be done as
follow-up patches.
Let's add new global type, which will control whole HCA (for example in percentages). It will
allow natively define new objects without need to introduce them to the user.
This HCA share will be overwritten by specific UVERBS types which you
already defined.
What do you think?
Except this proposal,
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Thanks.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH rdma-core] MAINTAINERS: Add backup/co-maintainer for ibacm
From: Hal Rosenstock @ 2016-10-05 11:17 UTC (permalink / raw)
To: Doug Ledford, Leon Romanovsky
Cc: Hefty, Sean, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Hal Rosenstock <hal-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
---
diff --git a/MAINTAINERS b/MAINTAINERS
index 9048311..d1a29a8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -64,6 +64,7 @@ F: libi40iw/
RDMA Communication Manager Assistant (for librdmacm.so)
M: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
+M: Hal Rosenstock <hal-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
S: Supported
F: ibacm/*
--
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 related
* [PATCH rdma-core] Remove unused HIDDEN gcc attribute
From: Leon Romanovsky @ 2016-10-05 11:08 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
The attribute HIDDEN was declared is almost every provider, but it wasn't
used, except in libibverbs. Let's remove it.
Signed-off-by: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
libhfi1verbs/src/hfiverbs.h | 2 --
libi40iw/src/i40iw_umain.h | 2 --
libipathverbs/src/ipathverbs.h | 2 --
libmlx4/src/mlx4.h | 2 --
libmlx5/src/mlx5.h | 2 --
libmthca/src/mthca.h | 2 --
libnes/src/nes_umain.h | 2 --
7 files changed, 14 deletions(-)
diff --git a/libhfi1verbs/src/hfiverbs.h b/libhfi1verbs/src/hfiverbs.h
index deebc65..e82ba2b 100644
--- a/libhfi1verbs/src/hfiverbs.h
+++ b/libhfi1verbs/src/hfiverbs.h
@@ -67,8 +67,6 @@
#include <infiniband/arch.h>
#include <infiniband/verbs.h>
-#define HIDDEN __attribute__((visibility ("hidden")))
-
#define PFX "hfi1: "
struct hfi1_device {
diff --git a/libi40iw/src/i40iw_umain.h b/libi40iw/src/i40iw_umain.h
index 13d3da8..719aefc 100644
--- a/libi40iw/src/i40iw_umain.h
+++ b/libi40iw/src/i40iw_umain.h
@@ -54,8 +54,6 @@
#define unlikely(x) __builtin_expect((x), 0)
#endif
-#define HIDDEN __attribute__((visibility("hidden")))
-
#define PFX "libi40iw-"
#define I40IW_BASE_PUSH_PAGE 1
diff --git a/libipathverbs/src/ipathverbs.h b/libipathverbs/src/ipathverbs.h
index 05e1c71..ff25854 100644
--- a/libipathverbs/src/ipathverbs.h
+++ b/libipathverbs/src/ipathverbs.h
@@ -47,8 +47,6 @@
#include <infiniband/arch.h>
#include <infiniband/verbs.h>
-#define HIDDEN __attribute__((visibility ("hidden")))
-
#define PFX "ipath: "
struct ipath_device {
diff --git a/libmlx4/src/mlx4.h b/libmlx4/src/mlx4.h
index 1855cfb..95a6521 100644
--- a/libmlx4/src/mlx4.h
+++ b/libmlx4/src/mlx4.h
@@ -49,8 +49,6 @@
#include <valgrind/memcheck.h>
-#define HIDDEN __attribute__((visibility ("hidden")))
-
#define PFX "mlx4: "
enum {
diff --git a/libmlx5/src/mlx5.h b/libmlx5/src/mlx5.h
index c209a79..f8674c7 100644
--- a/libmlx5/src/mlx5.h
+++ b/libmlx5/src/mlx5.h
@@ -54,8 +54,6 @@
#include <valgrind/memcheck.h>
-#define HIDDEN __attribute__((visibility("hidden")))
-
#ifdef HAVE_FUNC_ATTRIBUTE_ALWAYS_INLINE
#define ALWAYS_INLINE __attribute__((always_inline))
#else
diff --git a/libmthca/src/mthca.h b/libmthca/src/mthca.h
index da53010..b4b0b6a 100644
--- a/libmthca/src/mthca.h
+++ b/libmthca/src/mthca.h
@@ -41,8 +41,6 @@
#include <valgrind/memcheck.h>
-#define HIDDEN __attribute__((visibility ("hidden")))
-
#define PFX "mthca: "
enum mthca_hca_type {
diff --git a/libnes/src/nes_umain.h b/libnes/src/nes_umain.h
index 9129982..f3cc348 100644
--- a/libnes/src/nes_umain.h
+++ b/libnes/src/nes_umain.h
@@ -48,8 +48,6 @@
#define unlikely(x) __builtin_expect((x),0)
#endif
-#define HIDDEN __attribute__((visibility ("hidden")))
-
#define PFX "libnes: "
#define NES_QP_MMAP 1
--
2.7.4
--
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 related
* [PATCH rdma-core] Add travis CI status to master branch
From: Leon Romanovsky @ 2016-10-05 8:37 UTC (permalink / raw)
To: dledford-H+wXaHxf7aLQT0dZR+AlfA; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
Signed-off-by: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
README.md | 2 ++
1 file changed, 2 insertions(+)
diff --git a/README.md b/README.md
index 51b2faf..98ec5a7 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,5 @@
+[](https://travis-ci.org/linux-rdma/rdma-core)
+
# RDMA Core Userspace Libraries and Daemons
This is the userspace components for the Linux Kernel's drivers/infiniband
--
2.7.4
--
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 related
* Re: RDMA developer gatherings around Kernel Summit and Linux Plumbers in Santa Fe
From: Christoph Hellwig @ 2016-10-05 8:32 UTC (permalink / raw)
To: Christoph Lameter
Cc: Atchley, Scott, 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: <alpine.DEB.2.20.1610050242260.27600-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
Could someone elaborate what the OFA position is? Right now the only
thing I know is that they are a) forcing their members to Dual license
code nd have b) some sort of weird idea that they could also force this
on others in some way.
I personally think that a) is not helpful to the adoption of RDMA
technologies in Linux, and that b) is obviously a complete non-started
as confirmed multiple times, which isn't just my own opinion.
Based on that I really don't understand what the point of this
discussion is, unless OFA really needs help with an internal discussion
to get rid of a). If Christoph really wants me to help with a) please
do it during Plumbers as I won't be around on Saturday.
--
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: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
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