[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <542DB55D.3090601@akamai.com>
Date: Thu, 02 Oct 2014 16:28:13 -0400
From: Jason Baron <jbaron@...mai.com>
To: netdev@...r.kernel.org
CC: kaber@...sh.net
Subject: macvlan: optimizing the receive path?
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;
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists