[ovs-discuss] Some questions on ovs

[Jesse Gross]

On Fri, Jan 7, 2011 at 1:31 PM, Daniel Tiron <dtiron at debian.armed.us> wrote:
> Hello.
>
> Thanks for your answer.
>
>> >> 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.
>
> Yes, I have to get the packets into the userspace. But I have to do this
> anyway because I need to process the data with a monitoring tool called
> vermont [1]. So there's no chance I can keep the data in kernel space
> and do my stuff there. The capturing engine in my setup is PF_RING which
> *does* a full copy of each skb. I suppose this is the one copy you're
> talking about, too?

Yes.  As Peter said, though, if you can do some filtering or sampling
in the kernel that would help a lot.

>
> As I see it, the necessary copy has nothing to do with or without using
> a mirror port -> the performance should not differ very much from
> capturing from br0 (= configured as mirror) to capturing from tapXX
> (without a mirror port)? What would you say?

Right, that was my original point.  You were talking measuring the
cost of mirroring but the other pieces of your setup are much more
expensive, so the mirroring should just be noise.

>
>> 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.
>
> That sounds good. ;-) I didn't look at the source code yet, but I
> suppose the idea is the same as before: Kernel provides a callback-hook
> and ovs registers its own handler function, but in this case for each
> device separately?

Yes.