[PATCH net-next 0/2] Add packet capture support on macvtap device

[PATCH net-next 0/2] Add packet capture support on macvtap device

[Vlad Yasevich]

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.

Vlad Yasevich (2):
  macvtap: Add support of packet capture on macvtap device.
  macvlan: Remove custom recieve and forward handlers

 drivers/net/macvlan.c      | 17 ++++---------
 drivers/net/macvtap.c      | 63 +++++++++++++++++++++++++---------------------
 include/linux/if_macvlan.h |  7 +-----
 3 files changed, 41 insertions(+), 46 deletions(-)

-- 
1.8.4.2

[PATCH net-next 1/2] macvtap: Add support of packet capture on macvtap device.

[Vlad Yasevich]

Macvtap device currently doesn not allow a user to capture
traffic on due to the fact that it steals the packets
from the network stack before the skb->dev is set correctly
on the receive side, and that use uses macvlan transmit
path directly on the send side.  As a result, we never
get a change to give traffic to the taps while the correct
device is set in the skb.

This patch makes macvtap device behave almost exaclty like
macvlan.  On the send side, we switch to using dev_queue_xmit().
On the receive side, to deliver packets to macvtap, we now
use netif_rx and dev_forward_skb just like macvlan.  The only
differnce now is that macvtap has its own rx_handler which is
attached to the macvtap netdev.  It is here that we now steal
the packet and provide it to the socket.

As a result, we can now capture traffic on the macvtap device:
   tcpdump -i macvtap0

It also gives us the abilit to add tc actions to the macvtap
device and actually utilize different bandwidth management
queues on output.

Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
---
 drivers/net/macvtap.c | 59 ++++++++++++++++++++++++++++-----------------------
 1 file changed, 32 insertions(+), 27 deletions(-)

diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 4c6f84c..f9847da 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -70,6 +70,11 @@ static const struct proto_ops macvtap_socket_ops;
 #define RX_OFFLOADS (NETIF_F_GRO | NETIF_F_LRO)
 #define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG)
 
+static struct macvlan_dev *macvtap_get_vlan_rcu(const struct net_device *dev)
+{
+	return rcu_dereference(dev->rx_handler_data);
+}
+
 /*
  * RCU usage:
  * The macvtap_queue and the macvlan_dev are loosely coupled, the
@@ -271,24 +276,27 @@ static void macvtap_del_queues(struct net_device *dev)
 		sock_put(&qlist[j]->sk);
 }
 
-/*
- * Forward happens for data that gets sent from one macvlan
- * endpoint to another one in bridge mode. We just take
- * the skb and put it into the receive queue.
- */
-static int macvtap_forward(struct net_device *dev, struct sk_buff *skb)
+static rx_handler_result_t macvtap_handle_frame(struct sk_buff **pskb)
 {
-	struct macvlan_dev *vlan = netdev_priv(dev);
-	struct macvtap_queue *q = macvtap_get_queue(dev, skb);
+	struct sk_buff *skb = *pskb;
+	struct net_device *dev = skb->dev;
+	struct macvlan_dev *vlan;
+	struct macvtap_queue *q;
 	netdev_features_t features = TAP_FEATURES;
 
+	vlan = macvtap_get_vlan_rcu(dev);
+	if (!vlan)
+		return RX_HANDLER_PASS;
+
+	q = macvtap_get_queue(dev, skb);
 	if (!q)
-		goto drop;
+		return RX_HANDLER_PASS;
 
 	if (skb_queue_len(&q->sk.sk_receive_queue) >= dev->tx_queue_len)
 		goto drop;
 
-	skb->dev = dev;
+	skb_push(skb, ETH_HLEN);
+
 	/* Apply the forward feature mask so that we perform segmentation
 	 * according to users wishes.  This only works if VNET_HDR is
 	 * enabled.
@@ -320,22 +328,13 @@ static int macvtap_forward(struct net_device *dev, struct sk_buff *skb)
 
 wake_up:
 	wake_up_interruptible_poll(sk_sleep(&q->sk), POLLIN | POLLRDNORM | POLLRDBAND);
-	return NET_RX_SUCCESS;
+	return RX_HANDLER_CONSUMED;
 
 drop:
+	/* Count errors/drops only here, thus don't care about args. */
+	macvlan_count_rx(vlan, 0, 0, 0);
 	kfree_skb(skb);
-	return NET_RX_DROP;
-}
-
-/*
- * Receive is for data from the external interface (lowerdev),
- * in case of macvtap, we can treat that the same way as
- * forward, which macvlan cannot.
- */
-static int macvtap_receive(struct sk_buff *skb)
-{
-	skb_push(skb, ETH_HLEN);
-	return macvtap_forward(skb->dev, skb);
+	return RX_HANDLER_CONSUMED;
 }
 
 static int macvtap_get_minor(struct macvlan_dev *vlan)
