On 04/15/2016 09:51 AM, Michal Privoznik wrote:
> This is not the big patch set that enables sparse streams. Not
> just yet. I'm merely sending first few patches that prepare the
> environment for that. These can, however, go in independent of
> sparse streams.
>
> Michal Privoznik (9):
> daemonClientStream: Use unsigned int to store stream @serial
> daemon stream: Prefer bool over unsigned int var:1
> daemon stream: Convert @tx in daemonClientStream to bool
> daemon stream: Remove useless empty lines from header file
> virNetClientCallDispatchStream: Update comment
> daemonStreamHandleRead: Rework to follow our coding pattern
> Revert "rpc: Fix slow volume download (virsh vol-download)"
> virnetclientstream: Process stream messages later
> virStream{Recv,Send}All: Increase client buffer
>
> daemon/stream.c | 116 +++++++++++++++----------------
> daemon/stream.h | 2 -
> src/libvirt-stream.c | 5 +-
> src/rpc/virnetclient.c | 6 +-
> src/rpc/virnetclientstream.c | 158 +++++++++++++++---------------------------
> src/rpc/virnetserverprogram.c | 12 ++--
> src/rpc/virnetserverprogram.h | 4 +-
> 7 files changed, 129 insertions(+), 174 deletions(-)
>
I'm assuming for patch 2-3, the memory for the int -> bool conversions
is all "local" to the client side...
I've made comments on a few patches... I'm not an expert in this space
by any stretch - hopefully Martin can look at patch 8 (and since it goes
w/ 7 - they're a matched set.
ACK for at at least 1-6... I'm OK with 7&8 (although I had a double
check type question in 8 regarding the while loop and usage of 'want' as
a loop control along with the st->rx that could have been Queue'd.
I'm OK with patch 9 as well - I think it's fine - a bit more memory for
a bit less back and forth. Standard tradeoff to me ;-). Perhaps someone
else may have agita over it though, so lets just be sure no one does
before pushing that one.
John
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list