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)?
>> >-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
