Merge branch 'macvtap_capture'
authorDavid S. Miller <davem@davemloft.net>
Thu, 12 Dec 2013 18:38:46 +0000 (13:38 -0500)
committerDavid S. Miller <davem@davemloft.net>
Thu, 12 Dec 2013 18:38:46 +0000 (13:38 -0500)
commita46dc748caea185d4d0978280a1af0112bf6a8f8
tree80d2a3c5c9396bdd07c751eaa2ccfd42cd9c87c2
parent70f5613271744c8375d5d20a6685a58a9fdcaf8a
parent2f6a1b6607fd6b0eb9501843a40e0c7555f37b4a
Merge branch 'macvtap_capture'

Vlad Yasevich says:

====================
Add packet capture support on macvtap device

Change from RFC:
  - moved to the rx_handler approach.

This series adds support for packet capturing on macvtap device.
The initial approach was to simply export the capturing code as
a function from the core network.  While simple, it was not
a very architecturally clean approach.

The new appraoch is to provide macvtap with its rx_handler which can
is attached to the macvtap device itself.   Macvlan will simply requeue
the packet with an updated skb->dev.  BTW, macvlan layer already does this
for macvlan devices.  So, now macvtap and macvlan have almost the
same exact input path.

I've toyed with short-circuting the input path for macvtap by returning
RX_HANDLER_ANOTHER, but that just made the code more complicated and
didn't provide any kind of measurable gain (at least according to
netperf and perf runs on the host).

To see if there was a performance regression, I ran 1, 2 and 4 netperf
STREAM and MAERTS tests agains the VM from both remote host and another
guest on the same system.   The command ran was
    netperf -H $host -t $test -l 20 -i 10 -I 95 -c -C

The numbers I was getting with the new code were consistently very
slightly (1-2%) better then the old code.  I don't consider this
an improvement, but it's not a regression! :)

Running 'perf record' on the host didn't show any new hot spots
and cpu utilization stayed about the same.  This was better
then I expected from simply looking at the code.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>