[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v1 1/3] io: Enable write flags for QIOChannel
From: |
Leonardo Bras Soares Passos |
Subject: |
Re: [PATCH v1 1/3] io: Enable write flags for QIOChannel |
Date: |
Thu, 2 Sep 2021 05:26:04 -0300 |
Thanks for the feedback Eric!
On Wed, Sep 1, 2021 at 5:54 PM Eric Blake <eblake@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 <leobras@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
>