On 6/17/08 3:35 PM, "Leonardo Fialho" <lfia...@aomail.uab.es> wrote:
> Hi Ralph,
>
> 1) Yes, I'm using ORTE_RML_TAG_DAEMON with a new "command" that I
> defined in "odls_types.h".
> 2) I'm packing and unpacking variables like OPAL_INT, OPAL_SIZE, ...
> 3) I'm not blocking the "process_commands" function with long code.
> 4) To know the daemon's vpid and jobid I used the same jobid from the
> app (in this solution, I can be changed) and the vpid is ordered
> sequentially (0 for mpirun and 1 to N for the orted's).
The jobid of the daemons is different from the jobid of the apps. So at the
moment, you are actually sending the message to another app!
You can find the jobid of the daemons by extracting it as
ORTE_PROC_MY_DAEMON->jobid. Please note, though, that the app has no
knowledge of the contact info for that daemon, so this message will have to
route through the local daemon. Happens transparently, but just wanted to be
clear as to how this is working.
>
> The problems is: I need to send a buffered data, and I don't know the
> type of this data. I'm trying to use OPAL_NULL and OPAL_DATA_VALUE to
> send it but I got no success.... :(
If I recall correctly, you were trying to archive messages that flowed
through the PML - correct? I would suggest just treating them as bytes and
packing them as an opal_byte_object_t, something like this:
opal_byte_object_t bo;
bo.size = sizeof(my-data);
bo.data = *my_data;
opal_dss.pack(*buffer, &bo, 1, OPAL_BYTE_OBJECT);
Then on the other end:
opal_byte_object_t *bo;
int32_t n;
opal_dss.unpack(*buffer, &bo, &n, OPAL_BYTE_OBJECT);
You can then transfer the data into whatever storage you like. All this does
is pass the #bytes and the bytes as a collected unit - you could, of course,
simply pass the #bytes and bytes with independent packs if you wanted:
int32_t num_bytes;
uint8_t *my_data;
opal_dss.pack(*buffer, &num_bytes, 1, OPAL_INT32);
opal_dss.pack(*buffer, my-data, num_bytes, OPAL_BYTE);
...
opal_dss.unpack(*buffer, &num_bytes, &n, OPAL_INT32);
my_data = (uint8_t*)malloc(num_bytes);
opal_dss.unpack(*buffer, &my_data, &num_bytes, OPAL_BYTE);
Up to you.
Hope that helps
Ralph
>
> Thanks in advance,
> Leonardo Fialho
>
>
> Ralph H Castain escribió:
>> I'm not sure exactly how you are trying to do this, but the usual procedure
>> would be:
>>
>> 1. call opal_dss.pack(*buffer, *data, #data, data_type) for each thing you
>> want to put in the buffer. So you might call this to pack a string:
>>
>> opal_dss.pack(*buffer, &string, 1, OPAL_STRING);
>>
>> 2. once you have everything packed into the buffer, you send the buffer with
>>
>> orte_rml.send_buffer(*dest, *buffer, dest_tag, 0);
>>
>> What you will need is a tag that the daemon is listening on that won't
>> interfere with its normal operations - i.e., what you send won't get held
>> forever waiting to get serviced, and your servicing won't block us from
>> responding to a ctrl-c. You can probably use ORTE_RML_TAG_DAEMON, but you
>> need to ensure you don't block anything.
>>
>> BTW: how is the app figuring out the name of the remote daemon? The proc
>> will have access to the daemon's vpid (assuming it knows the nodename where
>> the daemon is running) in the ESS, but not the jobid - I assume you are
>> using some method to compute the daemon jobid from the apps?
>>
>>
>> On 6/17/08 12:08 PM, "Leonardo Fialho" <lfia...@aomail.uab.es> wrote:
>>
>>
>>> Hi All,
>>>
>>> I´m using RML to send log messages from a PML to a ORTE daemon (located
>>> in another node). I got success sending the message header, but now I
>>> need to send the message data (buffer). How can I do it? The problem is
>>> what data type I need to use for packing/unpacking? I tried
>>> OPAL_DATA_VALUE but don´t get success...
>>>
>>> Thanks,
>>>
>>
>>
>>
>> _______________________________________________
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>
