1. 19 Oct, 2012 1 commit
  2. 08 Oct, 2012 1 commit
    • Paolo Bonzini's avatar
      net: consolidate NetClientState header files into one · a245fc18
      Paolo Bonzini authored
      This patch doesn't seem much useful alone, I must admit.  However,
      it makes sense as part of the upcoming directory reorganization,
      where I want to have include/net/tap.h as the net<->hw interface
      for tap.  Then having both net/tap.h and include/net/tap.h does
      not work.  "Fixed" by moving all the init functions to a single
      header file net/clients.h.
      The patch also adopts a uniform style for including net/*.h files
      from net/*.c, without the net/ path.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@gmail.com>
  3. 23 Sep, 2012 1 commit
  4. 14 Sep, 2012 6 commits
    • Stefan Hajnoczi's avatar
      net: EAGAIN handling for net/socket.c TCP · 45a7f54a
      Stefan Hajnoczi authored
      Replace spinning send_all() with a proper non-blocking send.  When the
      socket write buffer limit is reached, we should stop trying to send and
      wait for the socket to become writable again.
      Non-blocking TCP sockets can return in two different ways when the write
      buffer limit is reached:
      1. ret = -1 and errno = EAGAIN/EWOULDBLOCK.  No data has been written.
      2. ret < total_size.  Short write, only part of the message was
      Handle both cases and keep track of how many bytes have been written in
      s->send_index.  (This includes the 'length' header before the actual
      payload buffer.)
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
    • Stefan Hajnoczi's avatar
      net: EAGAIN handling for net/socket.c UDP · 213fd508
      Stefan Hajnoczi authored
      Implement asynchronous send for UDP (or other SOCK_DGRAM) sockets.  If
      send fails with EAGAIN we wait for the socket to become writable again.
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
    • Stefan Hajnoczi's avatar
      net: asynchronous send/receive infrastructure for net/socket.c · 863f678f
      Stefan Hajnoczi authored
      The net/socket.c net client is not truly asynchronous.  This patch
      borrows the qemu_set_fd_handler2() code from net/tap.c as the basis for
      proper asynchronous send/receive.
      Only read packets from the socket when the peer is able to receive.
      This avoids needless queuing.
      Later patches implement asynchronous send.
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
    • Stefan Hajnoczi's avatar
      net: broadcast hub packets if at least one port can receive · 61518a74
      Stefan Hajnoczi authored
      In commit 60c07d93 ("net: fix
      qemu_can_send_packet logic") the "VLAN" broadcast behavior was changed
      to queue packets if any net client cannot receive.  It turns out that
      this was not actually the right fix and just hides the real bug that
      hw/usb/dev-network.c:usbnet_receive() clobbers its receive buffer when
      called multiple times in a row.  The commit also introduced a new bug
      that "VLAN" packets would not be sent if one of multiple net clients was
      The hw/usb/dev-network.c bug has since been fixed, so this patch reverts
      broadcast behavior to send packets as long as one net client can
      receive.  Packets simply get queued for the net clients that are
      temporarily unable to receive.
      Reported-by: default avatarRoy.Li <rongqing.li@windriver.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
    • Stefan Hajnoczi's avatar
      net: do not report queued packets as sent · 06b5f36d
      Stefan Hajnoczi authored
      Net send functions have a return value where 0 means the packet has not
      been sent and will be queued.  A non-zero value means the packet was
      sent or an error caused the packet to be dropped.
      This patch fixes two instances where packets are queued but we return
      their size.  This causes callers to believe the packets were sent.  When
      the caller uses the async send interface this creates a real problem
      because the callback will be invoked for a packet that the caller
      believed to be already sent.  This bug can cause double-frees in the
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
    • Paolo Bonzini's avatar
      net: notify iothread after flushing queue · 987a9b48
      Paolo Bonzini authored
      virtio-net has code to flush the queue and notify the iothread
      whenever new receive buffers are added by the guest.  That is
      fine, and indeed we need to do the same in all other drivers.
      However, notifying the iothread should be work for the network
      subsystem.  And since we are at it we can add a little smartness:
      if some of the queued packets already could not be delivered,
      there is no need to notify the iothread.
      Reported-by: default avatarLuigi Rizzo <rizzo@iet.unipi.it>
      Cc: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      Cc: Jan Kiszka <jan.kiszka@siemens.de>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: default avatarAmos Kong <akong@redhat.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
  5. 07 Sep, 2012 1 commit
  6. 09 Aug, 2012 1 commit
  7. 01 Aug, 2012 15 commits
  8. 23 Jul, 2012 9 commits
  9. 09 Jul, 2012 4 commits
  10. 15 Jun, 2012 1 commit