From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [Qemu-devel] [PATCH 1/5] virtio-net: Make tx_timer timeout configurable Date: Tue, 31 Aug 2010 12:07:16 -0600 Message-ID: <1283278036.5826.116.camel@x201> References: <20100827223659.2696.3589.stgit@s20.home> <20100827223708.2696.47389.stgit@s20.home> <20100831180048.GE30129@sequoia.sous-sol.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, jes.sorensen@redhat.com, kvm@vger.kernel.org To: Chris Wright Return-path: Received: from mx1.redhat.com ([209.132.183.28]:39735 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754097Ab0HaSHX (ORCPT ); Tue, 31 Aug 2010 14:07:23 -0400 In-Reply-To: <20100831180048.GE30129@sequoia.sous-sol.org> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, 2010-08-31 at 11:00 -0700, Chris Wright wrote: > * Alex Williamson (alex.williamson@redhat.com) wrote: > > diff --git a/hw/virtio-net.c b/hw/virtio-net.c > > index 075f72d..9ef29f0 100644 > > --- a/hw/virtio-net.c > > +++ b/hw/virtio-net.c > > @@ -36,6 +36,7 @@ typedef struct VirtIONet > > VirtQueue *ctrl_vq; > > NICState *nic; > > QEMUTimer *tx_timer; > > + uint32_t tx_timeout; > > int tx_timer_active; > > uint32_t has_vnet_hdr; > > uint8_t has_ufo; > > @@ -702,7 +703,7 @@ static void virtio_net_handle_tx(VirtIODevice *vdev, VirtQueue *vq) > > virtio_net_flush_tx(n, vq); > > } else { > > qemu_mod_timer(n->tx_timer, > > - qemu_get_clock(vm_clock) + TX_TIMER_INTERVAL); > > + qemu_get_clock(vm_clock) + n->tx_timeout); > > n->tx_timer_active = 1; > > virtio_queue_set_notification(vq, 0); > > } > > @@ -842,7 +843,7 @@ static int virtio_net_load(QEMUFile *f, void *opaque, int version_id) > > > > if (n->tx_timer_active) { > > qemu_mod_timer(n->tx_timer, > > - qemu_get_clock(vm_clock) + TX_TIMER_INTERVAL); > > + qemu_get_clock(vm_clock) + n->tx_timeout); > > I think I'm missing where this is stored? Looks like migration > would revert a changed tx_timeout back to 150us. It's not stored, it can be instantiated on the migration target any way you please and we can migrate between different values or even different TX mitigation strategies. If a non-default value is used on the source and you want to maintain the same behavior, the target needs to be started the same way. Alex