Thanks for the feedback Eric! On Wed, Sep 1, 2021 at 5:54 PM Eric Blake <ebl...@redhat.com> wrote: > > On Tue, Aug 31, 2021 at 08:02:37AM -0300, Leonardo Bras wrote: > > 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 for QIOChannelSocket, but can be easily > > extended to any other QIOChannel implementation. > > As a followup to this patch, I wonder if we can also get performance > improvements by implementing MSG_MORE, and using that in preference to > corking/uncorking to better indicate that back-to-back short messages > may behave better when grouped together over the wire. At least the > NBD code could make use of it (going off of my experience with the > libnbd project demonstrating a performance boost when we added > MSG_MORE support there).
That's interesting! We could use this patchset for testing that out, as I believe it's easy to add those flags to the sendmsg() we want to have it enabled. > > > > > Signed-off-by: Leonardo Bras <leob...@redhat.com> > > --- > > chardev/char-io.c | 2 +- > > hw/remote/mpqemu-link.c | 2 +- > > include/io/channel.h | 56 ++++++++++++++++++++--------- > > io/channel-buffer.c | 1 + > > io/channel-command.c | 1 + > > io/channel-file.c | 1 + > > io/channel-socket.c | 4 ++- > > io/channel-tls.c | 1 + > > io/channel-websock.c | 1 + > > io/channel.c | 53 ++++++++++++++------------- > > migration/rdma.c | 1 + > > scsi/pr-manager-helper.c | 2 +- > > tests/unit/test-io-channel-socket.c | 1 + > > 13 files changed, 81 insertions(+), 45 deletions(-) > > > > diff --git a/chardev/char-io.c b/chardev/char-io.c > > index 8ced184160..4ea7b1ee2a 100644 > > --- a/chardev/char-io.c > > +++ b/chardev/char-io.c > > @@ -122,7 +122,7 @@ int io_channel_send_full(QIOChannel *ioc, > > > > ret = qio_channel_writev_full( > > ioc, &iov, 1, > > - fds, nfds, NULL); > > + fds, 0, nfds, NULL); > > 0 before nfds here... Good catch! I will fix that for v2! > > > if (ret == QIO_CHANNEL_ERR_BLOCK) { > > if (offset) { > > return offset; > > diff --git a/hw/remote/mpqemu-link.c b/hw/remote/mpqemu-link.c > > index 7e841820e5..0d13321ef0 100644 > > --- a/hw/remote/mpqemu-link.c > > +++ b/hw/remote/mpqemu-link.c > > @@ -69,7 +69,7 @@ bool mpqemu_msg_send(MPQemuMsg *msg, QIOChannel *ioc, > > Error **errp) > > } > > > > if (!qio_channel_writev_full_all(ioc, send, G_N_ELEMENTS(send), > > - fds, nfds, errp)) { > > + fds, nfds, 0, errp)) { > > Thanks for fixing the broken indentation. I kept questioning myself if I was breaking something here :) > > ...but after nfds here, so one is wrong; up to this point in a linear > review, I can't tell which was intended... > > > +++ b/include/io/channel.h > > @@ -104,6 +104,7 @@ struct QIOChannelClass { > > size_t niov, > > int *fds, > > size_t nfds, > > + int flags, > > Error **errp); > > ...and finally I see that in general, you wanted to add the argument > after. Looks like the change to char-io.c is buggy. Yeap! > > (You can use scripts/git.orderfile as a way to force your patch to > list the .h file first, to make it easier for linear review). Nice tip! just added to my qemu gitconfig :) > > > ssize_t (*io_readv)(QIOChannel *ioc, > > const struct iovec *iov, > > @@ -260,6 +261,7 @@ ssize_t qio_channel_writev_full(QIOChannel *ioc, > > size_t niov, > > int *fds, > > size_t nfds, > > + int flags, > > Error **errp); > > > > /** > > @@ -325,6 +327,7 @@ int qio_channel_readv_all(QIOChannel *ioc, > > * @ioc: the channel object > > * @iov: the array of memory regions to write data from > > * @niov: the length of the @iov array > > + * @flags: optional sending flags > > * @errp: pointer to a NULL-initialized error object > > * > > * Write data to the IO channel, reading it from the > > @@ -339,10 +342,14 @@ int qio_channel_readv_all(QIOChannel *ioc, > > * > > * Returns: 0 if all bytes were written, or -1 on error > > */ > > -int qio_channel_writev_all(QIOChannel *ioc, > > - const struct iovec *iov, > > - size_t niov, > > - Error **erp); > > +int qio_channel_writev_all_flags(QIOChannel *ioc, > > + const struct iovec *iov, > > + size_t niov, > > + int flags, > > + Error **errp); > > You changed the function name here, but not in the comment beforehand. > Will fix this for v2, thanks ! > > + > > +#define qio_channel_writev_all(ioc, iov, niov, errp) \ > > + qio_channel_writev_all_flags(ioc, iov, niov, 0, errp) > > In most cases, you were merely adding a new function to minimize churn > to existing callers while making the old name a macro,... > > > @@ -853,6 +876,7 @@ int qio_channel_writev_full_all(QIOChannel *ioc, > > const struct iovec *iov, > > size_t niov, > > int *fds, size_t nfds, > > + int flags, > > Error **errp); > > ...but this one you changed in-place. Any reason? It might be nice > to mention how you chose which functions to wrap (to minimize churn to > existing clients) vs. modify signatures. It's the first one I did change, TBH. It just had a few uses. mostly in the same file scope, and a single use on mpqemu-link.c, so I thought it would be ok to just change it. But yeah, it makes sense to also add a macro to this one as well, and create another function to keep them all looking the same. > > > > > #endif /* QIO_CHANNEL_H */ > > diff --git a/io/channel-buffer.c b/io/channel-buffer.c > > index baa4e2b089..bf52011be2 100644 > > --- a/io/channel-buffer.c > > +++ b/io/channel-buffer.c > > @@ -81,6 +81,7 @@ static ssize_t qio_channel_buffer_writev(QIOChannel *ioc, > > size_t niov, > > int *fds, > > size_t nfds, > > + int flags, > > Error **errp) > > { > > QIOChannelBuffer *bioc = QIO_CHANNEL_BUFFER(ioc); > > Would it be wise to check that flags only contains values we can honor > in this (and all other) implementations of qio backends? Do we need > some way for a backend to advertise to the core qio code which flags > it is willing to accept? That's a good idea, maybe we can do as you suggest below, choose a set of features we are willing to support and then translate it depending on the implementation. Then this would only be testing for a mask. > > > +++ b/io/channel-socket.c > > @@ -525,6 +525,7 @@ static ssize_t qio_channel_socket_writev(QIOChannel > > *ioc, > > size_t niov, > > int *fds, > > size_t nfds, > > + int flags, > > Error **errp) > > { > > QIOChannelSocket *sioc = QIO_CHANNEL_SOCKET(ioc); > > @@ -558,7 +559,7 @@ static ssize_t qio_channel_socket_writev(QIOChannel > > *ioc, > > } > > > > retry: > > - ret = sendmsg(sioc->fd, &msg, 0); > > + ret = sendmsg(sioc->fd, &msg, flags); > > Because of this line, we are forcing our use of flags to be exactly > the same set of MSG_* flags understood by sendmsg(), which feels a bit > fragile. Wouldn't it be safer to define our own set of QIO_MSG_ > flags, and map those into whatever flag values the underlying backends > can support? After all, one thing I learned on libnbd is that > MSG_MORE is not universally portable, but the goal of qio is to > abstract away things so that the rest of the code doesn't have to do > #ifdef tests everywhere, but instead let the qio code deal with it > (whether to ignore an unsupported flag because it is only an > optimization hint, or to return an error because we depend on the > behavior change the flag would cause if supported, or...). And that > goes back to my question of whether backends should have a way to > inform the qio core which flags they can support. I think you are correct and having our own QIO_MSG_* would make sense here. This could allow us to filter incorrect flags easily, and also have well documented what each implementation supports, by their own masks. Thanks! Leonardo Bras > > -- > Eric Blake, Principal Software Engineer > Red Hat, Inc. +1-919-301-3266 > Virtualization: qemu.org | libvirt.org >