On 12/03/2015 01:18 AM, Christoph Hellwig wrote:
> The patch looks good to me, but while we touch this area, how about
> throwing in a few cosmetic fixes as well?
How about the patch below ? In that version of the ib_sg_to_pages() fix
these concerns have been addressed and additionally to more bu
The default value of 8 is too small to read
/sys/class/infiniband/usnic_x/node_type, which contains "6: usNIC
UDP". Per a7a73a8c1b39362f1701256bc772d82847832f9c, the too-small
buffer causes a stderr warning to be emitted from ibv_devinfo when
reading usNIC devices.
This commit therefore increases
There are holes in the sdma build support routines that do
not clean any partially built sdma descriptors after mapping or
allocate failures.
This patch corrects these issues.
Reviewed-by: Dennis Dalessandro
Signed-off-by: Mike Marciniszyn
---
drivers/staging/rdma/hfi1/sdma.c | 10 ++
The allocation code assumes that the shadow ring cannot
be overrun because the credits will limit the allocation.
Unfortuately, the progress mechanism in sc_release_update() updates
the free count prior to processing the shadow ring, allowing the
shadow ring to be overrun by an allocation.
Review
> From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
> Subject: Re: [PATCH for-next V2 05/11] IB/core: Add rdma_network_type to
> wc
>
> Bloating the WC with a field that's not really useful for the ULPs seems
> pretty
> sad..
You need per packet (read per-WC) network type both for hand
On Thu, Dec 03, 2015 at 03:47:12PM +0200, Matan Barak wrote:
> From: Somnath Kotur
>
> Providers should tell IB core the wc's network type.
> This is used in order to search for the proper GID in the
> GID table. When using HCAs that can't provide this info,
> IB core tries to deep examine the pa
On Thu, Dec 3, 2015 at 4:05 PM, Christoph Hellwig wrote:
> Bloating the WC with a field that's not really useful for the ULPs
> seems pretty sad..
Network header type is mandatory in order to find the GID type and get
the GIDs correctly from the header.
I realize ULPs might have preferred to get
The current ibv_poll_cq_ex mechanism needs to query every field
for its existence. In order to avoid this penalty at runtime,
add optimized functions for special cases.
Signed-off-by: Matan Barak
---
src/cq.c| 363 +---
src/mlx5.h | 1
Always inline isn't supported by every compiler. Adding it to
configure.ac in order to support it only when possible.
Inline other poll_one data path functions in order to eliminate
"ifs".
Signed-off-by: Matan Barak
---
configure.ac | 17 +
src/cq.c | 42 +
In order to query the current HCA's core clock, libmlx5 should
support ibv_query_values verb. Querying the hardware's cycles
register is done by mmaping this register to user-space.
Therefore, when libmlx5 initializes we mmap the cycles register.
This assumes the machine's architecture places the P
Hi Eli,
This series adds support for completion timestamp. In order to
support this feature, several extended verbs were implemented
(as instructed in libibverbs).
ibv_query_device_ex was extended to support reading the
hca_core_clock and timestamp mask.
The init_context verb vendor specific dat
Extended poll_cq supports writing only user's required work completion
fields. Adding support for this extended verb.
Signed-off-by: Matan Barak
---
src/cq.c | 699 +
src/mlx5.c | 5 +
src/mlx5.h | 14 ++
3 files changed, 584 inser
In order to create a CQ which supports timestamp, the user needs
to specify the timestamp flag for ibv_create_cq_ex.
Adding support for ibv_create_cq_ex in the mlx5's vendor library.
Signed-off-by: Matan Barak
---
src/mlx5.c | 1 +
src/mlx5.h | 2 ++
src/verbs.c | 72
Add support for filling the timestamp field in ibv_poll_cq_ex
(if it's required by the user).
Signed-off-by: Matan Barak
---
src/cq.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/cq.c b/src/cq.c
index 0185696..5e06990 100644
--- a/src/cq.c
+++ b/src/cq.c
@@ -913,6 +913,11 @@ inli
Extending core and vendor verb commands require us to check that the
unknown part of the user's given command is all zeros.
Adding ib_is_udata_cleared in order to do so.
Signed-off-by: Matan Barak
Reviewed-by: Moshe Lazer
---
include/rdma/ib_verbs.h | 67
In order to read the HCA's current cycles register, we need
to map it to user-space. Add support to map this register
via mmap command.
Signed-off-by: Matan Barak
Reviewed-By: Moshe Lazer
---
drivers/infiniband/hw/mlx5/main.c| 28
drivers/infiniband/hw/mlx5/mlx5
Hi Eli,
This patch-set adds user-space support for time-stamping in mlx5_ib.
It implements the necessary API:
(a) ib_create_cq_ex - Add support for CQ creation flags
(b) ib_query_device - return timestamp_mask and hca_core_clock.
We also add support for mmaping the HCA's free running clock.
In or
In order to create a CQ that supports timestamp, mlx5 needs to
support the extended create CQ command with the timestamp flag.
Signed-off-by: Matan Barak
Reviewed-by: Eli Cohen
---
drivers/infiniband/hw/mlx5/cq.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/infiniband/hw/m
Pass hca_core_clock_offset to user-space is mandatory in order to
let the user-space read the free-running clock register from the
right offset in the memory mapped page.
Passing this value is done by changing the vendor's command
and response of init_ucontext to be in extensible form.
Signed-off-
Reporting the hca_core_clock (in kHZ) and the timestamp_mask in
query_device extended verb. timestamp_mask is used by users in order
to know what is the valid range of the raw timestamps, while
hca_core_clock reports the clock frequency that is used for
timestamps.
Signed-off-by: Matan Barak
Revi
Did we ever make progress on this?
Just up to Doug to pull it in.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 10, 2015 at 12:36:44PM +0200, Sagi Grimberg wrote:
> Any reply on this patchset?
Did we ever make progress on this?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel
Bloating the WC with a field that's not really useful for the ULPs
seems pretty sad..
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
This patch set adds attributes of net device and gid type to each GID
in the GID table. Users that use verbs directly need to specify
the GID index. Since the same GID could have different types or
associated net devices, users should have the ability to query the
associated GID attributes. Adding
In order to validate the route, we need an easy way to check if a
net-device belongs to our RDMA device. Move this helper function
to a header file in order to make this check easier.
Signed-off-by: Matan Barak
Reviewed-by: Haggai Eran
---
drivers/infiniband/core/core_priv.h | 13 ++
Hi Doug,
This series adds the support for RoCE v2. In order to support RoCE v2,
we add gid_type attribute to every GID. When the RoCE GID management
populates the GID table, it duplicates each GID with all supported types.
This gives the user the ability to communicate over each supported
type.
P
In order to support multiple GID types, we need to store the gid_type
with each GID. This is also aligned with the RoCE v2 annex "RoCEv2 PORT
GID table entries shall have a "GID type" attribute that denotes the L3
Address type". The currently supported GID is IB_GID_TYPE_IB which is
also RoCE v1 GI
From: Moni Shoua
Since RoCEv2 is a protocol over IP header it is required to send IGMP
join and leave requests to the network when joining and leaving
multicast groups.
Signed-off-by: Moni Shoua
---
drivers/infiniband/core/cma.c | 96 ++---
drivers/infinib
From: Somnath Kotur
Providers should tell IB core the wc's network type.
This is used in order to search for the proper GID in the
GID table. When using HCAs that can't provide this info,
IB core tries to deep examine the packet and extract
the GID type by itself.
We choose sgid_index and type f
Currently, cma users can't increase or decrease the cma reference
count. This is necassary when setting cma attributes (like the
default GID type) in order to avoid use-after-free errors.
Adding cma_ref_dev and cma_deref_dev APIs.
Signed-off-by: Matan Barak
---
drivers/infiniband/core/cma.c
In order to make sure API users don't try to use SGIDs which don't
conform to the routing table, validate the route before searching
the RoCE GID table.
Signed-off-by: Matan Barak
---
drivers/infiniband/core/addr.c | 175 ++-
drivers/infiniband/core/cm.c
Previosuly, cm and cma modules supported only IB and RoCE v1 GID type.
In order to support multiple GID types, the gid_type is passed to
cm_init_av_by_path and stored in the path record.
The rdma cm client would use a default GID type that will be saved in
rdma_id_private.
Signed-off-by: Matan Ba
In order to validate the route, we need an easy way to check if a
net-device belongs to our RDMA device. Move this helper function
to a header file in order to make this check easier.
Signed-off-by: Matan Barak
Reviewed-by: Haggai Eran
---
drivers/infiniband/core/core_priv.h | 13 ++
From: Somnath Kotur
Providers should tell IB core the wc's network type.
This is used in order to search for the proper GID in the
GID table. When using HCAs that can't provide this info,
IB core tries to deep examine the packet and extract
the GID type by itself.
We choose sgid_index and type f
Adding RoCE v2 GID type and port type. Vendors
which support this type will get their GID table
populated with RoCE v2 GIDs automatically.
Signed-off-by: Matan Barak
---
drivers/infiniband/core/cache.c | 1 +
drivers/infiniband/core/roce_gid_mgmt.c | 3 ++-
include/rdma/ib_verbs.h
Users would like to control the behaviour of rdma_cm.
For example, old applications which don't set the
required RoCE gid type could be executed on RoCE V2
network types. In order to support this configuration,
we implement a configfs for rdma_cm.
In order to use the configfs, one needs to mount i
From: Moni Shoua
ib_ud_header_init() is used to format InfiniBand headers
in a buffer up to (but not with) BTH. For RoCE UDP ENCAP it is
required that this function would be able to build also IP and UDP
headers.
Signed-off-by: Moni Shoua
Signed-off-by: Matan Barak
---
drivers/infiniband/core
From: Moni Shoua
ib_ud_header_init() is used to format InfiniBand headers
in a buffer up to (but not with) BTH. For RoCE UDP ENCAP it is
required that this function would be able to build also IP and UDP
headers.
Signed-off-by: Moni Shoua
Signed-off-by: Matan Barak
---
drivers/infiniband/core
Users would like to control the behaviour of rdma_cm.
For example, old applications which don't set the
required RoCE gid type could be executed on RoCE V2
network types. In order to support this configuration,
we implement a configfs for rdma_cm.
In order to use the configfs, one needs to mount i
From: Moni Shoua
Since RoCEv2 is a protocol over IP header it is required to send IGMP
join and leave requests to the network when joining and leaving
multicast groups.
Signed-off-by: Moni Shoua
---
drivers/infiniband/core/cma.c | 96 ++---
drivers/infinib
Adding RoCE v2 GID type and port type. Vendors
which support this type will get their GID table
populated with RoCE v2 GIDs automatically.
Signed-off-by: Matan Barak
---
drivers/infiniband/core/cache.c | 1 +
drivers/infiniband/core/roce_gid_mgmt.c | 3 ++-
include/rdma/ib_verbs.h
In order to make sure API users don't try to use SGIDs which don't
conform to the routing table, validate the route before searching
the RoCE GID table.
Signed-off-by: Matan Barak
---
drivers/infiniband/core/addr.c | 175 ++-
drivers/infiniband/core/cm.c
Currently, cma users can't increase or decrease the cma reference
count. This is necassary when setting cma attributes (like the
default GID type) in order to avoid use-after-free errors.
Adding cma_ref_dev and cma_deref_dev APIs.
Signed-off-by: Matan Barak
---
drivers/infiniband/core/cma.c
Previosuly, cm and cma modules supported only IB and RoCE v1 GID type.
In order to support multiple GID types, the gid_type is passed to
cm_init_av_by_path and stored in the path record.
The rdma cm client would use a default GID type that will be saved in
rdma_id_private.
Signed-off-by: Matan Ba
This patch set adds attributes of net device and gid type to each GID
in the GID table. Users that use verbs directly need to specify
the GID index. Since the same GID could have different types or
associated net devices, users should have the ability to query the
associated GID attributes. Adding
In order to support multiple GID types, we need to store the gid_type
with each GID. This is also aligned with the RoCE v2 annex "RoCEv2 PORT
GID table entries shall have a "GID type" attribute that denotes the L3
Address type". The currently supported GID is IB_GID_TYPE_IB which is
also RoCE v1 GI
Hi Doug,
This series adds the support for RoCE v2. In order to support RoCE v2,
we add gid_type attribute to every GID. When the RoCE GID management
populates the GID table, it duplicates each GID with all supported types.
This gives the user the ability to communicate over each supported
type.
P
> How about the patch below ?
The patch looks good to me, but while we touch this area, how about
throwing in a few cosmetic fixes as well?
> - if (i && page_addr != dma_addr) {
> + if (i && (page_addr != dma_addr || last_page_off != 0)) {
> if (last_
On Thu, Dec 03, 2015 at 10:46:10AM +0200, Sagi Grimberg wrote:
> >> If entries 2 and 3 could be merged dma_len for 2 would span 2 and 3,
> >> and then entry 3 would actually have the dma addr and len for entry 4.
>
> So what would be in the last entry {dma_addr, dma_len}? zeros?
>
> >>I'm not
Hello Sagi,
Hmm ... why would it be unacceptable to return 0 if sg_nents == 0 ?
Regarding which component to modify if mapping the first page fails:
for almost every kernel function I know a negative return value means
failure and a return value >= 0 means success. Hence my proposal to
change
Replying to my own email,
dma_map_sg returns the actual number of entries to iterate. At least
historically some IOMMU implementations would do strange tricks like:
If entries 2 and 3 could be merged dma_len for 2 would span 2 and 3,
and then entry 3 would actually have the dma addr and
Hi Doug,
not having any maintainer available for an extended time is a problem,
and we actually had long discussions about that at kernel summit, with
a clear hint with a cluebat from Linus that he'd prefer maintainer
teams. So I'd really love to know who was so ead set aginst them.
I personally
52 matches
Mail list logo