> > There are no in tree users and the only attempt at adding one was
> rejected.
>
> There are no in tree users of this but there is your madeye tool (which
> is out of tree). This is still a useful debug tool for MADs and there
> are people who still use that.
It's an out of tree tool. Maintai
> In ib_mad.h, ib_mad_snoop_handler uses send_buf rather than send_wr
The MAD snooping should be removed from the mad stack. There are no in tree
users and the only attempt at adding one was rejected.
Thanks - applied
--
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
> >> +struct rvt_rwqe {
> >> + u64 wr_id;
> >> + u8 num_sge;
> >> + struct ib_sge sg_list[0];
> >> +};
> >> +
> >> +/*
> >> + * This structure is used to contain the head pointer, tail pointer,
> >> + * and receive work queue entries as a single memory allocation so
> >> + * it can be mmap'ed in
> > How about I reword the comment to say that while we could continue
> > allocating PDs being only constrained by system resources, the spec says
> > there is a limit so we enforce that?
>
> I'm ok with that, Sean?
That's fine
--
To unsubscribe from this list: send the line "unsubscribe linux-r
> >> Example: Compute nodes are assigned pkeys 0x8000 and 0x7fff. A node
> >> running the job scheduler has pkeys 0x and 0x8000 (maybe it's
> >> also the backup SA). Ibacm would need to select pkey 0x8000 for
> >> communication.
> >
> > I've also seen the reverse, eg 0x is used for defaul
> pkey[0] at least has the logic that the admin will configure things so
> that the default ipoib device reaches the broadest audiance makes the
> most sense to me. That is what most sites I've seen want to do.
Kaike, will pkey[0] work in the configurations that you're targeting with this
change?
> > 1. Find the first non-management full-member pkey;
I.e. a pkey with the high-order bit set that is not 0x
> > 2. If it fails, find pkey 0x;
>
> Order of 1 and 2 depends on use models for full default partition and
> other partitions. Reversing 1 and 2 (full default partition first) w
> > I mean that the user needs to investigate why the fabric is not working
> out of box.
>
> My point is that an educated admin should _know_ to configure in these
> cases and that debug is only when things are broken not by default in
> these more complex cases. This means the limitations of the
> > +* Determine the default pkey for parsing address file as well.
> > +* order of preference: first full-member non-management pkey,
> > +* 0x, first pkey.
> > +*/
>
> This really should just be the 0 index pkey, which exactly matches how
> IPoIB determines the default pk
> >> +#define RDMAVT_DRIVER_VERSION "0.1"
> >Do we really need driver version?
>
> Based on these patches thus far. Probably not. We do still have a bit more
> development to go here, I added it more as a just in case but am not
> steadfast in keeping it.
>
> What's the general rule here? Should
> > > +struct ib_pd *rvt_alloc_pd(struct ib_device *ibdev,
> > > +struct ib_ucontext *context,
> > > +struct ib_udata *udata)
> > > +{
> > > + struct rvt_dev_info *dev = ib_to_rvt(ibdev);
> > > + struct rvt_pd *pd;
> > > + struct ib_pd *ret;
> > > +
> > > + p
> drivers/infiniband/sw/rdmavt/qp.h |5 -
> include/rdma/rdma_vt.h| 233
> +
> 2 files changed, 233 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/infiniband/sw/rdmavt/qp.h
> b/drivers/infiniband/sw/rdmavt/qp.h
> index 4e4709f..c80d326
> include/rdma/rdma_vt.h | 53
>
> 1 files changed, 53 insertions(+), 0 deletions(-)
>
> diff --git a/include/rdma/rdma_vt.h b/include/rdma/rdma_vt.h
> index 5112dd7..39a0737 100644
> --- a/include/rdma/rdma_vt.h
> +++ b/include/rdma/rdma_vt.h
>
> +/*
> + * Check driver override. If driver passes a value use it, otherwise we
> use our
> + * own value.
> + */
> +#define CDR(rdi, x) \
> + rdi->ibdev.x = rdi->ibdev.x ? : rvt_ ##x
This is an extremely obscure name.
No one will be able to look at this:
> + CDR(rdi, alloc_pd);
> +
> @@ -0,0 +1,89 @@
> +/*
> + *
> + * This file is provided under a dual BSD/GPLv2 license. When using or
> + * redistributing this file, you may do so under either license.
> + *
> + * GPL LICENSE SUMMARY
> + *
> + * Copyright(c) 2015 Intel Corporation.
I'm guessing that the GPL license text does
> +static int rvt_query_device(struct ib_device *ibdev,
> + struct ib_device_attr *props,
> + struct ib_udata *uhw)
> +{
> + /*
> + * Return rvt_dev_info.props contents
> + */
> + return -EINVAL;
ENOSYS on all of the function templa
> The following series implements rdmavt. This is the rdma verbs transport
> software library
This is going to be an annoying request, but I would rather see this named the
IB transport library, unless this framework is usable over iWarp as well.
N�r��yb�X��ǧv�^�){.n�+{��ٚ�{ay� ʇڙ�,j
> +struct ib_pd *rvt_alloc_pd(struct ib_device *ibdev,
> +struct ib_ucontext *context,
> +struct ib_udata *udata)
> +{
> + struct rvt_dev_info *dev = ib_to_rvt(ibdev);
> + struct rvt_pd *pd;
> + struct ib_pd *ret;
> +
> + pd = kmalloc(
> IIRC responding to Get(CPI) is mandatory?
Maybe the drivers are responding? I don't believe that the CM does.
--
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-i
> > + /* CM attributes other than ClassPortInfo only use Send method
> */
> > + if (mad_hdr->mgmt_class == IB_MGMT_CLASS_CM) {
> > + if (mad_hdr->attr_id != IB_MGMT_CLASSPORTINFO_ATTR_ID) {
> > + if (mad_hdr->method != IB_MGMT_METHOD_S
> Receipt of CM MAD with response method for other than ClassPortInfo
> attribute is invalid.
>
> CM attributes other than ClassPortInfo use send method only
> and GetResp is valid for ClassPortInfo attribute.
> Note also that the CM ClassPortInfo is not currently supported.
>
> The SRP initiator
Merged - thanks.
This is the first patch against the libibcm in over 4 years. Is there a reason
why this is being used instead of the librdmacm? I ask because I assumed that
the libibcm was basically deprecated. The last release was over 6 years ago.
- Sean
> > Sean, I need to close on this patch. What is your position after
> > Matan's explanation?
> >
>
> Absent an objection from Sean, I've pulled this in. A use after free
> bug is a pretty serious issue, and you've listed an error flow that
> triggers it. The only thing bugging me is that this
> Today, cm assumes paths are reversible primary_path->reversible = 1.
I can't quickly find a link, but I believe all CM MADs are reversible, per the
spec.
> >> ib_create_ah_from_wc needs to resolve the DMAC in order to create the
> >> AH (this may result sending an ARP and waiting for response).
> >> CM uses this function (which is now sleepable).
> >
> > This is a significant change to the CM. The CM calls are invoked
> assuming that they return re
> On Mon, Oct 12, 2015 at 7:42 PM, Hefty, Sean wrote:
> >> When IP based addressing was introduced, ib_create_ah_from_wc was
> >> changed in order to support a suitable AH. Since this AH should
> >> now contains the DMAC (which isn't a simple derivative of the G
> When IP based addressing was introduced, ib_create_ah_from_wc was
> changed in order to support a suitable AH. Since this AH should
> now contains the DMAC (which isn't a simple derivative of the GID).
> In order to find the DMAC, an ARP should sometime be sent. This ARP
> is a sleeping context.
> ib_send_cm_sidr_rep could sometimes erase the node from the sidr
> (depending on errors in the process). Since ib_send_cm_sidr_rep is
> called both from cm_sidr_req_handler and cm_destroy_id, cm_id_priv
This should clarify that it is the app calling from the callback, and not a
direct call from
Thanks - merged all 3
--
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
> >The issue is that basically no one tests the releases of the packages.
>
> We assume that the maintainer of the package tests it before they release
> it :)
No one has access to that many pieces of hardware and system configurations.
The "community" can't dump the responsibility for testing
> Anyway, I had intended, and I've started on, making a change in how
> libibverbs is done anyway. The idea that a new release is just a script
> that throws a version on and we go is naive. I *will* be doing
> pre-release rc tarballs and there will be testing and there will be a
> release proces
> diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
> index ea4db9c..8fab3a7 100644
> --- a/drivers/infiniband/core/cm.c
> +++ b/drivers/infiniband/core/cm.c
> @@ -2812,7 +2812,12 @@ static int cm_lap_handler(struct cm_work *work)
> cm_init_av_for_response(work->port, w
What kernel is this patch against?
> Allocating a workqueue might fail, which wasn't checked so far and would
> lead to NULL ptr derefs when an attempt to use it was made.
>
> Signed-off-by: Sasha Levin
> ---
> drivers/infiniband/core/ucma.c |7 ++-
> 1 file changed, 6 insertions(+), 1
> > Trying to limit the number of QPs that an app can allocate,
> > therefore, just limits how much of the address space an app can use.
> > There's no clear link between QP limits and HW resource limits,
> > unless you assume a very specific underlying implementation.
>
> Isn't that the point tho
> So, the existence of resource limitations is fine. That's what we
> deal with all the time. The problem usually with this sort of
> interfaces which expose implementation details to users directly is
> that it severely limits engineering manuevering space. You usually
> want your users to expr
> > In past there has been similar comment to have dedicated cgroup
> > controller for RDMA instead of merging with device cgroup.
> > I am ok with both the approach, however I prefer to utilize device
> > controller instead of spinning of new controller for new devices
> > category.
> > I anticipa
> right now RDMA/CM works on a QP basis, but seems very awakward if you
> want multiple QPs as part of a single logical device, which will be
> useful for a lot of modern protocols. For example we will need to check
> in the CM handler that we're not getting a different ib_device if we
> want to a
> This fixes the incorrect assumation that the function ib_send_cm_drep
> always runs successfully and never fails in the function rdma_disconnect
> by making this call be assigned the variable used to return to callers
> of rdma_disconnect in order to make sure that a error code is returned
> if a
> diff --git a/drivers/infiniband/core/multicast.c
> b/drivers/infiniband/core/multicast.c
> index 2cb865c..9284337 100644
> --- a/drivers/infiniband/core/multicast.c
> +++ b/drivers/infiniband/core/multicast.c
> @@ -526,8 +526,9 @@ static void join_handler(int status, struct
> ib_sa_mcmember_rec *
> This fixes error handling in the function cm_init_av_by_path
> to properly check if the internal call to the function
> ib_init_ah_from_path has failed by returning a error code and
> if so return immediately to the caller with this error code in
> order to signal/allow the caller to handle the e
> This fixes mutex locking to lock before unlocking in the function
> cma_ib_mc_handler for the mutex handler_mutex as part of the pointer
> id_priv before unlocking it after the critical region for event handler
> work and execution in order to have actual proper concurrent execution
> protection
This series looks reasonable to me
--
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
> AFAIK, this path is rarely (never?) actually used. I think all the
> drivers we have can post directly from userspace.
I didn't think the ipath or qib drivers post from userspace.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.
> Something like this:
>
> CPU A CPU B
>
> ucma_destroy_id()
> wait_for_completion()
> .. anything
> ucma_put_ctx()
>
> I don't think we should over-complex things vs. what the network stack
> does for many (since kernel 2.4?!) years. They have basically three
> flags
>
> NETIF_F_IP_CSUM - device can checksum TCP/UDP over IPv4
> NETIF_F_IP6_CSUM - device can checksum TCP/UDP over IPv6
> NETIF_F_HW_CSUM - device c
> > > +enum ib_csum_cap_flags {
> > > + IB_CSUM_RX_TCP_UDP = 1 << 0,
> > > + IB_CSUM_RX_IP_HDR= 1 << 1,
> > > + IB_CSUM_TX_TCP_UDP = 1 << 2,
> > > + IB_CSUM_TX_IP_HDR= 1 << 3
> > > +};
> >
> > TPC and UDP should be separate flags.
>
> Can you explain why?
For the same
> +enum ib_csum_cap_flags {
> + IB_CSUM_RX_TCP_UDP = 1 << 0,
> + IB_CSUM_RX_IP_HDR= 1 << 1,
> + IB_CSUM_TX_TCP_UDP = 1 << 2,
> + IB_CSUM_TX_IP_HDR= 1 << 3
> +};
TPC and UDP should be separate flags.
--
To unsubscribe from this list: send the line "unsubs
> please take a look at my RFC patch here:
>
> http://git.infradead.org/users/hch/scsi.git/commitdiff/751774250b71d
> a83a26ba8584cff70f5e7bb7b1e
>
> the commit contains my explanation, but apparently the patch is too
> large for the list limit and didn't make it through.
This looks like a
> I think it would be better just to remove the service_mask parameter
> from this function, right? rdma_cm makes no use of the service mask.
If it is not being used, then, yes, I would remove it.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to
> @@ -1040,6 +1040,181 @@ static int cma_save_net_info(struct sockaddr
> *src_addr,
> return cma_save_ip_info(src_addr, dst_addr, ib_event, service_id);
> }
>
> +struct cma_req_info {
> + struct ib_device *device;
> + int port;
> + const union ib_gid *local_gid;
The use of a po
> Add helper functions to access the IDRs by port-space and port number.
>
> Pass around the port-space enum in cma.c instead of using pointers to
> port-space IDRs.
Why?
> drivers/infiniband/core/cma.c | 81 --
> -
> 1 file changed, 60 insertions(+), 21
> +/**
> + * Create a new listening ib_cm_id and listen on the given service ID.
> + *
> + * If there's an existing ID listening on that same device and service
> ID,
> + * return it.
> + *
> + * @device: Device associated with the cm_id. All related communication
> will
> + * be associated with t
> The lkey is possibly useful if someone wants to do single op transfers
> larger than the S/G limit of the SQE. I haven't noticed any ULPs doing
> that..
That changes how the buffer is identified, which gets back to my question of
are we identifying local buffers by address or through some sort
> > This may be a nit, but IMO, the use of the term 'rkey' versus 'stag'
> matters. They convey different ways of finding a data
> buffer. For
> > example, do you locate a buffer using the stag, then verify that the
> offset + length fits into the target buffer?
>
> Yes. HW always uses the stag
> I'm use
> cat /sys/class/infiniband/mlx4_0/ports/1/gids/0
>
> fe80::::0002:c903:00ef:6601
>
> In node I'm use gid provided below service null, hints contains af_ib and
> rai_family|rai_numerichost
Ah, yes, the rdma_cm supports GIDs. It does not support GUIDs. Though it's
usually
> There is confusion about lkeys and rkeys with regard to iWARP. In the
> iWARP verbs, there is no distinction between an lkey and
> rkey: they are the same key, called a Steering Tag or STAG. When you
> create a MR, the lkey == rkey == STAG for iwarp transports.
> Somewhat related, but really a
> >> Hello, does it possible to use rdma_getaddrinfo and specify in node
> port
> >> GUID?
> >
> > The current code does not support this.
>
>
> Why rdma_getaddrinfo does not return error? Why it returns success and
> result contains port guid?
I don't think I'm following your questions on how r
> Hello, does it possible to use rdma_getaddrinfo and specify in node port
> GUID?
The current code does not support this.
> +enum ib_mr_type {
> + IB_MR_TYPE_FAST_REG,
> + IB_MR_TYPE_SIGNATURE,
If we're going to go through the trouble of changing everything, I vote for
dropping the word 'fast'. It's a marketing term. It's goofy. And the IB spec
is goofy for using it.
--
To unsubscribe from this list: send
> > This just emphasizes why we need to converge to a single method.
>
> In my opinion, we already have it.
>
> For local registrations, ib_reg_phys_mr()/ib_get_dma_mr(). These are not
> quite equivalent, btw.
Personally, I would work to eliminate local registration as part of the API.
> For re
> I am still not clear if all of us agree that we need it.
> Sean and Steve had some disclaimers...
A single entry point doesn't help a whole lot if the app must deal with
different behavior based on how the API is used. We have a single entry point
for post_send, for example, and that makes th
> include/uapi/rdma/rdma_netlink.h | 87
> ++
> 1 files changed, 87 insertions(+), 0 deletions(-)
>
> diff --git a/include/uapi/rdma/rdma_netlink.h
> b/include/uapi/rdma/rdma_netlink.h
> index 6e4bb42..d2c50e9 100644
> --- a/include/uapi/rdma/rdma_netlink.h
>
> I suggest to start consolidating to ib_create_mr() that receives an
> extensible ib_mr_init_attr and additional attributes can be mr_roles
> and mr_attrs.
I think this makes sense, but does it really help? If the end result is that
the app and providers basically end up switching on mr_attr::t
> > I prefer to decouple the iSER changes with this core work.
> > Jason/Sean... thoughts? I could do the iSER w/o patch 3, and the
> > follow up with a series that includes our final solution on
> > transport independent memory registration and change all the TI
> > kernel users (iser and nfsrdma
> > > > +enum rdma_mr_roles {
> > > > + RDMA_MRR_RECV = 1,
> > > > + RDMA_MRR_SEND = (1<<1),
> > > > + RDMA_MRR_READ_SOURCE= (1<<2),
> > > > + RDMA_MRR_READ_SINK = (1<<3),
> > >
> > > Maybe it's just me, but it too
> I wanted to point out that with this scheme the ULP may sometimes get an
> MR with a wider set of permissions that it asked for, and I'm not sure
> that's always safe. Perhaps the ULP wants to guarantee that the MR
> doesn't allow certain kinds of accesses and doesn't expect the verbs
> layer to
> +enum rdma_mr_roles {
I would drop naming the enum - it shouldn't be used, as the values are bit
flags.
> + RDMA_MRR_RECV = 1,
> + RDMA_MRR_SEND = (1<<1),
> + RDMA_MRR_READ_SOURCE= (1<<2),
> + RDMA_MRR_READ_SINK = (1<
> What about moving to something more specific? Encode the allowed verbs
> in the access flag?
This makes more sense to me. Something like: SEND, RECV, INIT READ, INIT
WRITE, READ TARGET, WRITE TARGET, etc. We're close to this, but it's not
clear, for example, what flags are needed for a recei
> How would you envision doing this? At the time a MR is registered the
> device driver doesn't know if the application will be doing
> RDMA reads or not on that MR.
I was thinking of checking for REMOTE_READ, but that doesn't work on the
initiator side.
I guess you could a READ_DEST(SOURCE? TA
> > +* IWARP transports need REMOTE_WRITE for MRs used as the target of
> > +* an RDMA_READ. Since the DMA MR is used for all ports, then if
> > +* any port is running IWARP, add REMOTE_WRITE.
> > +*/
> > + if (any_port_is_iwarp(device))
>
> It would be nice to have a new-style
> rds_ib_add_one says:
> /* Only handle IB (no iWARP) devices */
> but not sure comment is 100% accurate as it checks node type != IB CA.
>
> rds_ib_laddr_check says:
> /* rdma_bind_addr will only succeed for IB & iWARP devices */
> /* due to this, we will claim to support iWARP devices unless we
> Note that there still remain a couple of node type checks in the kernel
> that we may want to remove. There's an IB CA check in cma.c:rdma_notify
This should check for rdma_cap_ib_cm()
> as well as in rds/ib.c:rds_ib_add_one and rds_ib_laddr_check and
Not sure what the underlying reason is for
> In an effort to reform the RDMA core and ULPs to minimize use of
> node_type in struct ib_device, an additional bit is added to
> struct ib_device for is_switch (IB switch). This is needed
> to be initialized by any IB switch device driver. This is a
> NEW requirement on such device drivers which
> In an effort to reform the RDMA core and ULPs to minimize use of
> node_type in struct ib_device, an additional bit is added to
> struct ib_device for is_switch (IB switch). This is needed
> to be initialized by any IB switch device driver. This is a
> NEW requirement on such device drivers which
> Ummm.. Could we get some more descriptions as to what this code is for?
>
> Do we have a new OmniPath protocol here as well or is it IB? Which
> standards are followed?
>
> I think the APIs that the driver uses need to be documented somewhere in
> particular if new sysfs entries etc are created
> >>> include/rdma/opa_port_info.h | 433
> >>
> >> This matches the current code structure, but is this the best location
> for this file?
> >
> > Do you have a suggestion?
>
> Couldn't it be a header in the hfi1 driver directory ? Isn't it OPA
> specific ?
I don't have a specific suggesti
> PSM2 (and PSM) uses this to dialog with the driver for hardware specific
> setup.
>
> I'm suspected at some point in the past, this was ioctl based and changed
> due to bias against ioctl.
Could this be distinguished based on a common command header?
--
To unsubscribe from this list: send the l
Thanks - applied manually
> acm/src/acme.c |2 +-
Path?
> diff --git a/acm/src/acme.c b/acm/src/acme.c
> index 9bf7557..d54c8b9 100644
> --- a/acm/src/acme.c
> +++ b/acm/src/acme.c
> @@ -787,7 +787,7 @@ static int inet_any_pton(char *addr, struct sockaddr
This was off by a couple hundred li
> You're right that apps can be coded to other CA types, like RNICs and
> USNICs. However, those are all very different from an IB_CA due to
> limited queue pair types or limited primitives. If OPA had that same
> limitation then I would agree it needs a different node type.
>
> So this will be
> The idea is to allow SIDR request to be sorted by the GID, when we will
> have alias GIDs for IPoIB.
Please limit this series, or at least the early patches in this series, to
simply moving the de-mux out of the ib_cm and into the rdma_cm.
--
To unsubscribe from this list: send the line "unsubs
> drivers/infiniband/hw/hfi1/mad.h | 477
> ++
> 1 file changed, 477 insertions(+)
> create mode 100644 drivers/infiniband/hw/hfi1/mad.h
>
> diff --git a/drivers/infiniband/hw/hfi1/mad.h
> b/drivers/infiniband/hw/hfi1/mad.h
> new file mode 100644
> index
> Add helper functions to access the IDRs by port-space and port number.
>
> Pass around the port-space enum in cma.c instead of using pointers to
> port-space IDRs.
What is the motivation for this change?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a m
> -static int cma_save_net_info(struct rdma_cm_id *id, struct rdma_cm_id
> *listen_id,
> - struct ib_cm_event *ib_event)
> +static u16 cma_port_from_service_id(__be64 service_id)
> {
> - struct cma_hdr *hdr;
> + return be64_to_cpu(service_id);
> +}
Nit - Does the
> @@ -722,6 +725,7 @@ struct ib_cm_id *ib_create_cm_id(struct ib_device
> *device,
> INIT_LIST_HEAD(&cm_id_priv->work_list);
> atomic_set(&cm_id_priv->work_count, -1);
> atomic_set(&cm_id_priv->refcount, 1);
> + cm_id_priv->listen_sharecount = 1;
This is setting the listen co
> drivers/infiniband/core/cm.c | 7 +++
> include/rdma/ib_cm.h | 2 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
> index c5f5f89e274a..46f99ec4080a 100644
> --- a/drivers/infiniband/core/cm.c
> +++ b/drivers/infinib
> Expose the service ID on an incoming CM or SIDR request to the event
> handler. This will allow the RDMA CM module to de-multiplex connection
> requests based on the information encoded in the service ID.
>
> Signed-off-by: Haggai Eran
Acked-by: Sean Hefty
--
To unsubscribe from this list: se
> Was Al Viro's comment on qib addressed here? That would be a
> showstopper for me..
Do you have a link to this comment? I'm missing a bunch of messages from this
thread and can't find anything from Al in the logs.
- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma"
> > +int __init dev_init(void)
> > +{
> > + int ret;
> > +
> > + ret = alloc_chrdev_region(&hfi1_dev, 0, HFI1_NMINORS,
> DRIVER_NAME);
> > + if (ret < 0) {
> > + pr_err("Could not allocate chrdev region (err %d)\n", -
> ret);
> > + goto done;
> > +
> include/rdma/opa_port_info.h | 433
This matches the current code structure, but is this the best location for this
file?
> > I agree that the node type enum isn't particularly useful and should be
> retired.
>
> Are you referring to kernel space or user space or both ?
Short term, kernel space. User space needs to keep something around for
backwards compatibility.
But the in tree code will never expose this valu
> > cap_is_switch_smi would be a nice refinement to let us drop nodetype.
>
> Exactly, we need a bit added to the immutable data bits, and a new cap_
> helper, and then nodetype is ready to be retired. Add a bit, drop a
> u8 ;-)
I agree that the node type enum isn't particularly useful and shoul
> Intel is supporting multicast in hardware. Its just a bad implementation
> (broadcast and filtering MC groups in the HCA or what was that?) and there
> is no plan to fix the issues despite the problem being known for quite
> some time. Also does this mean that libfabric only to supports the
> fea
> Not directly. IPoIB treats it that way. I guess to "be safe".
>
> Officially one should register for UnPath/RePath traps. But no one has
> ever implemented that.
>
> To be clear I am agreeing with Hal that having some sort of "update
> signal" would be nice. But I don't think that must be d
> > > This series does not attempt to optimize the kernel needing to know
> > > that a PR has been updated. There are existing mechanisms for that.
> >
> > Does this exist in the kernel?
>
> At least some support, yes. For example client reregister marks all IPoIB
> paths as invalid.
Reregister
> >>> +/* Local Service Reversible attribute */ struct
> >>> +rdma_nla_ls_reversible {
> >>> + __u32 reversible;
> >>> +};
> >>
> >> Isn't __u8 sufficient for reversible ?
> > Certainly enough. However, reversible is __u32 in struct
> ib_user_path_rec and int in struct ib_sa_path_rec.
>
> This series does not attempt to optimize the kernel needing to know that a
> PR
> has been updated. There are existing mechanisms for that.
Does this exist in the kernel?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.
> Not in the patches themselves but in the general issue when a PR changes.
>
> Do you think this needs addressing or are things fine as they are now ?
IMO, I think it needs addressing in terms of "can the proposed netlink
architecture and design accommodate this sort of request in the future?"
> There are multiple problems with libfrabric related to the use cases in my
> area. Most of all the lack of multicast support. Then there is the build
> up of software bloat on top. The interest here is in low latency
> operations. Redenzvous and other new features are really not wanted if
> they
> RDMA_CM_EVENT_UNREACHABLE is indicated when there are timeouts in
> underlying CM protocol exchange. I suspect that the server is really
> busy and doesn't respond to the low level CM MADs in a timely manner.
> RDMA CM (and other kernel ULPs like IPoIB and SRP use hard coded local
> and remote re
1 - 100 of 1448 matches
Mail list logo
