Subject: RE: [Ipoverib] DHCP over InfiniBand

From: "Larsen, Roy K" <[email-masked]>
Date: Wed, 3 Apr 2002 13:17:07 -0800

/rkl
embedded
rkl/

-----Original Message-----
From: Vivek Kashyap [mailto:[email-masked]]
Sent: Wednesday, April 03, 2002 12:27 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Ipoverib] DHCP over InfiniBand

> /rkl
> NO!  Isn't that how we got here?  If DHCP hadn't defined the 'chaddr' as
> fixed length we wouldn't even be having this discussion.  The
> client-identifier is an opaque value so why should the length matter?
> rkl/

        chaddr applies to all hardware types. The value 32 applies to
        InfiniBand. The choice is between listing the hardware address
        or just the GID. I prefer the full hardware address -
        including the QPN. Now, for those that don't have a constant
        QPN and whose uniqueness requirement is served by just the GID
        can set the 4 bytes of QPN/reserved flags to 0.

        The length in the option field therefore automatically becomes
        21 since we need to add the 1 byte of hardware type.
/rkl
Since the QPN is an output parameter of the CREATE QUEUE PAIR verbs
interface, I don't believe anyone should assume an invariant QPN.
Therefore, I would venture to guess that the client-identifier will rarely
reflect the true IPoIB hardware address.  Since it is an opaque value and
there is no requirement that it reflect the IPoIB hardware address, it
doesn't follow that it must be equal in length.  But, given that I can use
type 0 to construct a friendly invariant client-id, there is no reason to
push it any further here.

Thanks for clarifying the type usage in DHCP.
Roy
rkl/

<snip>

Vivek

_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib

---

From: Vivek Kashyap <[email-masked]>
Date: Wed, 3 Apr 2002 16:34:52 -0800 (PST)

> interface, I don't believe anyone should assume an invariant QPN.

        It is not 'assume an invariant QPN' but 'know the invariant
        QPN' i.e. if the implementation ensures invariant QPN it can
        use it. Verbs don't restrict anyone from implementing an
        interface that returns a specific queue pair or any other
        solution that allows for invariant QPs for a particular
        function. This is not the issue though.

        I suppose the length can be a different fixed length - but
        then, as you too seem to agree below, one can just use type 0
        for a non-htype client id.

> push it any further here.

        Agreed. Does this mean you are ok with the description in the
        draft ?

Vivek

-- 
Vivek Kashyap
Linux Technology Center, IBM
[email-masked] 
[email-masked] 
503 578 3422 (o)