On Apr 22, 2013, at 4:00 PM, Doug Ledford wrote:
>> 2. Change all instances of ib_mtu/ibv_mtu to an int. Code such as
>> "switch(mtu) case IBV_MTU_1024: ..." will need to be updated to
>> "switch(mtu) case 1024: ...".
>
> I was actually thinking that an ibverbs API version 2.0 might be an
> i
On 04/22/2013 02:00 PM, Jeff Squyres (jsquyres) wrote:
> 2. Change all instances of ib_mtu/ibv_mtu to an int. Code such as
> "switch(mtu) case IBV_MTU_1024: ..." will need to be updated to
> "switch(mtu) case 1024: ...".
>
> PRO: solves the problem for all MTU values
> PRO: eliminates the num-
On Apr 22, 2013, at 1:30 PM, Doug Ledford wrote:
> However, for some reason I had it
> in my mind when I was reading the patch that it was against libibverbs.
> That's what I get for staying up late and reviewing when I'm tired :-/
There were other patches against libibverbs that were submitted
On 04/20/2013 07:29 PM, Hefty, Sean wrote:
>> This seems reasonable, but still concerns me a bit. The original
>> version was flat out wrong because you can't re-arrange any exposed
>> enum like this without requiring that all user space apps be
>> recompiled. This is especially true because ibv_
> This seems reasonable, but still concerns me a bit. The original
> version was flat out wrong because you can't re-arrange any exposed enum
> like this without requiring that all user space apps be recompiled.
> This is especially true because ibv_mtu_enum_to_int is an inline
ib_mtu_enum_to_int
On 04/19/2013 11:24 AM, Jeff Squyres (jsquyres) wrote:
> On Apr 12, 2013, at 11:40 AM, Jeff Squyres (jsquyres)
> wrote:
>
>>> As an aside I like the use of RDMA_MTU_* for these values. Again to
>>> distinguish them from the IBTA values. But I know that is poor form.
>>
>> So what's the right
On Apr 12, 2013, at 11:40 AM, Jeff Squyres (jsquyres)
wrote:
>> As an aside I like the use of RDMA_MTU_* for these values. Again to
>> distinguish them from the IBTA values. But I know that is poor form.
>
> So what's the right way to move forward on this? Is it this:
>
> enum ib_mtu {
>
On Apr 9, 2013, at 10:44 PM, "Weiny, Ira" wrote:
> As an aside I like the use of RDMA_MTU_* for these values. Again to
> distinguish them from the IBTA values. But I know that is poor form.
So what's the right way to move forward on this? Is it this:
enum ib_mtu {
IB_MTU_256 = 1,
> -Original Message-
> From: Hefty, Sean
> Sent: Tuesday, April 09, 2013 6:30 PM
> To: Weiny, Ira; Jeff Squyres (jsquyres)
> Cc: Hal Rosenstock; Roland Dreier; linux-rdma@vger.kernel.org; Upinder
> Malhi (umalhi)
> Subject: RE: [PATCH 2/2] Ad IB_MTU_1500|9000 enums.
&g
> If the IBTA were to release new MTU enumerations which values would you
> recommend then?
I don't think there's a great solution here. We're mixing IBTA encoded values
with non-IBTA values. We could reserve the 6-bit encoded values for IB, and
use direct values for others (or at least jump b
> -Original Message-
> From: Jeff Squyres (jsquyres) [mailto:jsquy...@cisco.com]
> Subject: Re: [PATCH 2/2] Ad IB_MTU_1500|9000 enums.
>
> On Apr 8, 2013, at 6:16 PM, "Hefty, Sean" wrote:
>
> > Why can't IB_MTU_1500 = 1500?
>
Sean,
If the
On Apr 9, 2013, at 4:10 PM, "Weiny, Ira" wrote:
>> Just to re-state: our issue is that there does not seem to be any other way
>> to
>> get the max UD message size without knowing the actual MTU (are we
>> incorrect about that?). Hence, using the IB-defined values is not really
>> sufficient.
>
On Apr 8, 2013, at 6:16 PM, "Hefty, Sean" wrote:
> Why can't IB_MTU_1500 = 1500?
It certainly could. Additionally, since Roland was a little concerned about
the "IB" prefix (since 1500 and 9000 are not IBTA-sanctioned MTUs), they could
have a different prefix -- perhaps RDMA_MTU_1500.
Alt
> -Original Message-
> From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
> Subject: Re: [PATCH 2/2] Ad IB_MTU_1500|9000 enums.
>
> On Apr 4, 2013, at 1:57 PM, "Weiny, Ira" wrote:
>
> >> In hindsight, the user space API never should
> Agreed, but changing to an int would seem to have some fairly serious
> backwards
> compatibility issues.
Why can't IB_MTU_1500 = 1500?
--
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://
On Apr 4, 2013, at 1:57 PM, "Weiny, Ira" wrote:
>> In hindsight, the user space API never should have exposed the mtu as an
>> enum...
>>
>> Since an enum is an int, and we're never going to have anything with an mtu
>> <= 5 bytes, couldn't we just store all new mtu values directly as their byte
> -Original Message-
> From: Hefty, Sean
>
> > Even with a map I think having IB_MTU_1500 will cause some confusion
> > as this is not an "IB" MTU. It seems an alternate enum name like
> RDMA_MTU_1500 is better.
>
> Couldn't these be usable MTU's for RoCE?
I guess so, I don't have much
> Even with a map I think having IB_MTU_1500 will cause some confusion as this
> is
> not an "IB" MTU. It seems an alternate enum name like RDMA_MTU_1500 is
> better.
Couldn't these be usable MTU's for RoCE?
In hindsight, the user space API never should have exposed the mtu as an enum...
Sinc
> -Original Message-
> From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
>
> > What happens if in the future the IBTA adds new MTUs and allocates
> > those currently reserved MTU values ? Wouldn't those values need to be
> > standardized at the IBTA so that conflict won't occur ?
> What happens if in the future the IBTA adds new MTUs and allocates those
> currently reserved MTU values ? Wouldn't those values need to be
> standardized at the IBTA so that conflict won't occur ?
The IBTA needs to standardize the values as they appear in MADs. The software
values can differ.
On 4/4/2013 8:22 AM, Jeff Squyres (jsquyres) wrote:
> On Apr 3, 2013, at 12:52 PM, Roland Dreier wrote:
>
>> I don't think we can blithely do this... I think the IB enum values
>> are defined to match the values used in the IB spec (PathRecord etc).
>
> Gotcha. I inserted the enums in their pro
On Apr 3, 2013, at 12:52 PM, Roland Dreier wrote:
> I don't think we can blithely do this... I think the IB enum values
> are defined to match the values used in the IB spec (PathRecord etc).
Gotcha. I inserted the enums in their proper numerical order to make the range
comparisons simpler in
On 4/3/2013 11:52 AM, Roland Dreier wrote:
On Wed, Apr 3, 2013 at 6:13 AM, Jeff Squyres wrote:
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 8a66758..4670f6f 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -174,8 +174,10 @@ enum ib_mtu {
IB_
On Wed, Apr 3, 2013 at 6:13 AM, Jeff Squyres wrote:
> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> index 8a66758..4670f6f 100644
> --- a/include/rdma/ib_verbs.h
> +++ b/include/rdma/ib_verbs.h
> @@ -174,8 +174,10 @@ enum ib_mtu {
> IB_MTU_256 = 1,
> IB_MTU_512
Allow specification of common Ethernet MTUs.
---
include/rdma/ib_addr.h | 6 +-
include/rdma/ib_verbs.h | 8 ++--
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/include/rdma/ib_addr.h b/include/rdma/ib_addr.h
index 9996539..1f6fbbc 100644
--- a/include/rdma/ib_addr.h
+++
25 matches
Mail list logo
