1. 16 Jul, 2009 2 commits
  2. 09 Jul, 2009 2 commits
    • Mark McLoughlin's avatar
      Don't abort if TUNSETSNDBUF fails where no sndbuf= arg is supplied · d026fb6d
      Mark McLoughlin authored
      If no tap,sndbuf= arg is supplied, we use a default value. If
      TUNSETSNDBUF fails in this case, we should not abort.
      Signed-off-by: default avatarMark McLoughlin <markmc@redhat.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      d026fb6d
    • Mark McLoughlin's avatar
      net: set a default value for sndbuf= · fc5b81d1
      Mark McLoughlin authored
      On reflection, perhaps it does make sense to set a default value for
      the sndbuf= tap parameter.
      
      For best effect, sndbuf= should be set to just below the capacity of
      the physical NIC.
      
      Setting it higher will cause packets to be dropped before the limit
      is hit. Setting it much lower will not cause any problems unless
      you set it low enough such that the guest cannot queue up new packets
      before the NIC has emptied its queue.
      
      In Linux, txqueuelen=1000 by default for ethernet NICs. Given a 1500
      byte MTU, 1Mb is a good choice for sndbuf.
      
      If it turns out that txqueuelen is actually much lower than this, then
      sndbuf is essentially disabled. In the event that txqueuelen is much
      higher, it's unlikely that the NIC will be able to empty a 1Mb queue.
      
      Thanks to Herbert Xu for this logic.
      Signed-off-by: default avatarMark McLoughlin <markmc@redhat.com>
      Cc: Herbert Xu <herbert.xu@redhat.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      fc5b81d1
  3. 01 Jul, 2009 1 commit
  4. 29 Jun, 2009 19 commits
  5. 24 Jun, 2009 1 commit
  6. 22 Jun, 2009 10 commits
  7. 13 Jun, 2009 2 commits
  8. 11 Jun, 2009 1 commit
  9. 09 Jun, 2009 2 commits
    • Mark McLoughlin's avatar
      net: make use of async packet sending API in tap client · e19eb224
      Mark McLoughlin authored
      If a packet is queued by qemu_send_packet(), remove I/O
      handler for the tap fd until we get notification that the
      packet has been sent.
      
      A not insignificant side effect of this is we can now
      drain the tap send queue in one go without fear of packets
      being dropped.
      Signed-off-by: default avatarMark McLoughlin <markmc@redhat.com>
      e19eb224
    • Mark McLoughlin's avatar
      net: add qemu_send_packet_async() · f3b6c7fc
      Mark McLoughlin authored
      Add a qemu_send_packet() variant which will queue up the packet
      if it cannot be sent when all client queues are full. It later
      invokes the supplied callback when the packet has been sent.
      
      If qemu_send_packet_async() returns zero, the caller is expected
      to not send any more packets until the queued packet has been
      sent.
      
      Packets are queued iff a receive() handler returns zero (indicating
      queue full) and the caller has provided a sent notification callback
      (indicating it will stop and start its own queue).
      
      We need the packet sending API to support queueing because:
      
        - a sending client should process all available packets in one go
          (e.g. virtio-net emptying its tx ring)
      
        - a receiving client may not be able to handle the packet
          (e.g. -EAGAIN from write() to tapfd)
      
        - the sending client could detect this condition in advance
          (e.g. by select() for writable on tapfd)
      
        - that's too much overhead (e.g. a select() call per packet)
      
        - therefore the sending client must handle the condition by
          dropping the packet or queueing it
      
        - dropping packets is poor form; we should queue.
      
      However, we don't want queueing to be completely transparent. We
      want the sending client to stop sending packets as soon as a
      packet is queued. This allows the sending client to be throttled
      by the receiver.
      Signed-off-by: default avatarMark McLoughlin <markmc@redhat.com>
      f3b6c7fc