<br><div class="gmail_quote">On Sun, Jan 20, 2013 at 8:16 PM, Bharata B Rao <span dir="ltr"><<a href="mailto:bharata.rao@gmail.com" target="_blank">bharata.rao@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Thu, Jan 10, 2013 at 11:55 AM, Anand Avati <<a href="mailto:aavati@redhat.com">aavati@redhat.com</a>> wrote:<br>
> - On the read side things are a little more complicated. In<br>
> rpc-transport/socket, there is a call to iobuf_get() to create a new iobuf<br>
> for reading in the readv reply data from the server. We will need a<br>
> framework changes where, if the readv request (of the xid for which readv<br>
> reply is being handled) happened to be a "direct" variant (i.e, zero-copy),<br>
> then the "special iobuf around user's memory" gets picked up and read() from<br>
> socket is performed directly into user's memory. Similar, but equivalent,<br>
<br>
</div>AFAICS, the read from the socket is always done to a single buffer and<br>
the actual "scatter input" (reading or copying into multiple user supplied<br>
iovec buffer) is actually done at the end in libgfapi. So as you note, some<br>
framework changes need to be done to enable direct reading of socket data into<br>
multiple user supplied buffers.<br></blockquote><div><br></div><div>Right. Those are all (the kind of) details to be taken care of. </div><div><br></div><div>Avati</div><div><br></div></div>