> > Registering an event handler is done for a device. This device may have
> > one RoCE port (no SA cap) and one InfiniBand port (has SA cap).
> > Therefore, warning from the event handler about a specific port that
> > doesn't have SA cap is correct but pollutes the kernel log without a
> > need.
> While this appears to address the current upstream use model for ACM
> with it's multicast overlay backend where PRs are static, it does not
> appear to address PR changes.
Although this ties into ibacm, from the viewpoint of the kernel, there's no
requirement on the user space implementation.
> Sean, this change is needed b/c two drivers have (mlx4 and ocrda) and
> more two to come soon (mlx5 and soft-Roce) would have the very same
> logic of constructing the port GID table according to netdev events and
> such, no point in repeating this logic/code over and over.
>
> Matan explained w
> --- a/drivers/infiniband/hw/mlx5/mr.c
> +++ b/drivers/infiniband/hw/mlx5/mr.c
> @@ -1174,6 +1174,18 @@ static int clean_mr(struct mlx5_ib_mr *mr)
> int umred = mr->umred;
> int err;
>
> + if (mr->sig) {
> + if (mlx5_core_destroy_psv(dev->mdev,
> +
> Previously, every vendor implemented its net device notifiers in its own
> driver. This introduces a huge code duplication as figuring
> 28 files changed, 2253 insertions(+), 860 deletions(-)
How does adding 1400 lines of code help reduce code duplication?
Can you please explain and justify
> In order to support that we provide the user with an interface
> to pass a scattered list of buffers to the IB core layer called
> ib_indir_reg_list and provide a new send work request opcode
> called IB_WR_REG_INDIR_MR. We extend wr union with a new type of
> memory registration called indir_reg
> @@ -1693,8 +1693,11 @@ struct ib_device {
> u8 port_num,
> const struct ib_wc *in_wc,
> const struct ib_grh *in_grh,
> -
> The flag RDMA_CORE_CAP_IB_SA is set when link layer is InfiniBand but
> also when link layer is Ethernet. Therefore, link layer is not implied by
This flag should NOT be set for Ethernet. What is setting this?
> this flag.
>
> ---
> drivers/infiniband/core/cma.c |2 +-
> 1 files changed,
> > If I were adding timestamps, I would probably define a new completion
> > structure with 2 u64 time stamp fields (start and end times), and figure
> > out when start occurred, end occurred, and the timing metric later. :)
>
> Not sure why you would need the start. The app knows when it submit
> Yes, I saw Sean's comment, and I am glad we all understand there are
> only 3 callers. And looking at the callers there are only a small
> number of elements being used:
>
> rdma cm:
> IB_SA_PATH_REC_DGID | IB_SA_PATH_REC_SGID |
> IB_SA_PATH_REC_PKEY | IB_SA_PATH_REC_NUMB_PA
> I am very surprised to see this layered under send_mad, all the
> context is lost at that point, and it makes it impossible to provide
> all the non-IB context (IP addrs, netdevs, QOS, etc)
It's layered under query path record. This should provide the most benefit to
the most applications, inc
> Can you share what the libfabric change would look like to add a
> timestamp field to the completion? That might be informative,
> libfabric is also consuming the kernel UAPI.
Libfabric uses a CQ format option. so this would just require a new format.
There is no type checking on CQ poll (read)
> No, if they followed (I didn't check yes) the extension scheme then the
> poll call is
>
> struct ibv_wc_ex wcs[num_wcs]
> ibv_poll_wc_ex(&wcs,num_wcs,sizeof(wcs[0]));
>
> And the drivers decide what to do based on the 3rd argument, which is
> essentially the ABI version.
As a couple of opti
> We want to have a time stamp when the action is complete and the data is
> available to the application or the send action is complete and the CQ
> entry can be reused.
This is what polling the completion from the CQ tells you, independent of there
being a time stamp.
--
To unsubscribe from thi
> The use case is clear IMO. It's for financial trading software. I
> don't think they really care about details like whether it's the start
> or end packet, or completion, or whatever. They need a tie breaker
> between when they have two different buy or sell orders on the same lot
> of stock.
> Now, as a general rule, I would call timestamps general. They should be
> added in a fashion that anyone can implement. They should also be well
> defined. Sean's questions raise a very valid point. Exactly what is
> being timestamped, and do we care about different timestamp options? Is
> i
> What is the issue here? The timestamp is created when the processing is
> finished by the nic and the completion entry becomes available.
The timestamp is generated when a work completion entry is written. If there's
a clear use case for this, it hasn't been described. The use case you
menti
> > > Second: What about wrap around? Does it even make sense to expose less
> > > than 64 bits to userspace? Should the driver manage wrap around to
> > > create a flat 64 bit space?
> >
> > The wrap around is given by the mask. Cycle registers are often shorter
> > than 64 bits.
>
> I am aware o
> > #define IB_NL_DATA_TYPE_INVALID 0x
> > #define IB_NL_DATA_TYPE_NAME0x0001
> > #define IB_NL_DATA_TYPE_ADDRESS_IP 0x0002
> > #define IB_NL_DATA_TYPE_ADDRESS_IP6 0x0003
> > #define IB_NL_DATA_TYPE_PATH_RECORD 0x0004
> > #def
> It remains to clean up ib_cm's ib_cm_listen interface now that
> compare_data isn't used, but I'm not sure this belongs in this series.
This patch series is changing the behavior that the compare data solves.
Currently, the ib_cm handles all of the multiplexing for the rdma_cm -- that's
the r
> The value is 0 by default (kzalloc) and is why I wrote the comment like I
> did.
My objection with the comment is that it was not describing what the function
did, but rather the value that should be stored in the structure. Basically,
it seemed misplaced.
--
To unsubscribe from this list: se
> Can I add your reviewed by after this change?
Yes - I've reviewed all patches except 10 and 14 so far.
--
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
> @@ -2678,7 +2693,8 @@ static int ib_mad_post_receive_mads(struct
> ib_mad_qp_info *qp_info,
> mad_priv = mad;
> mad = NULL;
> } else {
> - mad_priv = kmem_cache_alloc(ib_mad_cache, GFP_KERNEL);
> + m
> +/**
> + * rdma_max_mad_size - Return the max MAD size required by this RDMA
> Port.
> + *
> + * @device: Device
> + * @port_num: Port number
> + *
> + * Return the max MAD size required by the Port. Should return 0 if the
> port
> + * does not support MADs
> + */
> +static inline size_t rdma_ma
> diff --git a/drivers/infiniband/core/smi.c b/drivers/infiniband/core/smi.c
> index b09fa1dec865..4969ce3338fb 100644
> --- a/drivers/infiniband/core/smi.c
> +++ b/drivers/infiniband/core/smi.c
> @@ -236,21 +236,20 @@ enum smi_action smi_handle_dr_smp_recv(struct ib_smp
> *smp, u8 node_type,
>
> diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
> index 9cd4ce8dfbd0..96daba58afad 100644
> --- a/drivers/infiniband/core/mad.c
> +++ b/drivers/infiniband/core/mad.c
> @@ -1924,6 +1924,52 @@ static void ib_mad_complete_recv(struct
> ib_mad_agent_private *mad_agent_priv,
> As I mentioned, I think there is a pretty strong tie between the kernel
> stack the libibverbs. Especially when you consider that things like
> verbs extensions need to be synced between the two. That's why I'm
> offering/suggesting that it would be a good idea that I handle it along
> with the
> The other issue is that each caller in the kernel specifies a different
> timeout. Defining this in 1 central place and allowing user space to
> control
> the policy of that timeout is much better than allowing the kernel clients
> to
> specify the timeout as they do now.
Everything has been ra
> I'm not sure there is much use case for letting user space get
> involved in arbitary MAD traffic..
I was thinking more about easily supporting other queries - ServiceRecords,
MCMemberRecords, etc. The only use case I'm currently aware of is PathRecords,
however.
> Over generalizing feels li
> > N?r??yb?X??ǧv?^?){.n?+{??ٚ?{ay? ʇڙ?,j
??f???h???z? ?w???
>
> ???j:+v???w?j?m
zZ+?ݢj"??!
>
> Does anyone else ever wonder what this garbage is on some of the
> messages from @intel folks?
I believe it's some weird formatting of:
> To unsubscribe from this list: send
> Resent due to mailer issues
Next time, please put this comment under the '---', so that it doesn't end up
in the patch description.
> Support for using UD and AF_IB is currently broken. The
> IB_CM_SIDR_REQ_RECEIVED
> message is not handled properly in cma_save_net_info() and we end up
> fall
> For the UDP port used by the usNIC QP, the usnic_verbs kernel driver
> requires user space to pass a file descriptor of a regular UDP socket down
> at create_qp time. The reference count on this socket is incremented to
> make sure that the socket can't disappear out from under us. Then an RX
>
> Is the concern here about CM issues or the UDP ports used by the actual
> usNIC RQs?
UDP port space sharing
--
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-inf
> > Keep in mind that this enum was Liran's response to Michael's original
> > patch. In the enum in Michael's patch, there was both USNIC and
> > USNIC_UDP.
>
> Right! That's why I'm confused. Seems wrong to drop it, right?
I think the original USNIC protocol is layered directly over Ethernet.
> > > I thought we were dropping this in favor of listing the actual
> > > features the ULP required unconditionally? One of my messages had the
> > > start of a list..
>
> ??? I forget. I was arguing that we should not have it. But I thought
> others
> disagreed with me so it was left in.
I d
> > So, I think that our "old-transport" below is just fine.
> > No need to change it (and you aren't, since it is currently implemented
> as a function).
>
> I think there is a need to change this. Encoding the transport into the
> node
> type is not a good idea. Having different "transport sem
> The RoCE Verbs interface references the HCA GID table in QPs and AHs, for
> all RoCE versions.
The IBTA specifically does not define software interfaces. The concern here is
the architecture and definition of the linux rdma software stack, not verbs,
despite the fact that the layer is named t
> > To be confirmed:
> > PORT ASSIGNED
> > rdma_init_qp_attr Y
> > rdma_destroy_id unknown
> > cma_listen_on_dev N
> > cma_bind_loopback N
Bind loopback will attach to a port, but the id does not have on entry.
> > rdma_lis
> > No idea, but having ib_register_device fail and unwind if a client
> > fails to attach makes sense to me.
>
> It seems a bit unfriendly to fail an entire device if one ULP has a
> problem. Let's say you have a system whose main network connection is
> IPoIB. Would you want that connection to
> After the discussion settled, I ended up thinking that implementing
> explicit device checks, for use by CM, and the BUG_ON at register to
> require all ports have the same value was the best option.
Sure, but why not update the other areas anyway? This way when listens become
per port, rather
> >> diff --git a/drivers/infiniband/core/cma.c
> b/drivers/infiniband/core/cma.c
> >> index 65e41f4..7f5815d 100644
> >> --- a/drivers/infiniband/core/cma.c
> >> +++ b/drivers/infiniband/core/cma.c
> >> @@ -470,7 +470,7 @@ static int cma_resolve_ib_dev(struct
> rdma_id_private *id_priv)
> >>
> >>
> > RoCE v2 is really Infiniband over UDP over IP. Why don't we just call
> it IBoUDP like it is?
> RoCEv2 is the name in the IBTA spec (Annex 17)
We call RoCE IBoE in the kernel, because that's what it is. RoCE is an IBTA
marketing name.
Looking through the Annex, I don't see where Ethernet i
> > This is equivalent to today where the checks are per node rather than
> > per port.
> >
> > Should all checks here be port 1 based or only certain ones like listen
> > ? For example, in connect/reject/disconnect, don't we already have port
> > ? Guess this can be dealt with later as this is not
> libibverbs also exposes transport at the device level. Isn't a change to
> make transport per port rather than per device needed there as well to
> be consistent with these proposed kernel changes ? If so, would the
> additional IBoE transport be exposed ? We also need to worry about
> backward c
> It does not break every app, the choice of which GID type to use is made
> by the RDMA-CM based on network topology hint obtained from the IP stack.
> Please refer to patch 15/33: IB/Core: Changes to the IB Core
> infrastructure for RoCEv2 support.
> Of course, if the user does not want to go wi
> Yes, that is the only reasonable thing that could happen.
>
> init failure should only be possible under exceptional cases (OOM).
>
> The only system response is to call ib_umad_add_one again - so of
> course the first call had to completely clean up everything it did.
A reasonable follow up c
> This is a part of the GID meta info. The user should be able to choose
> between RoCE V1 (which is represented here by IB_GID_TYPE_IB) and RoCE
> V2 - just as a user could choose between IPv6 and IPv4.
IPv4 and IPv6 are different protocols, not different formats for the same
address. How does
> But that moves us in the wrong direction. If we later support port 2
> without
> port 1 that code will be broken.
I agree that the code will be broken, but supporting that model requires a lot
more work in how the ib_cm listens across devices.
--
To unsubscribe from this list: send the line "u
> Yes, this comment probably could use a reword..
> > > + IB_GID_TYPE_IB= 0,
> > > + IB_GID_TYPE_ROCE_V2 = 1,
> > > + IB_GID_TYPE_SIZE
> > > +};
> >
> > Can you explain the purpose of defining a 'GID type'. A GID is just a
> global
> > address. Why does it matter to anyone using it how
> On Mon, Apr 13, 2015 at 07:25:48PM +0000, Hefty, Sean wrote:
> > > @@ -1037,17 +1033,13 @@ void rdma_destroy_id(struct rdma_cm_id *id)
> > > mutex_unlock(&id_priv->handler_mutex);
> > >
> > > if (id_priv->cma_dev) {
> > > -
> @@ -1037,17 +1033,13 @@ void rdma_destroy_id(struct rdma_cm_id *id)
> mutex_unlock(&id_priv->handler_mutex);
>
> if (id_priv->cma_dev) {
> - switch (rdma_node_get_transport(id_priv->id.device-
> >node_type)) {
> - case RDMA_TRANSPORT_IB:
> + if (rd
> @@ -1153,9 +1153,7 @@ static void ib_sa_add_one(struct ib_device *device)
> {
> struct ib_sa_device *sa_dev;
> int s, e, i;
> -
> - if (rdma_node_get_transport(device->node_type) != RDMA_TRANSPORT_IB)
> - return;
> + int count = 0;
>
> if (device->node_type
> > - if (rdma_node_get_transport(ib_device->node_type) !=
> RDMA_TRANSPORT_IB)
> > - return;
> > + int count = 0;
>
> I'm ok with this as an intermediate patch but going forward if we are
> going to
> have calls like
>
> static inline int cap_ib_cm_dev(struct ib_device *device)
I
> Same here (having been asked privately to look into doing this). FWIW,
> Red Hat has agreed that they are willing to allow me to transition my job
> to a full time upstream focused position (as of now, I work on upstream
> around my deliverables inside the company).
Excellent. To me, this seem
> Unfortunately, Sean -- you haven't provided for > 2 months any
> feedback on the patches to the CM/CMA modules which you own/maintain
> for supporting name-spaces and such which are part of enabling proper
> RDMA support for containers.
> http://marc.info/?l=linux-netdev&m=142366747608908&w=2 Thi
> I'm on a perhaps-unfortunately-timed vacation this week, but to make
> the transition smooth, I'll handle the easy patches that are in flight
> for 4.1, and then turn things over to the community for 4.2. (Unless
> the feeling is that it's better for me to step down immediately — I
> have no pro
> > This thread has made me realize that even as I am able to carve out
> > more time to work on things like IB maintaintership, I no longer
> > have the desire to spend my time maintaining the IB subsystem.
> > Since my current level of activity is clearly hurting the community,
> > I've decided t
> > Didn't an earlier patch make is possible to read the mad_size directly
> from the device?
> >
>
> Not exactly, that patch specified the "max_mad_size" the device supported.
>
> OPA devices support IB MADs. If the IB Base Version is specified on an
> OPA
> device the IB MAD size is to be used
> I'm concerned about the performance implications of this. The size of
> this patchset already points out just how many places in the code we
> have to check for various aspects of the device transport in order to do
> the right thing. Without going through the entire list to see how many
> are
> On 04/07/2015 11:36 PM, Hefty, Sean wrote:
> >> diff --git a/drivers/infiniband/core/cma.c
> b/drivers/infiniband/core/cma.c
> >> index d8a8ea7..c23f483 100644
> >> --- a/drivers/infiniband/core/cma.c
> >> +++ b/drivers/infiniband/core/c
> In order to manage multiple types, vlans and MACs per GID, we
> need to store them along the GID itself. We store the net device
> as well, as sometimes GIDs should be handled according to the
> net device they came from. Since populating the GID table should
> be identical for every RoCE provide
> diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
> index d8a8ea7..c23f483 100644
> --- a/drivers/infiniband/core/cma.c
> +++ b/drivers/infiniband/core/cma.c
> @@ -435,10 +435,10 @@ static int cma_resolve_ib_dev(struct rdma_id_private
> *id_priv)
> pkey = ntohs(addr
> +static inline int rdma_transport_ib(struct ib_device *device, u8
> port_num)
> +{
> + return device->query_transport(device, port_num)
> + == RDMA_TRANSPORT_IB;
> +}
> +
> +static inline int rdma_transport_iboe(struct ib_device *device, u8
> port_num)
> +{
> + return
> > index f704254..4e61104 100644
> > +++ b/drivers/infiniband/core/sa_query.c
> > @@ -540,7 +540,7 @@ int ib_init_ah_from_path(struct ib_device *device,
> u8 port_num,
> > ah_attr->port_num = port_num;
> > ah_attr->static_rate = rec->rate;
> >
> > - force_grh = rdma_port_get_link_layer(d
> diff --git a/drivers/infiniband/core/sysfs.c
> b/drivers/infiniband/core/sysfs.c
> index cbd0383..aa53e40 100644
> --- a/drivers/infiniband/core/sysfs.c
> +++ b/drivers/infiniband/core/sysfs.c
> @@ -248,14 +248,10 @@ static ssize_t phys_state_show(struct ib_port *p,
> struct port_attribute *unuse
> diff --git a/drivers/infiniband/core/sa_query.c
> b/drivers/infiniband/core/sa_query.c
> index f704254..4e61104 100644
> --- a/drivers/infiniband/core/sa_query.c
> +++ b/drivers/infiniband/core/sa_query.c
> @@ -540,7 +540,7 @@ int ib_init_ah_from_path(struct ib_device *device, u8
> port_num,
>
> > Rather than calling device->process_mad() directly, would it be better
> to call a common function? So we can avoid adding:
> >
> > > + struct ib_mad *in_mad = (struct ib_mad *)in;
> > > + struct ib_mad *out_mad = (struct ib_mad *)out;
> > > +
> > > + if (in_mad_size != sizeof(*in_mad) || *out
> > > The IBA is pretty clear what should happen to process an unsupported
> class
> > > version and and adding OPA shouldn't suddenly make the IB side
> > > non-conformant, however aesthetically unpleasing the code may be.
> >
> > Are there checks to ensure that MADs not supported by RoCE aren't
>
> > The IBA is pretty clear what should happen to process an unsupported
> class
> > version and and adding OPA shouldn't suddenly make the IB side
> > non-conformant, however aesthetically unpleasing the code may be.
>
> Are there checks to ensure that MADs not supported by RoCE aren't
> processe
> Hal asked for this, and I agree. It is just lazy not to check the
> underlying device type for this stuff - they are different number
> spaces, administered by different bodies with no apparent
> coordination.
>
> The IBA is pretty clear what should happen to process an unsupported class
> versi
> I understand your point and I originally called this "attributes" but it
> was
> suggested to call it cached_dev_attrs.
>
> https://www.mail-archive.com/linux-rdma%40vger.kernel.org/msg22486.html
>
> I can change it back if we are all agreed.
I'll disagree with Or on this. Unless some of thes
> diff --git a/drivers/infiniband/core/agent.c
> b/drivers/infiniband/core/agent.c
> index b6bd305..18275a5 100644
> --- a/drivers/infiniband/core/agent.c
> +++ b/drivers/infiniband/core/agent.c
> @@ -80,13 +80,17 @@ ib_get_agent_port(struct ib_device *device, int
> port_num)
>
> void agent_send_
> > diff --git a/include/rdma/ib_mad.h b/include/rdma/ib_mad.h
> > index 00a5e51..80e7cf4 100644
> > --- a/include/rdma/ib_mad.h
> > +++ b/include/rdma/ib_mad.h
> > @@ -136,6 +136,11 @@ enum {
> > IB_MGMT_DEVICE_HDR = 64,
> > IB_MGMT_DEVICE_DATA = 192,
> > IB_MGMT_MAD_SIZE = IB_MGMT_MAD
> @@ -236,6 +252,24 @@ enum smi_action smi_handle_dr_smp_recv(struct ib_smp
> *smp, u8 node_type,
> smp->dr_slid == IB_LID_PERMISSIVE);
> }
>
> +/*
> + * Adjust information for a received SMP
> + * Return 0 if the SMP should be dropped
The function returns a
> @@ -937,20 +937,31 @@ struct ib_mad_send_buf * ib_create_send_mad(struct
> ib_mad_agent *mad_agent,
> struct ib_mad_send_wr_private *mad_send_wr;
> int pad, message_size, ret, size;
> void *buf;
> + size_t mad_size;
> + int opa;
>
> mad_agent_priv = container_of(m
> /* Registration table sizes */
> #define MAX_MGMT_CLASS 80
> -#define MAX_MGMT_VERSION 8
> +#define MAX_MGMT_VERSION 0x83
It's unfortunate that this results in a big jump in used versions. Mad_priv.h
defines this:
struct ib_mad_port_private {
...
struct
> Define jumbo_mad and jumbo_rmpp_mad.
I would just use 'opa_mad' in place of 'jumbo_mad'. Jumbo sounds like a
marketing term or elephant name.
> Jumbo MAD structures are 2K versions of ib_mad and ib_rmpp_mad structures.
> Currently only OPA base version MADs are of this type.
>
> Create an R
> -static struct ib_mad_private *alloc_mad_priv(struct ib_device *dev)
> +static struct ib_mad_private *alloc_mad_priv(struct ib_device *dev,
> + size_t *mad_size)
> {
> + *mad_size = dev->cached_dev_attrs.max_mad_size;
Why does this function return th
Reviewed-by: Sean Hefty
--
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
Reviewed-by: Sean Hefty
--
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
Reviewed-by: Sean Hefty
--
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
> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> index 0d74f1d..0116e4b 100644
> --- a/include/rdma/ib_verbs.h
> +++ b/include/rdma/ib_verbs.h
> @@ -1675,6 +1675,7 @@ struct ib_device {
> u32 local_dma_lkey;
> u8 node_
> I must disagree. You made this claim back when we submitted the IB
> core patch which adds support for signature, protection etc offloads
> (commit 1b01d33560e7 "IB/core: Introduce signature verbs API" and the
> detailed replied you got were explaining that
And I'll continue to make this claim b
> It doesn't take a lot of time to do this work, especially if you use
> the correct tools. I can review and apply 100 patches a day, even
> when I'm on vacation. I'm an extreme example, but what you're doing
> right now Roland is not acceptable and is not in agreement with your
> claims about ho
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
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
> Yes, it's currently copy the logical we are using to branch the
> management, however, if the vendor could provide his own setup code
> here, we don't really need to infer anymore but following the
> indicator from vendor, this 'default' method is for transition.
>
> Sean, could you please give
> > On 02/11/2015 05:06 PM, Shachar Raindel wrote:
> >> RDMA-CM uses IP based addressing and routing to setup RDMA
> >> connections between
> >> hosts. Currently, all of the IP interfaces and addresses used by the
> >> RDMA-CM
> >> must reside in the init_net namespace. This restricts the usage of
> We have plenty of places where we don't care what exactly the
> transport type is, but only care if it's IB type.
>
> This patch introduce rdma_transport_is_ib() as shortcuts to check
> whether an 'ib_device' is infiniband transport type, which help us to
> save some code.
In most of these plac
> But it makes sense to me to use management specific
> fields/attributes/flags for the *management* pieces, rather than using the
> link and/or transport layer protocols as a proxy. Management related code
> should really branch based on that.
As a proposal, we could add a new field to the kerne
> > or management application.
>
> Agreed, but _only_ when talking to the hardware. Other MAD interfaces are
> IB compatible.
Maybe this is what Ira is thinking, and just not explaining very well. But it
makes sense to me to use management specific fields/attributes/flags for the
*management*
> InfiniBandInfiniBand InfiniBand Verbs
> iWARP InfiniBand iWARP Verbs (subset of IBV, with
> specific connection establishment
> requirements that don't exist with IBV)
> RoCE EthernetInfiniBand Verb
> Thanks for the quick response. I've made the suggested changes, but
> I'm afraid I am having the same problems. In fact, I see that a
> previous thread (
> http://www.spinics.net/lists/linux-rdma/msg07573.html ) follows
> another user with the same problem. In fact, I finally found a message
> (f
> I have a fairly complex system that I've built over the last few years
> as part of my PhD that uses reliable connections for message-passing
> and RDMA. After reading a recent paper, I decided to compare the
> performance of message-passing over unreliable connections for the
> sake of completen
> > >>@@ -860,6 +860,12 @@ int ib_modify_qp_is_ok(enum ib_qp_state
> cur_state, enum ib_qp_state next_state,
> > >> if (mask & ~(req_param | opt_param | IB_QP_STATE))
> > >> return 0;
> > >>+ if ((mask & IB_QP_SQ_PSN) && (attr->sq_psn & 0xff00))
> > >>+ return
Thanks - applied
> Does this patch look ok?
It looks okay at a glance. Sorry, I haven't lost this, but just haven't had
time to apply it.
N�r��yb�X��ǧv�^�){.n�+{��ٚ�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
> Currently, these patches are claiming values that are controlled by an
> established standards organization. It is the equivalent of just
> grabbing a currently unused Ethertype value for a new protocol and then
> claiming that whenever the IEEE allocates it for something else you will
> make cha
Thanks - merged
--
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
> So it's possible on server side listen using AF_INET, but client
> rdma_resolve_addr/rdma_resolve_route/rdma_connect with AF_IB?
Yes
101 - 200 of 1448 matches
Mail list logo
