WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] (repeatable) cross-domain networking failure

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] (repeatable) cross-domain networking failure
From: mukesh agrawal <xen.sourceforge.net@xxxxxxxxxxxxxxxxxxx>
Date: Sun, 16 Jan 2005 16:56:04 -0500 (EST)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx, Nivedita Singhvi <niv@xxxxxxxxxx>
Delivery-date: Sun, 16 Jan 2005 21:57:37 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <E1CqHe4-0004Ve-00@xxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <E1CqHe4-0004Ve-00@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
On Sun, 16 Jan 2005, Keir Fraser wrote:

This corroborates my intial guess that the backend driver (in DOM0) is
sending the packets into the DOM0 networking layer, and never hearing
back when the packet is freed. Normally this would trigger a response
to be sent back to the domU and resources in the backend driver would
get freed up. This isn't happening and you eventually hit a limit on
the number of packets that the driver will simultaneously put in
flight.

When you say "resources in the backend driver would get freed up", that's the domU (sender) backend driver?

Either those UDP packets are queued up somewhere in the DOM0 network
stack, or the destructor callback is not getting called for some
reason or has got overwritten(!).

Well, the packets aren't stuck in the dom0 network stack... They get delivered all the way up to the application just fine (nc in the trivial test case). So I think it must be the latter... After delivering the UDP packet to the application, the destructor is not being called back.

Further, this seems to be specific to the receive path for packets delivered to userspace (since traffic to the kernel NFS server doesn't seem to trigger it, nor traffic to closed ports).

What (specific source files or documentation) would you suggest starting at, to see an example of how the destruction is supposed to be done? I guess the TCP receive code works properly, so maybe I should compare that to the UDP code?

Thanks,
mukesh



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel