[RFC] naming for new QP types

[RFC] naming for new QP types

[Moni Shoua]

Hi,
This message follows a discussion about names for a new QP type (see http://www.mail-archive.com/linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg04512.html) and precedes a patch set for RAW QP that we intend to send.

The patch requires changes in enum ib_qp_type
1. Rename IB_QPT_RAW_ETY to IB_QPT_RAW_ETHERTYPE - this is not really a requirement but an opportunity to improve an existing name.
2. Add new QP type - IBV_QPT_RAW_PACKET. I'll delay the comments for the new name to later, when the patches are submitted, but ask another question instead.

The xrc branch also includes modifications to the same structure and it adds a new type IBV_QPT_XRC before the end.

In general, will it be acceptable if we submit the patches so that after they are applied the structure will look like this

enum ib_qp_type {
        /*
         * IB_QPT_SMI and IB_QPT_GSI have to be the first two entries
         * here (and in that order) since the MAD layer uses them as
         * indices into a 2-entry table.
         */
        IB_QPT_SMI,
        IB_QPT_GSI,

        IB_QPT_RC,
        IB_QPT_UC,
        IB_QPT_UD,
        IB_QPT_RAW_IPV6,
        IB_QPT_RAW_ETHERTYPE = 7,
        IB_QPT_RAW_PACKET = 8
};

So when XRC is accepted we still keep the same values for the last 2?

thanks

MoniS
--
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

RE: [RFC] naming for new QP types

[Hefty, Sean]

> In general, will it be acceptable if we submit the patches so that after
> they are applied the structure will look like this
> 
> enum ib_qp_type {
>         /*
>          * IB_QPT_SMI and IB_QPT_GSI have to be the first two entries
>          * here (and in that order) since the MAD layer uses them as
>          * indices into a 2-entry table.
>          */
>         IB_QPT_SMI,
>         IB_QPT_GSI,
> 
>         IB_QPT_RC,
>         IB_QPT_UC,
>         IB_QPT_UD,
>         IB_QPT_RAW_IPV6,
>         IB_QPT_RAW_ETHERTYPE = 7,
>         IB_QPT_RAW_PACKET = 8
> };
> 
> So when XRC is accepted we still keep the same values for the last 2?

Have the existing values been exposed to user space in any way, even if not defined by libibverbs?

- 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

RE: [RFC] naming for new QP types

[Moni Shoua]

Along with the patches to the kernel we will send a patch to libibverbs
to expose the new values

---------------------------------------
  Moni Shoua|  +972-54-5567934  


-----Original Message-----
From: Hefty, Sean [mailto:sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org] 
Sent: Friday, July 02, 2010 3:34 AM
To: Moni Shoua; Roland Dreier
Cc: linux-rdma; Or Gerlitz; Walukiewicz, Miroslaw; Aleksey Senin
Subject: RE: [RFC] naming for new QP types

> In general, will it be acceptable if we submit the patches so that 
> after they are applied the structure will look like this
> 
> enum ib_qp_type {
>         /*
>          * IB_QPT_SMI and IB_QPT_GSI have to be the first two entries
>          * here (and in that order) since the MAD layer uses them as
>          * indices into a 2-entry table.
>          */
>         IB_QPT_SMI,
>         IB_QPT_GSI,
> 
>         IB_QPT_RC,
>         IB_QPT_UC,
>         IB_QPT_UD,
>         IB_QPT_RAW_IPV6,
>         IB_QPT_RAW_ETHERTYPE = 7,
>         IB_QPT_RAW_PACKET = 8
> };
> 
> So when XRC is accepted we still keep the same values for the last 2?

Have the existing values been exposed to user space in any way, even if
not defined by libibverbs?

- 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

RE: [RFC] naming for new QP types

[Hefty, Sean]

> Along with the patches to the kernel we will send a patch to libibverbs
> to expose the new values

I was actually asking if a user space app could access the existing definitions/values in any way.  For example, if a user space app called create qp with a hard-coded value of 6, what would happen?

- 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

RE: [RFC] naming for new QP types

[Moni Shoua]

If I understand you right this time then you ask what about will happen
if user calls create_qp() from user space with qp_type=6. Right?

I guess that this should be handled in code like with any other illegal
value.

---------------------------------------
  Moni Shoua|  +972-54-5567934  


-----Original Message-----
From: Hefty, Sean [mailto:sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org] 
Sent: Friday, July 02, 2010 6:37 PM
To: Moni Shoua; Roland Dreier
Cc: linux-rdma; Or Gerlitz; Walukiewicz, Miroslaw; Aleksey Senin
Subject: RE: [RFC] naming for new QP types

> Along with the patches to the kernel we will send a patch to 
> libibverbs to expose the new values

I was actually asking if a user space app could access the existing
definitions/values in any way.  For example, if a user space app called
create qp with a hard-coded value of 6, what would happen?

- 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