On Fri, Aug 12, 2005 at 12:02:46PM +0200, Henrik Nordstrom wrote: > >This solves the problem quite nicely, and it is probably the simplest to > >implement, but requires changing the hardware. > > > >I'm trying to figure out how to achieve the same effect with eth0 and tap0 > >(as opposed to eth0 and eth1). > > Not easily done as you are then missing the switch component looping the > frames back to eth0. >
Well, I'm also comparing this to, say, a user space bridge of tap0 and tap1. For that, we are also missing the switch component, but this is easy to solve. The user space component simply needs the file descriptors of both tap0 and tap1, then when it receives a packet on tap0 it can simply write it to tap1 and vice versa. Since writing a packet to the file descriptor of a tap device causes the upper layer protocol layers to take a look at it, the issue doesn't exist here. >From a brief look at the kernel code, it looks like netif_rx() can be used to achieve the same effect for a real ethernet card. Packets that are recieved by the device driver are queued with netif_rx() to be interpreted by the host OS protocol stack, so if vde_pcap could call netif_rx() directly then it could inject packets at the ethernet frame level to the host OS directly. Unfortuantly vde_pcap is a userland program and netif_rx() is a kernel function, so unless netif_rx() is exposed thru a procfs interface or something similar there is no way to take advantage of it. > >If we had a), then vde_pcap would "just work" - there'd be no need to > >fiddle > >with faking things on tap devices or etc. > > Not fully. Without having the bridge component in the mix frames sent by > the guest to the host is likely to be echoed out on the LAN. > Ideally, packets destined for the host will end up in the OS's protocol stack and stay there, while packets destined elsewhere will actually go thru the NIC and into the LAN. Of course, vde_pcap could write packets for the host via netif_rx() and send the rest thru the packet socket. AFAICS packets sent thru netif_rx() will not be echoed back out the device again. > >Most of these are my goals as well (except I don't mind having to run a > >bit of > >glue in a startup script). > > If you are prepared to run a bit of glue in system startup scripts then > use bridgeing with a tap device. This provides the absolutely cleanest > networking capabilities. > That is very true. > > Regards > Henrik > -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
