[libvirt] [PATCH 0/9] Slightly rework our streams

John Ferlan jferlan at redhat.com
Wed Apr 20 14:04:02 UTC 2016



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




More information about the libvir-list mailing list