On Tue, Dec 28, 2010 at 12:57 PM, Daniel Tiron <dti...@debian.armed.us> wrote: > Hello. > >> The br0 interface is just another port to the switch. Since traffic >> is flowing between two VMs, no traffic will be directed to other >> interfaces. It would make more sense to run tcpdump on either the >> interfaces connected to VMs or the mirror target. > > Jesse, thanks for your reply. With your suggestion, I manage to > configure br0 as mirror port as well. Now I am up to comparing the > packet capture rates between capturing from a mirror (br0) and capturing > directly from one of the tap interfaces. The problem is, although my > actual test environment only consists of two virtual machines, there can > be more in other cases - and I need to capture the packets from all of > them. ;-) > >> Data isn't copied during packet forwarding. If you mirror a port it >> copies the packet metadata and adds a reference. > > So the performance impact should be rather small when a mirror port? > I'm really curious what my performance measurements will show. ;-)
Well the actual impact of mirroring should be small. However, what you do with the packet afterwards can have significant cost. If you're trying to get the packet to userspace, you'll incur a full packet copy. > > While looking into the source to understand how an incoming frame is > processed I noticed that you have changed the integration into the Linux > network subsystem. As I can see ovs placed its own function > (netdev_port_receive) as callback function for br_handle_frame_hook. But > as it seems this has been changed for kernels > 2.6.36. > Sorry, I don't see how you grab the frames now. Could you please give me > a hint what has changed? What reasons lead to this change? Was it only > the be able to load the native bridge module at the same time? Kernels 2.6.36 and newer support registering handlers on a per-device basis, which is done in netdev_rx_handler_register() instead of a global function pointer. This avoids conflicts with the bridge. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
