Skip to content

AccelIO v1.7 GA

Latest
Compare
Choose a tag to compare
@ilansmith ilansmith released this 21 Jul 19:08

New features:

  1. Added support for SRQ (shared receive queue) in RDMA. This allows the receive resources (such as xio_task and its' adjacent memory) to be shared between several QPs. This significantly reduces Accelio memory foot print. SRQ is currently only supported in user mode Accelio and thus is disabled by default. It can be enabled by a configuration flag during configuration:

    ./configure --enable-shared-receive-queue=yes

  2. Added new types of session events:

    1. XIO_SESSION_CONNECTION_RECONNECTING_EVENT that indicates that reconnect has began
    2. XIO_SESSION_CONNECTION_RECONNECTED_EVENT that indicated that reconnect has successfully ended
  3. Added support for Debian packaging

Changes:

  1. The user application can now configure nexus close timeout passing parameter XIO_OPTNAME_TRANSPORT_CLOSE_TIMEOUT to xio_set_opt(). This parameter is in units of milliseconds (default value is 1 minute) and it represents the time that passes after the last xio_connection on the same transport is closed and the transport (TCP socket or RDMA QP) is closed.
  2. The user can now configure the number of tasks in the RDMA receive queue. This is done by passing rq_depth in xio_context_params when creating the xio_context. Passing 0 indicated that the user wants to use the default value (the receive queue will be "XIO_MAX_IOV + constant" deep). This is useful for example if the user knows for a fact that all QPs on this context will receive only msgs with a small number of vector elements seldom and he wishes to save memory.

Bug fixes:

  1. Fix header not appearing in assign_data_in_buf() in TCP. When using XIO_TCP_READ in dual stream the user header was attached to the user data and not to the xio_header. This caused the assign_data_in_buf() callback to be triggered on a message without the header.
  2. In case of nexus shared by multiple connections, not all "connection established" notifications were posted since work member was overwritten again and again. Now the work member is dynamically allocated/freed.