[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] (repeatable) cross-domain networking failure
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |