Hi Julian,
First off, I'm sorry for not responding to this sooner. I know you
guys want to use the request id and other hints in your work, and
having to deal with a separate branch all the time can be a pain.
That being said, we would like to merge in this code to the trunk,
and hope to do that soon. I still want to iterate on a few things
though:
* After some discussion with RobR, I think we'd prefer a little
different hint structure:
typedef struct
{
char * type; /* null terminated */
char * hint;
int length;
} PVFS_hint;
This essentially replaces the type with a string, allowing us to keep
the external interfaces (and types) relatively simple and static (not
changing). With an enum for the types, the external interfaces
(namely the enum) changes everytime someone adds a new hint.
Internally, having the enum of hints is fine, and converting to that
format seems appropriate for sending the hints over the wire.
Also, I would prefer to see each of the system interfaces take an
array of hints (pointer to PVFS_hint and length) instead of the
linked list structure it is now. That would mean that the caller has
to allocate the array himself instead of calling _add_hint, but I'm
ok with that, esp. since for just one hint (most likely case) we can
keep it on the stack instead of the heap.
* All the PINT_* functions should be moved to internal headers or
remove altogether. In fact, with just the type definition in the
hints header, it probably makes sense to move that to pvfs2-types.h.
* I don't like the PINT_hint_add_environment_hints function. I can't
think of any reasonable use cases where someone would want to set
hints with environment variables, and it seems like adding it as a
feature will allow users to shoot themselves in the foot.
In order to limit the length of the hints in the server request, can
we only add the "well known" hints to the request? Well known hints
would be the ones defined in the internal enum.
* The request id format you're using seems rather inefficient. I'd
prefer to see it be a 64 or 128 bit value, and have client-core just
generate something like a uuid. It might be nice to have a util
function that would generate the id that could be passed to the
different system interfaces:
PVFS_hint_generate(const char * type, PVFS_hint * hint);
It seems like the server should be able to treat the request id as
completely opaque, allowing us to change it later if necessary. Are
you adding the hostname and pid to the event logs? Would it be
possible/difficult to extract that info from the id in the logfile at
display time? I'm on the fence on this though...maybe we should pick
a format and stick with it?
* The code in your branch adds hint parameters to all the job, trove,
bmi and flow calls. I'm still in favor of associating the hint with
the job/trove/bmi ids in separate event calls. Actually it looks
like none of the bmi stuff uses the hints at all (only trove and flow)?
-sam
On Sep 7, 2006, at 2:06 PM, Julian Martin Kunkel wrote:
Hi guys,
I want to bother you again with the hint stuff ;-)
As I regard only Pete said something to the hints so far. So I have
no idea if
you like it or not. Propably you want (me) to modify it...
Pete mentioned that it is not good to add the hints to all
operations, e.g.
the pvfs2 nope operation. I think it is good to have a hint for all
operations to provide the same mechanism to all ops, because we do
not know
what researchers intend to do with it.
With the request ID I think I proved that such a mechanism could be
used to
provide a new optional functionality.
Summary of the outstanding questions:
-Should all operations provide a hint ? If no, which should provide
it ?
-Should the hint be given to the job / flow / trove layer. As a
general
mechanism, which most people wanted to have, I think yes.
It might not be so interesting for BMI, also there are multiple
implementations already available.
-Is the hint mechanism provided ok ?
Have a nice day,
julian
---
Darth Vader:
The force is with you young Skywalker, but you are
not a Jedi yet.
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
