ia64/xen-unstable
changeset 10975:7684f9032f9f
[NET] front: Check for received packets in network_open0
Because the backend brings up the interface long before the frontend
has booted up, it is possible that by the time we get here we already
have packets queued up for processing.
If we don't process them here, we may delay them more than what is
necessary. Worse yet, it is possible to miss the notification
interrupt from the backend in such a way that we never get another
one until we bring the interface down and up.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Because the backend brings up the interface long before the frontend
has booted up, it is possible that by the time we get here we already
have packets queued up for processing.
If we don't process them here, we may delay them more than what is
necessary. Worse yet, it is possible to miss the notification
interrupt from the backend in such a way that we never get another
one until we bring the interface down and up.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
author | ack@localhost.localdomain |
---|---|
date | Fri Aug 04 16:07:58 2006 +0100 (2006-08-04) |
parents | e1a2a8029e9f |
children | 49dcd838b7df |
files | linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c |
line diff
1.1 --- a/linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c Fri Aug 04 11:36:07 2006 +0100 1.2 +++ b/linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c Fri Aug 04 16:07:58 2006 +0100 1.3 @@ -497,6 +497,9 @@ static int network_open(struct net_devic 1.4 network_alloc_rx_buffers(dev); 1.5 np->rx.sring->rsp_event = np->rx.rsp_cons + 1; 1.6 1.7 + if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx)) 1.8 + netif_rx_schedule(dev); 1.9 + 1.10 netif_start_queue(dev); 1.11 1.12 return 0;