Re: [PATCH v1 0/3] QIOChannel flags + multifd zerocopy

On Tue, Aug 31, 2021 at 08:02:36AM -0300, Leonardo Bras wrote: > Results: > So far, the resource usage of __sys_sendmsg() reduced 15 times, and the > overall migration took 13-18% less time, based in synthetic workload. Leo, Could you share some of the details of your tests? E.g., what's the

Re: [PATCH v1 3/3] migration: multifd: Enable zerocopy

On Tue, Aug 31, 2021 at 02:16:42PM +0100, Daniel P. Berrangé wrote: > On Tue, Aug 31, 2021 at 08:02:39AM -0300, Leonardo Bras wrote: > > Call qio_channel_set_zerocopy(true) in the start of every multifd thread. > > > > Change the send_write() interface of multifd, allowing it to pass down > >

Re: [PATCH v1 2/3] io: Add zerocopy and errqueue

On Tue, Aug 31, 2021 at 01:57:33PM +0100, Daniel P. Berrangé wrote: > On Tue, Aug 31, 2021 at 08:02:38AM -0300, Leonardo Bras wrote: > > MSG_ZEROCOPY is a feature that enables copy avoidance in TCP/UDP socket > > send calls. It does so by avoiding copying user data into kernel buffers. > > > > To

Re: [PATCH] block/vvfat: Fix ro shared folder

Hi Guillaume, On 8/31/21 4:17 PM, Guillaume Roche wrote: > QEMU exits in error when passing a vfat shared folder in read-only mode. > > To fix this issue, this patch removes any potential write permission > from cumulative_perms, when a read-only block device is in use. > > Buglink:

[PATCH] block/vvfat: Fix ro shared folder

QEMU exits in error when passing a vfat shared folder in read-only mode. To fix this issue, this patch removes any potential write permission from cumulative_perms, when a read-only block device is in use. Buglink: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918950 Signed-off-by:

[PATCH v1 1/3] io: Enable write flags for QIOChannel

Some syscalls used for writting, such as sendmsg(), accept flags that can modify their behavior, even allowing the usage of features such as MSG_ZEROCOPY. Change qio_channel_write*() interface to allow passing down flags, allowing a more flexible use of IOChannel. At first, it's use is enabled

[PATCH v1 3/3] migration: multifd: Enable zerocopy

Call qio_channel_set_zerocopy(true) in the start of every multifd thread. Change the send_write() interface of multifd, allowing it to pass down flags for qio_channel_write*(). Pass down MSG_ZEROCOPY flag for sending memory pages, while keeping the other data being sent at the default copying

[PATCH v1 2/3] io: Add zerocopy and errqueue

MSG_ZEROCOPY is a feature that enables copy avoidance in TCP/UDP socket send calls. It does so by avoiding copying user data into kernel buffers. To make it work, three steps are needed: 1 - A setsockopt() system call, enabling SO_ZEROCOPY 2 - Passing down the MSG_ZEROCOPY flag for each send*()

[PATCH v1 0/3] QIOChannel flags + multifd zerocopy

This patch series intends to enable MSG_ZEROCOPY in QIOChannel, and make use of it for multifd migration performance improvement. Patch #1 enables the use of flags on qio_channel_write*(), allowing more flexibility in using the channel. It was designed for MSG_ZEROCOPY usage, in which it's a

Re: Virtual FAT disk images

up :-) nobody uses this feature of qemu? Le ven. 27 août 2021 à 11:11, Pascal a écrit : > hello everybody, > > virtual FAT disk image - *which is a convenient way to transfer files to > the guest without having to activate its network* - seems to work very > poorly with Windows : do you have

Re: [PATCH v1 3/3] migration: multifd: Enable zerocopy

On Tue, Aug 31, 2021 at 08:02:39AM -0300, Leonardo Bras wrote: > Call qio_channel_set_zerocopy(true) in the start of every multifd thread. > > Change the send_write() interface of multifd, allowing it to pass down > flags for qio_channel_write*(). > > Pass down MSG_ZEROCOPY flag for sending

Re: [PATCH v1 2/3] io: Add zerocopy and errqueue

On Tue, Aug 31, 2021 at 08:02:38AM -0300, Leonardo Bras wrote: > MSG_ZEROCOPY is a feature that enables copy avoidance in TCP/UDP socket > send calls. It does so by avoiding copying user data into kernel buffers. > > To make it work, three steps are needed: > 1 - A setsockopt() system call,

Re: block/curl: should we be checking curl_easy_setopt() for errors?

On Tue, 31 Aug 2021 at 09:44, Daniel P. Berrangé wrote: > > On Mon, Aug 30, 2021 at 04:34:56PM +0100, Peter Maydell wrote: > > Coverity complains (CID 1460331, 1459482, 1459336, 1458895) > > that we call curl_easy_setopt(), which can return an error value, > > but we never check the return value.

Re: block/curl: should we be checking curl_easy_setopt() for errors?

On Mon, Aug 30, 2021 at 04:34:56PM +0100, Peter Maydell wrote: > Coverity complains (CID 1460331, 1459482, 1459336, 1458895) > that we call curl_easy_setopt(), which can return an error value, > but we never check the return value. > > Is it correct? Looking at the libcurl documentation, the