Skip to content
Snippets Groups Projects
  • Leonardo Bras's avatar
    2bc58ffc
    QIOChannelSocket: Implement io_writev zero copy flag & io_flush for CONFIG_LINUX · 2bc58ffc
    Leonardo Bras authored
    
    For CONFIG_LINUX, implement the new zero copy flag and the optional callback
    io_flush on QIOChannelSocket, but enables it only when MSG_ZEROCOPY
    feature is available in the host kernel, which is checked on
    qio_channel_socket_connect_sync()
    
    qio_channel_socket_flush() was implemented by counting how many times
    sendmsg(...,MSG_ZEROCOPY) was successfully called, and then reading the
    socket's error queue, in order to find how many of them finished sending.
    Flush will loop until those counters are the same, or until some error occurs.
    
    Notes on using writev() with QIO_CHANNEL_WRITE_FLAG_ZERO_COPY:
    1: Buffer
    - As MSG_ZEROCOPY tells the kernel to use the same user buffer to avoid copying,
    some caution is necessary to avoid overwriting any buffer before it's sent.
    If something like this happen, a newer version of the buffer may be sent instead.
    - If this is a problem, it's recommended to call qio_channel_flush() before freeing
    or re-using the buffer.
    
    2: Locked memory
    - When using MSG_ZERCOCOPY, the buffer memory will be locked after queued, and
    unlocked after it's sent.
    - Depending on the size of each buffer, and how often it's sent, it may require
    a larger amount of locked memory than usually available to non-root user.
    - If the required amount of locked memory is not available, writev_zero_copy
    will return an error, which can abort an operation like migration,
    - Because of this, when an user code wants to add zero copy as a feature, it
    requires a mechanism to disable it, so it can still be accessible to less
    privileged users.
    
    Signed-off-by: default avatarLeonardo Bras <leobras@redhat.com>
    Reviewed-by: default avatarPeter Xu <peterx@redhat.com>
    Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
    Reviewed-by: default avatarJuan Quintela <quintela@redhat.com>
    Message-Id: <20220513062836.965425-4-leobras@redhat.com>
    Signed-off-by: default avatarDr. David Alan Gilbert <dgilbert@redhat.com>
    2bc58ffc
    History
    QIOChannelSocket: Implement io_writev zero copy flag & io_flush for CONFIG_LINUX
    Leonardo Bras authored
    
    For CONFIG_LINUX, implement the new zero copy flag and the optional callback
    io_flush on QIOChannelSocket, but enables it only when MSG_ZEROCOPY
    feature is available in the host kernel, which is checked on
    qio_channel_socket_connect_sync()
    
    qio_channel_socket_flush() was implemented by counting how many times
    sendmsg(...,MSG_ZEROCOPY) was successfully called, and then reading the
    socket's error queue, in order to find how many of them finished sending.
    Flush will loop until those counters are the same, or until some error occurs.
    
    Notes on using writev() with QIO_CHANNEL_WRITE_FLAG_ZERO_COPY:
    1: Buffer
    - As MSG_ZEROCOPY tells the kernel to use the same user buffer to avoid copying,
    some caution is necessary to avoid overwriting any buffer before it's sent.
    If something like this happen, a newer version of the buffer may be sent instead.
    - If this is a problem, it's recommended to call qio_channel_flush() before freeing
    or re-using the buffer.
    
    2: Locked memory
    - When using MSG_ZERCOCOPY, the buffer memory will be locked after queued, and
    unlocked after it's sent.
    - Depending on the size of each buffer, and how often it's sent, it may require
    a larger amount of locked memory than usually available to non-root user.
    - If the required amount of locked memory is not available, writev_zero_copy
    will return an error, which can abort an operation like migration,
    - Because of this, when an user code wants to add zero copy as a feature, it
    requires a mechanism to disable it, so it can still be accessible to less
    privileged users.
    
    Signed-off-by: default avatarLeonardo Bras <leobras@redhat.com>
    Reviewed-by: default avatarPeter Xu <peterx@redhat.com>
    Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
    Reviewed-by: default avatarJuan Quintela <quintela@redhat.com>
    Message-Id: <20220513062836.965425-4-leobras@redhat.com>
    Signed-off-by: default avatarDr. David Alan Gilbert <dgilbert@redhat.com>