[Pvfs2-developers] Hint patch

[Sam Lang]

On Sep 15, 2007, at 9:56 AM, Julian Martin Kunkel wrote:

> Hi Sam,
> cool that you made the modifications ;-)
>
> I think the overall changes look good. There are only a few (minor)  
> comments
> you might consider if you like..
> I would rather avoid to store the encode & decode functions  
> explicitly in the
> PVFS_hint_s struct, because it is contained in the PINT_hint_info  
> struct as
> well. I add some comments and modifications directly to the structure:
>
Agreed.  I'll make that change.

> typedef struct PVFS_hint_s
> {
>     struct PINT_hint_info * type; /* link with the specific type */
>     char* unknown_type_name; /* used only if the type is unknown  
> otherwise the
>                                       * name is available in the  
> type array*/
>     char* value;
>     int32_t length;
>
>     int flags;
>     struct PVFS_hint_s *next;
>     /* int count; where and how do you use this value ? */

Its probably just left-over from wanting to keep track of  
transferrable hints instead of having to compute the number at encode  
time.  I can remove it.

>
> } PINT_hint;
>
> Therefore just add a dummy type for unknown hints in the  
> PINT_hint_info struct
> to cover for the encode functions:
> static const struct PINT_hint_info hint_types[] = {
>
>     {PINT_HINT_UNKNOWN
>      PINT_HINT_TRANSFER,
>      PVFS_HINT_UNKNOWN,
>      encode_func_string,
>      decode_func_string,
>      0, /* value gets automatically filled depending on the length  
> of the hint
> */
> ...
> }
>
> Maybe it would be neat to have another function:
> int PVFS_hint_add_internal(
>     PVFS_hint *hint,
>     int type, /*instead of string */
>     int length,
>     void *value)
> That one could be used internally for instance as follows:
> In the function decode_PINT_hint the function PVFS_hint_add is  
> used. I like
> this idea to support unknown hints (from the clients view) to work  
> on servers
> understanding the hint. However, for known hints this extra  
> computation could
> be avoided by using the available hint type directly. This would  
> avoid to
> look up the hint's type by the server again.
Yep, that's fine.  I'll add that.
-sam

> Also if the server might want to add a hint directly (for further  
> inter server
> communication) it could do so by using the PVFS_hint_add_internal  
> function
> itself. (I used something like this to tag special migration I/O's  
> between
> the servers)...
>
> With your scheme (with or without the modifications I propose)  
> adding new
> hints seems unproblematic. If the server does not understand the  
> hint it is
> ignored, the client encodes it as a string. A problem is only if  
> the client
> has a different order of the hints as the server.
> That is fine with me ;-)
>
> Best regards,
> Julian
>