This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel][PATCH] netback: netif cleanup

To: Ky Srinivasan <ksrinivasan@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel][PATCH] netback: netif cleanup
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Sun, 06 Dec 2009 21:44:40 +0000
Delivery-date: Sun, 06 Dec 2009 13:45:15 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B1B84EF020000300007B120@xxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acp2mC9qOriAjkw1QR+aDsdEhwZTIQAJSDLk
Thread-topic: [Xen-devel][PATCH] netback: netif cleanup
User-agent: Microsoft-Entourage/
This looks like a hack. I think you'd get most of the benefit by simply
always calling net_tx_action_dealloc() at the top of net_tx_action() (i.e.,
remove the dealloc_cons!=dealloc_prod conditional). I think the presence of
that conditional is actually a bug, and removing it should get interface
shutdowns to a reasonable time with no other changes.

 -- Keir

On 06/12/2009 17:18, "Ky Srinivasan" <ksrinivasan@xxxxxxxxxx> wrote:

> We have seen cases where,  when a guest is shutdown during heavy network
> traffic, the backend vif hangs around for considerable amounts of time holding
> up the xenbus thread for the duration of the cleanup. We have seen cases (HP,
> Novell) where it has taken hours to cleanup the interface and for that
> duration we cannot launch new guests. We have traced this problem to the fact
> that the front-end can shutdown with transmit resources still in transit on
> the back-end side. On the back-end side, the moment the carrier is turned off
> on the interface, the interface is not eligible for further scheduling in the
> backend. Since turning off the carrier happens completely asynchronously with
> the rest of the packet processing in the back-end (via tasklets today), we can
> have situations where the vif cannot be cleaned up for a significant amount of
> time.
> I am attaching a patch for addressing this issue. I have tried to fix the
> problem with minimal changes to the current code. The main idea is to cleanup
> the guest transmit resources quickly and aggressively. With this patch, the
> cleanup time has been dramatically reduced. Even in this patch, the xenbus
> thread is held up for the duration of the cleanup - however we attempt to
> cleanup aggressively. This is in comparison to the current code where the
> xenbus thread just waits for the refcnt  on the interface to drop to zero. An
> obvious improvement would be to not tie up the xenbus thread for the duration
> of cleaning up the interface. If there is interest, I can submit a patch for
> doing this. This patch has been tested on 2.6.16 (SLES10 sp2, sp3 kernels) as
> well as 2.6.27 (sles11) kernel. This  patch is however against the
> 2.6.18-xen.hg sources.
> Signed-off-by: K. Y. Srinivasan <ksrinivasan@xxxxxxxxxx>
> Regards,
> K. Y

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>