@@ -385,6 +384,8 @@ static int macvtap_newlink(struct net *src_net,
 			   struct nlattr *data[])
 {
 	struct macvlan_dev *vlan = netdev_priv(dev);
+	int err;
+
 	INIT_LIST_HEAD(&vlan->queue_list);
 
 	/* Since macvlan supports all offloads by default, make
@@ -392,16 +393,21 @@ static int macvtap_newlink(struct net *src_net,
 	 */
 	vlan->tap_features = TUN_OFFLOADS;
 
+	err = netdev_rx_handler_register(dev, macvtap_handle_frame, vlan);
+	if (err)
+		return err;
+
 	/* Don't put anything that may fail after macvlan_common_newlink
 	 * because we can't undo what it does.
 	 */
 	return macvlan_common_newlink(src_net, dev, tb, data,
-				      macvtap_receive, macvtap_forward);
+				      netif_rx, dev_forward_skb);
 }
 
 static void macvtap_dellink(struct net_device *dev,
 			    struct list_head *head)
 {
+	netdev_rx_handler_unregister(dev);
 	macvtap_del_queues(dev);
 	macvlan_dellink(dev, head);
 }
@@ -725,9 +731,8 @@ static ssize_t macvtap_get_user(struct macvtap_queue *q, struct msghdr *m,
 		skb_shinfo(skb)->tx_flags |= SKBTX_SHARED_FRAG;
 	}
 	if (vlan) {
-		local_bh_disable();
-		macvlan_start_xmit(skb, vlan->dev);
-		local_bh_enable();
+		skb->dev = vlan->dev;
+		dev_queue_xmit(skb);
 	} else {
 		kfree_skb(skb);
 	}
-- 
1.8.4.2

[PATCH net-next 2/2] macvlan: Remove custom recieve and forward handlers

[Vlad Yasevich]

Since now macvlan and macvtap use the same receive and
forward handlers, we can remove them completely and use
netif_rx and dev_forward_skb() directly.

Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
---
 drivers/net/macvlan.c      | 17 +++++------------
 drivers/net/macvtap.c      |  3 +--
 include/linux/if_macvlan.h |  7 +------
 3 files changed, 7 insertions(+), 20 deletions(-)

diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index cfb9157..24ea994 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -120,7 +120,7 @@ static int macvlan_broadcast_one(struct sk_buff *skb,
 	struct net_device *dev = vlan->dev;
 
 	if (local)
-		return vlan->forward(dev, skb);
+		return dev_forward_skb(dev, skb);
 
 	skb->dev = dev;
 	if (ether_addr_equal_64bits(eth->h_dest, dev->broadcast))
@@ -128,7 +128,7 @@ static int macvlan_broadcast_one(struct sk_buff *skb,
 	else
 		skb->pkt_type = PACKET_MULTICAST;
 
-	return vlan->receive(skb);
+	return netif_rx(skb);
 }
 
 static u32 macvlan_hash_mix(const struct macvlan_dev *vlan)
@@ -251,7 +251,7 @@ static rx_handler_result_t macvlan_handle_frame(struct sk_buff **pskb)
 	skb->dev = dev;
 	skb->pkt_type = PACKET_HOST;
 
-	ret = vlan->receive(skb);
+	ret = netif_rx(skb);
 
 out:
 	macvlan_count_rx(vlan, len, ret == NET_RX_SUCCESS, 0);
@@ -803,10 +803,7 @@ static int macvlan_validate(struct nlattr *tb[], struct nlattr *data[])
 }
 
 int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
