0x54 is just a random opcode.
Remember that ports and buffers are distinct.
In general, there is one or more buffers allocated for each port (input or
output) when the worker is instantiated.
The term "zero copy" actually applies in several places. The RCC worker model
always supplies buffer pointers to the workers, so I/O in and out of all
workers is generally "zero copy" in that no data copying is required between
workers (since the same pointer given to the producing worker is ultimately
given to the consuming worker(s).
Also, a buffer arriving via DMA (from a producer somewhere else) is not copied
when consumed by a worker since the worker is simply given a pointer to it as
it arrives.
One particular case of "send", when the buffer being sent came from an input
port is an "input-to-output zero copy", where the worker is indicating that a
buffer that arrived on an input port should be sent from an output port. The
OpenCPI infrastructure then has the *possibiity* of moving the data without
copies anywhere. Depending on the underlying transport used, this optimization
may or may not happen (e.g. if the input was from PCIe DMA and the output is
OFED RDMA, it won't currently work and a copy will be made). But the general
case is that the input buffer is queued as an output from the output port and
when it is finally sent, it is recycled back to the input port where it started.
Your last question (when does the port know when the processing is done) should
be clear from the documentation (I guess it isn't :).
The worker says it is done with an input buffer in one of several ways:
1. The simplest: just return RCC_ADVANCE. This says that all buffers
available on all ports were processed. Current buffers at input ports can be
released, and current buffers at output ports can be sent.
2. The next most likely: perform c->advance() on the port. This says release
or send the current buffer AND request another buffer be made available. (send
= release + request).
3. release() by itself says: I am done, but don't necessarily get more
buffers right now since I don't really need them.
I think your last scenario is ok, although the release is wrong since "send"
implies release.
The documentation (in the RCC reference) is too fuzzy on the exact
release-vs-advance semantics. Its on our todo list...
Jim
On Feb 23, 2012, at 10:12 PM, Sutton, Joshua (Contractor) wrote:
UNCLASSIFIED
Hi
I've got some questions on the zero copy functionality within rcc workers:
The only example for zero copy workers seems to be in
components/testzc.rcc/zcworkers.c.
In the code fragment below, what's the meaning of the ordinal 0x54?
Is this worker a working example or is there another example of zero copy
within an RCC worker ?
"
runc=1;
switch( runc ) {
// Send input buffer to output port
case 0:
{
this_->container.send( out, &in->current, 0x54, len );
}
break;
....
return RCC_OK
"
Also, when using the zero copy functionality within rcc workers with multiple
input buffers:
A worker has multiple input buffers and a single output buffer. How does the
input port know when the worker has finished processing the input buffer?
(The multiple input buffers is obviously to allow the worker to access multiple
input buffers at a time). I assume the sequence to hold multiple input buffers
and then do a zero copy of one of them to the output port is something like:
container->take(in, NULL, &state->buffers[cur]);
container->send(out, &(state->buffers[prev]), state->buffer_operation[prev],
state->buffer_length[prev]);
cont->release(&state->buffers[prev]);
Is this correct?
Cheers,
Josh
IMPORTANT: This email remains the property of the Department of Defence and is
subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have
received this email in error, you are requested to contact the sender and
delete the email.
_______________________________________________
opencpi_dev mailing list
[email protected]<mailto:[email protected]>
http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org
_______________________________________________
opencpi_dev mailing list
[email protected]
http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org
