macvlan: optimizing the receive path?

[Jason Baron <jbaron@akamai.com>]

Hi,

I was just wondering why the netif_rx(skb) call in macvlan_handle_frame()
was necessary? IE:

macvlan_handle_frame()
{
       ........

        skb->dev = dev;
        skb->pkt_type = PACKET_HOST;

****>ret = netif_rx(skb);

out:
        macvlan_count_rx(vlan, len, ret == NET_RX_SUCCESS, 0);
        return RX_HANDLER_CONSUMED;
}


I think the point of going through netif_rx() is to ensure that we throttle
incoming packets, but hasn't that already been accomplished in this path?
That is if the packets are arriving from the physical NIC, we've already
throttled them by this point. Otherwise, if they are coming via
macvlan_queue_xmit(), it calls either 'dev_forward_skb()', which ends
up calling netif_rx_internal(), or else in broadcast mode there is
to be throttling via macvlan_broadcast_enqueue().

So I suspect there is a code path that I am missing but the netif_rx() call in
question essentially re-queues packets coming from off the box. I've tried the
simple patch below to optimize this path, and obviously performs a lot better
in my limited testing.

Thanks,

-Jason

--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -321,8 +321,8 @@ static rx_handler_result_t macvlan_handle_frame(struct sk_buff **pskb)
        skb->dev = dev;
        skb->pkt_type = PACKET_HOST;
 
-       ret = netif_rx(skb);
-
+      macvlan_count_rx(vlan, len, true, 0);
+      return RX_HANDLER_ANOTHER;
 out:
        macvlan_count_rx(vlan, len, ret == NET_RX_SUCCESS, 0);
        return RX_HANDLER_CONSUMED;