On Mon, 2008-05-19 at 14:34 -0400, Talpey, Thomas wrote:
> At 02:32 PM 5/19/2008, Tom Tucker wrote:
> >> Well, technically the iWARP connection manager *currently* does not
> >> exchange these values. I think the comment would be more accurate
> >> if it said "in the absence of"...
> >
> >I'm not sure it really has anything to do with where it is implemented.
>
> That wasn't my point - I meant, in the absence of information what the
> peer's maximum might be, the server has to make something up. But, future
> iwarp cm's could pass it.
>
> What value bubbles up in this field from current iWARP connections? Is
> it total garbage, or at least, recognizably useless (-1)?
For iWARP it is currently the local device's max. When iWARP (hopefully)
gets a standard for this -- it will be the remote peer's IRD. This code
won't need to change.
>
> >> >-static void handle_connect_req(struct rdma_cm_id *new_cma_id)
> >> >+static void handle_connect_req(struct rdma_cm_id *new_cma_id, u8
> >client_ird)
> >>
> >> While "u8" might be the limit of the implementations today, wouldn't "int" be
> >> easier to understand, and more portable?
> >>
> >
> >I think that 'int' might provoke the "wrath of Chuck". Unsigned
> >something else --
>
> Okay, well if not "int", then at least some type which is not a specific
> storage size. u{8,16,32} etc should be reserved for describing hardware
> and on-wire stuff, and handled as native when used locally.
>
> Tom.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
