Subject: RE: [rddp] RDDP header format

From: "Culley, Paul" <[email-masked]>
Date: Mon, 11 Nov 2002 12:35:14 -0600

I think the reason for including the RDMA layer stuff in the DDP layer, is that this avoids defining a general purpose method of making space after the DDP header for an RDMA header, but before the DDP data to be placed.  Since we could only see a need for the 1 bytes for Tagged, and 5 bytes for Untagged (in worst case) of RDMA "header data", we only allowed these two cases.

In retrospect, we could possibly have reduced the QN field to a couple of bits in the DDP header (using some of the remaining 4 bits), but, due to the historical development, we did not.  Others may also have concerns with using our reserved bits that much, or plans for the larger QN field...

Paul Culley
HP Sr. Fellow
281-514-5543

-----Original Message-----
From: Williams, Jim [mailto:[email-masked]]
Sent: Monday, November 11, 2002 11:27 AM
To: [email-masked]
Subject: RE: [rddp] RDDP header format

> -----Original Message-----
> From: Michael Krause [mailto:[email-masked]]
>
> >For untagged buffers, the header defines a 32 bit field
> >called "RsvdULP[8:39]".  The RDMA layer uses this
> >for STag invalidate.  Just curious why this field
> >should be in the DDP header rather than the RDMA
> >header.
> 
> Standard field location for multiple ULP to use without 
> having to re-invent the wheel.

I don't understand.  Why is putting ULP header information
in the DDP header rather the the ULP header a good thing?
And how does that avoid re-inventing the wheel?  Perhaps
I'm missing something here.

> >Also, in the untagged buffer DDP header is a 32 bit
> >field defining the queue number.  Why does this
> >require 32 bits?  It looks like RDMA uses only
> >three queues numbered 0, 1, and 2.  If the number
> >of queues expected to be used is small, one
> >could potentially eliminate this field and use
> >two or three reserved bits to indicate the
> >queue number.
> 
> Pre-enablement for new services where a large QN space might be 
> desirable.  [...]  In general, defining a larger 
> space allows for future flexibility.

That is clear.  64 bits would give even more
flexability.  I was really trying to get at what
new services are forseen with sufficient probability
to justify this size QN space.  I am sure some
thought was give to that.  Perhaps it should be 
shared.
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 14 Nov 2002 14:50:42 -0600

On 11/11/02, Culley, Paul wrote:

>I think the reason for including the RDMA layer stuff in
>the DDP layer, is that this avoids defining a general
>purpose method of making space after the DDP header for an
>RDMA header, but before the DDP data to be placed.  Since
>we could only see a need for the 1 bytes for Tagged, and 5
>bytes for Untagged (in worst case) of RDMA "header data",
>we only allowed these two cases.
>
>In retrospect, we could possibly have reduced the QN field
>to a couple of bits in the DDP header (using some of the
>remaining 4 bits), but, due to the historical development,
>we did not.  Others may also have concerns with using our
>reserved bits that much, or plans for the larger QN
>field...
>

In "retrospect" could a chunk of the high order bits simply
be redefined as "reserved"? Nobody is using high queue
numbers yet, are they?

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp