RE: [dsdp-tcf-dev] Applicability of TCF agent for remote tracing

["Burton, Felix" <Felix.Burton@xxxxxxxxxxxxx>]

Hi Michael,

See comments inline.

> -----Original Message-----
> From: dsdp-tcf-dev-bounces@xxxxxxxxxxx [mailto:dsdp-tcf-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Michael Sills-Lavoie
> Sent: Wednesday, May 27, 2009 12:48 PM
...
> What we are using right now to transfer the tracing data for the
kernel
> memory to a file in our local deamon is the splice system call from
> linux. This way, we can ask the kernel to do the transfer for us so we
> don't get any useless copy. It's what we wanted to use for the network
> transfer too to get the smallest possible overhead. I think this won't
> be easily feasible in tcf because we can't have access directly to the
> file descriptor or the socket, am I wrong? Maybe we could think of
> another way of doing it with mmap and bloc write to get something
> similar, but getting the file descriptor would probably be the most
> efficient way of doing it.

In addition to a block write function we could add a
copy-block-from-file function which under the hood is using splice.  I
have not used splice before, but the documentation states that one side
must be a pipe.  Do you know if a socket considered to be a pipe or a
file from the splice system call point of view?

> For the sending side of the agent, were you thinking of flushing the
> write buffer stream (writing it to the socket) before every blocwrite
> of data and then sending the bloc directly?

Yes, the block write function would write any pending data in the fifo
to the socket, preferable in such a way that it does not cause a package
to be sent to over the network.

> I also have the concern of how we are going to tell that a bloc of
> uncompressed data is in the message. I thought of inserting another
> escape sequence to let the reader know about the data (ESCcode size
> [data]). Because right now, the inputbuf is scanning the data for the
> end of message sequence (ibuf_read_done and ibuf_get_more). It would
> also have to check for the "bloc escape sequence" and skip the binary
> data so there are some other changes that would need to be done there?

Correct, the receiving side would have to check the a block marker and
skip any marker checks in that range.

Thanks,
Felix