-			   struct nlattr *tb[], struct nlattr *data[],
-			   int (*receive)(struct sk_buff *skb),
-			   int (*forward)(struct net_device *dev,
-					  struct sk_buff *skb))
+			   struct nlattr *tb[], struct nlattr *data[])
 {
 	struct macvlan_dev *vlan = netdev_priv(dev);
 	struct macvlan_port *port;
@@ -848,8 +845,6 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
 	vlan->lowerdev = lowerdev;
 	vlan->dev      = dev;
 	vlan->port     = port;
-	vlan->receive  = receive;
-	vlan->forward  = forward;
 	vlan->set_features = MACVLAN_FEATURES;
 
 	vlan->mode     = MACVLAN_MODE_VEPA;
@@ -894,9 +889,7 @@ EXPORT_SYMBOL_GPL(macvlan_common_newlink);
 static int macvlan_newlink(struct net *src_net, struct net_device *dev,
 			   struct nlattr *tb[], struct nlattr *data[])
 {
-	return macvlan_common_newlink(src_net, dev, tb, data,
-				      netif_rx,
-				      dev_forward_skb);
+	return macvlan_common_newlink(src_net, dev, tb, data);
 }
 
 void macvlan_dellink(struct net_device *dev, struct list_head *head)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index f9847da..46168d0 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -400,8 +400,7 @@ static int macvtap_newlink(struct net *src_net,
 	/* Don't put anything that may fail after macvlan_common_newlink
 	 * because we can't undo what it does.
 	 */
-	return macvlan_common_newlink(src_net, dev, tb, data,
-				      netif_rx, dev_forward_skb);
+	return macvlan_common_newlink(src_net, dev, tb, data);
 }
 
 static void macvtap_dellink(struct net_device *dev,
diff --git a/include/linux/if_macvlan.h b/include/linux/if_macvlan.h
index 84ba5ac..ea22721 100644
--- a/include/linux/if_macvlan.h
+++ b/include/linux/if_macvlan.h
@@ -69,8 +69,6 @@ struct macvlan_dev {
 	netdev_features_t	set_features;
 	enum macvlan_mode	mode;
 	u16			flags;
-	int (*receive)(struct sk_buff *skb);
-	int (*forward)(struct net_device *dev, struct sk_buff *skb);
 	/* This array tracks active taps. */
 	struct macvtap_queue	__rcu *taps[MAX_MACVTAP_QUEUES];
 	/* This list tracks all taps (both enabled and disabled) */
@@ -103,10 +101,7 @@ static inline void macvlan_count_rx(const struct macvlan_dev *vlan,
 extern void macvlan_common_setup(struct net_device *dev);
 
 extern int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
-				  struct nlattr *tb[], struct nlattr *data[],
-				  int (*receive)(struct sk_buff *skb),
-				  int (*forward)(struct net_device *dev,
-						 struct sk_buff *skb));
+				  struct nlattr *tb[], struct nlattr *data[]);
 
 extern void macvlan_count_rx(const struct macvlan_dev *vlan,
 			     unsigned int len, bool success,
-- 
1.8.4.2

Re: [PATCH net-next 0/2] Add packet capture support on macvtap device

[David Miller]

From: Vlad Yasevich <vyasevic@redhat.com>
Date: Wed, 11 Dec 2013 13:27:09 -0500

> This series adds support for packet capturing on macvtap device.

This looks fine to me, I'll let it get some more review before I
apply it, thanks.

Re: [PATCH net-next 1/2] macvtap: Add support of packet capture on macvtap device.

[Jason Wang]

On 12/12/2013 02:27 AM, Vlad Yasevich wrote:
> Macvtap device currently doesn not allow a user to capture
> traffic on due to the fact that it steals the packets
> from the network stack before the skb->dev is set correctly
> on the receive side, and that use uses macvlan transmit
> path directly on the send side.  As a result, we never
> get a change to give traffic to the taps while the correct
> device is set in the skb.
>
> This patch makes macvtap device behave almost exaclty like
> macvlan.  On the send side, we switch to using dev_queue_xmit().
> On the receive side, to deliver packets to macvtap, we now
> use netif_rx and dev_forward_skb just like macvlan.  The only
> differnce now is that macvtap has its own rx_handler which is
> attached to the macvtap netdev.  It is here that we now steal
> the packet and provide it to the socket.
>
> As a result, we can now capture traffic on the macvtap device:
>    tcpdump -i macvtap0
>
> It also gives us the abilit to add tc actions to the macvtap
> device and actually utilize different bandwidth management
> queues on output.
>
> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
> ---
>  drivers/net/macvtap.c | 59 ++++++++++++++++++++++++++++-----------------------
>  1 file changed, 32 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> index 4c6f84c..f9847da 100644
> --- a/drivers/net/macvtap.c
> +++ b/drivers/net/macvtap.c
> @@ -70,6 +70,11 @@ static const struct proto_ops macvtap_socket_ops;
>  #define RX_OFFLOADS (NETIF_F_GRO | NETIF_F_LRO)
>  #define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG)
>  
[...]
>  
>  static void macvtap_dellink(struct net_device *dev,
>  			    struct list_head *head)
>  {
> +	netdev_rx_handler_unregister(dev);
>  	macvtap_del_queues(dev);
>  	macvlan_dellink(dev, head);
>  }
> @@ -725,9 +731,8 @@ static ssize_t macvtap_get_user(struct macvtap_queue *q, struct msghdr *m,
>  		skb_shinfo(skb)->tx_flags |= SKBTX_SHARED_FRAG;
>  	}
>  	if (vlan) {
> -		local_bh_disable();
> -		macvlan_start_xmit(skb, vlan->dev);
> -		local_bh_enable();
> +		skb->dev = vlan->dev;
> +		dev_queue_xmit(skb);
>  	} else {
>  		kfree_skb(skb);
>  	}

An issue here: macvlan is a NETIF_F_LLTX device with only one transmit
queue, we may get contention on qdisc lock of macvtap when transmitting
through multiple tx queues.

Re: [PATCH net-next 1/2] macvtap: Add support of packet capture on macvtap device.

[Vlad Yasevich]

On 12/11/2013 10:45 PM, Jason Wang wrote:
> On 12/12/2013 02:27 AM, Vlad Yasevich wrote:
>> Macvtap device currently doesn not allow a user to capture
>> traffic on due to the fact that it steals the packets
>> from the network stack before the skb->dev is set correctly
>> on the receive side, and that use uses macvlan transmit
>> path directly on the send side.  As a result, we never
>> get a change to give traffic to the taps while the correct
>> device is set in the skb.
>>
>> This patch makes macvtap device behave almost exaclty like
>> macvlan.  On the send side, we switch to using dev_queue_xmit().
>> On the receive side, to deliver packets to macvtap, we now
>> use netif_rx and dev_forward_skb just like macvlan.  The only
>> differnce now is that macvtap has its own rx_handler which is
>> attached to the macvtap netdev.  It is here that we now steal
>> the packet and provide it to the socket.
>>
>> As a result, we can now capture traffic on the macvtap device:
>>    tcpdump -i macvtap0
>>
>> It also gives us the abilit to add tc actions to the macvtap
>> device and actually utilize different bandwidth management
>> queues on output.
>>
>> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
>> ---
>>  drivers/net/macvtap.c | 59 ++++++++++++++++++++++++++++-----------------------
>>  1 file changed, 32 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
>> index 4c6f84c..f9847da 100644
>> --- a/drivers/net/macvtap.c
>> +++ b/drivers/net/macvtap.c
>> @@ -70,6 +70,11 @@ static const struct proto_ops macvtap_socket_ops;
>>  #define RX_OFFLOADS (NETIF_F_GRO | NETIF_F_LRO)
>>  #define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG)
>>  
> [...]
>>  
>>  static void macvtap_dellink(struct net_device *dev,
>>  			    struct list_head *head)
>>  {
>> +	netdev_rx_handler_unregister(dev);
>>  	macvtap_del_queues(dev);
>>  	macvlan_dellink(dev, head);
>>  }
>> @@ -725,9 +731,8 @@ static ssize_t macvtap_get_user(struct macvtap_queue *q, struct msghdr *m,
>>  		skb_shinfo(skb)->tx_flags |= SKBTX_SHARED_FRAG;
>>  	}
>>  	if (vlan) {
>> -		local_bh_disable();
>> -		macvlan_start_xmit(skb, vlan->dev);
>> -		local_bh_enable();
>> +		skb->dev = vlan->dev;
>> +		dev_queue_xmit(skb);
>>  	} else {
>>  		kfree_skb(skb);
>>  	}
> 
> An issue here: macvlan is a NETIF_F_LLTX device with only one transmit
> queue, we may get contention on qdisc lock of macvtap when transmitting
> through multiple tx queues.

Hmm... Yes, it looks like we could.  I'll can change this to
    dev_start_hard_xmit(skb, vlan->dev, NULL, NULL);
for now.

To use dev_queue_xmit(), we'd need to expose the macvtap queues
as real device queues (similar to what we do with tap).  Would this
something we would to do.

I could see a desire to do attach qdiscs to macvtap device itself.
Right not that's not really possible.

Thanks
-vlad
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH net-next 0/2] Add packet capture support on macvtap device

[David Miller]

From: Vlad Yasevich <vyasevic@redhat.com>
Date: Wed, 11 Dec 2013 13:27:09 -0500

> Change from RFC:
>   - moved to the rx_handler approach.

Eric's feedback about contention is legitimate, but I think you can
deal with this in follow-on patches, so I've applied this series to
net-next.

Thanks!