From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C0NPW-0003CY-P0 for qemu-devel@nongnu.org; Thu, 26 Aug 2004 12:47:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C0NPV-0003Bb-Oc for qemu-devel@nongnu.org; Thu, 26 Aug 2004 12:47:38 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C0NPV-0003B1-IX for qemu-devel@nongnu.org; Thu, 26 Aug 2004 12:47:37 -0400 Received: from [64.233.170.205] (helo=mproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C0NKo-0002lE-3y for qemu-devel@nongnu.org; Thu, 26 Aug 2004 12:42:46 -0400 Received: by mproxy.gmail.com with SMTP id v18so219322rnb for ; Thu, 26 Aug 2004 09:42:45 -0700 (PDT) Message-ID: <5640213304082609425986326c@mail.gmail.com> Date: Thu, 26 Aug 2004 11:42:45 -0500 From: Mike Tremoulet Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] pcap-based networking? Reply-To: Mike Tremoulet , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org All -- Apologies if this design decision has been worked before. I've successfully run various *nixes on my Win2K host, and while the slirp solution usually works, I was thinking of ways to make it more flexible. I haven't finished identifying parts of the source code yet (my C skills aren't that sharp), but from what I can tell, the tun/tap interface uses file read/write operations to work on Unix, and the slirp module does its thing somewhere as well, and the choice is made by compile options and command-line switches. My question is: Is there a reason to use (or not to use) a libpcap/libnet solution for networking? At a high level, I think of it as a queue of incoming packets and a queue of outgoing packets (from the standpoint of the guest). Outgoing packets from the guest would be held in a queue and written onto the network via libnet, and incoming packets would get captured by libpcap and written to the virtual device. The advantages for me would be: - I can bind this networking to the device of my explicit choosing at runtime. So, I could install a tap device on my host and have qemu always use that device, or I could bind it to a second NIC on the host. - More importantly, this can be somewhat platform independant. Libpcap exists in a very similar, if not identical, API in the form of winpcap. I know there is an equivalent way to write packets to the network, but I forget the name right now. What would the potential performance impacts be? Is this something that I/we should pursue? Other thoughts? -- Mike