Skip to content
Snippets Groups Projects
  • Dor Laor's avatar
    350fa518
    Allow parallel execution of {add|get}_buff, prevent fast path allocs · 350fa518
    Dor Laor authored
    virtio-vring and it's users (net/blk) were changed so no request
    header will be allocated on run time except for init. In order to
    do that, I have to change get_buf and break it into multiple parts:
    
            // Get the top item from the used ring
            void* get_buf_elem(u32 *len);
            // Let the host know we consumed the used entry
            // We separate that from get_buf_elem so no one
            // will re-cycle the request header location until
            // we're finished with it in the upper layer
            void get_buf_finalize();
            // GC the used items that were already read to be emptied
            // within the ring. Should be called by add_buf
            // It was separated from the get_buf flow to allow parallelism of the two
            void get_buf_gc();
    
    As a result, it was simple to get rid of the shared lock that protected
    _avail_head variable before. Today only the thread that calls add_buf
    updates this variable (add_buf calls get_buf_gc internally).
    
    There are two new locks instead:
      - virtio-net tx_gc lock - very rarely it can be accessed
        by the tx_gc thread or normally by the tx xmit thread
      - virtio-blk make_requests - there are parallel requests
    350fa518
    History
    Allow parallel execution of {add|get}_buff, prevent fast path allocs
    Dor Laor authored
    virtio-vring and it's users (net/blk) were changed so no request
    header will be allocated on run time except for init. In order to
    do that, I have to change get_buf and break it into multiple parts:
    
            // Get the top item from the used ring
            void* get_buf_elem(u32 *len);
            // Let the host know we consumed the used entry
            // We separate that from get_buf_elem so no one
            // will re-cycle the request header location until
            // we're finished with it in the upper layer
            void get_buf_finalize();
            // GC the used items that were already read to be emptied
            // within the ring. Should be called by add_buf
            // It was separated from the get_buf flow to allow parallelism of the two
            void get_buf_gc();
    
    As a result, it was simple to get rid of the shared lock that protected
    _avail_head variable before. Today only the thread that calls add_buf
    updates this variable (add_buf calls get_buf_gc internally).
    
    There are two new locks instead:
      - virtio-net tx_gc lock - very rarely it can be accessed
        by the tx_gc thread or normally by the tx xmit thread
      - virtio-blk make_requests - there are parallel requests