1. 25 3月, 2013 1 次提交
    • S
      net: increase buffer size to accommodate Jumbo frame pkts · d32fcad3
      Scott Feldman 提交于
      Socket buffer sizes were hard-coded to 4K for VDE and socket netdevs.  Bump this
      up to 68K (ala tap netdev) to handle maximum GSO packet size (64k) plus plenty
      of room for the ethernet and virtio_net headers.
      
      Originally, ran into this limitation when using -netdev UDP sockets to connect
      VM-to-VM, where VM interface is configure with MTU=9000.  (Using virtio_net
      NIC model).  Test is simple: ping -M do -s 8500 <target>.  This test will
      attempt to ping with unfragmented packet of given size.  Without patch, size
      is limited to < 4K (minus protocol hdrs).  With patch, ping test works with pkt
      size up to 9000 (again, minus protocol hdrs).
      
      v2: per Stefan, increase buf size to (4096+65536) as done in tap and apply
          to vde and socket netdevs.
      v1: increase buf size to 12K just for -netdev UDP sockets
      Signed-off-by: NScott Feldman <sfeldma@cumulusnetworks.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      d32fcad3
  2. 27 2月, 2013 2 次提交
    • J
      net: reduce the unnecessary memory allocation of multiqueue · f6b26cf2
      Jason Wang 提交于
      Edivaldo reports a problem that the array of NetClientState in NICState is too
      large - MAX_QUEUE_NUM(1024) which will wastes memory even if multiqueue is not
      used.
      
      Instead of static arrays, solving this issue by allocating the queues on demand
      for both the NetClientState array in NICState and VirtIONetQueue array in
      VirtIONet.
      
      Tested by myself, with single virtio-net-pci device. The memory allocation is
      almost the same as when multiqueue is not merged.
      
      Cc: Edivaldo de Araujo Pereira <edivaldoapereira@yahoo.com.br>
      Cc: qemu-stable@nongnu.org
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      f6b26cf2
    • L
      net: fix qemu_flush_queued_packets() in presence of a hub · 199ee608
      Luigi Rizzo 提交于
      When frontend and backend are connected through a hub as below
      (showing only one direction), and the frontend (or in general, all
      output ports of the hub) cannot accept more traffic, the backend
      queues packets in queue-A.
      
      When the frontend (or in general, one output port) becomes ready again,
      quemu tries to flush packets from queue-B, which is unfortunately empty.
      
        e1000.0 <--[queue B]-- hub0port0(hub)hub0port1 <--[queue A]-- tap.0
      
      To fix this i propose to introduce a new function net_hub_flush()
      which is called when trying to flush a queue connected to a hub.
      Signed-off-by: NLuigi Rizzo <rizzo@iet.unipi.it>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      199ee608
  3. 14 2月, 2013 1 次提交
  4. 08 2月, 2013 1 次提交
    • M
      net: fix infinite loop on exit · b8904921
      Michael Roth 提交于
      1ceef9f2 added handling for cleaning
      up multiple queues in qemu_del_nic() for cases where multiqueue is in
      use. To determine the number of queues it looks at nic->conf->queues,
      then iterates through all the queues to cleanup the associated
      NetClientStates. If no queues are found, no NetClientStates are deleted.
      
      However, nic->conf->queues is only set when a peer is created via
      -netdev or netdev_add, and is otherwise 0. This causes us to spin in
      net_cleanup() if we attempt to shut down qemu before adding a host
      device.
      
      Since qemu_new_nic() unconditionally creates at least 1
      queue/NetClientState at queue idx 0, make qemu_del_nic() always attempt
      to clean it up.
      Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      b8904921
  5. 02 2月, 2013 7 次提交
  6. 30 1月, 2013 1 次提交
  7. 17 1月, 2013 1 次提交
  8. 13 1月, 2013 1 次提交
  9. 19 12月, 2012 6 次提交
  10. 01 11月, 2012 1 次提交
    • S
      net: Reject non-netdevs in qmp_netdev_del() · 645c9496
      Stefan Hajnoczi 提交于
      The netdev_del command crashes when given a -net device, because it
      calls qemu_opts_del(NULL).
      
      Check that this is a -netdev before attempting to delete it and the
      QemuOpts.
      
      Note the subtle change from qemu_find_opts_err("netdev", errp) to
      qemu_find_opts_err("netdev", NULL).  Since "netdev" is a built in
      options group and we don't check for NULL return anyway, there's no use
      in passing errp here.
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      645c9496
  11. 08 10月, 2012 1 次提交
    • P
      net: consolidate NetClientState header files into one · a245fc18
      Paolo Bonzini 提交于
      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: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@gmail.com>
      a245fc18
  12. 14 9月, 2012 2 次提交
    • S
      net: add receive_disabled logic to iov delivery path · c67f5dc1
      Stefan Hajnoczi 提交于
      This patch adds the missing NetClient->receive_disabled logic in the
      sendv delivery code path.  It seems that commit
      893379ef ("net: disable receiving if
      client returns zero") only added the logic to qemu_deliver_packet() and
      not qemu_deliver_packet_iov().
      
      The receive_disabled flag should be automatically set when .receive(),
      .receive_raw(), or .receive_iov() return 0.  No further packets will be
      delivered to the NetClient until the receive_disabled flag is cleared
      again by calling qemu_flush_queued_packets().
      
      Typically the NetClient will wait until its file descriptor becomes
      writable and then invoke qemu_flush_queued_packets() to resume
      transmission.
      Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      c67f5dc1
    • P
      net: notify iothread after flushing queue · 987a9b48
      Paolo Bonzini 提交于
      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: NLuigi Rizzo <rizzo@iet.unipi.it>
      Cc: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      Cc: Jan Kiszka <jan.kiszka@siemens.de>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: NAmos Kong <akong@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      987a9b48
  13. 07 9月, 2012 1 次提交
  14. 03 8月, 2012 1 次提交
    • P
      Support 'help' as a synonym for '?' in command line options · c8057f95
      Peter Maydell 提交于
      For command line options which permit '?' meaning 'please list the
      permitted values', add support for 'help' as a synonym, by abstracting
      the check out into a helper function.
      
      This change means that in some cases where we were being lazy in
      our string parsing, "?junk" will now be rejected as an invalid option
      rather than being (undocumentedly) treated the same way as "?".
      
      Update the documentation to use 'help' rather than '?', since '?'
      is a shell metacharacter and thus prone to fail confusingly if there
      is a single character filename in the current working directory and
      the '?' has not been escaped. It's therefore better to steer users
      towards 'help', though '?' is retained for backwards compatibility.
      
      We do not, however, update the output of the system emulator's -help
      (or any documentation autogenerated from the qemu-options.hx which
      is the source of the -help text) because libvirt parses our -help
      output and will break. At a later date when QEMU provides a better
      interface so libvirt can avoid having to do this, we can update the
      -help text too.
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      c8057f95
  15. 01 8月, 2012 13 次提交