datapath: Don't orphan packets in dp_dev transmit path.
authorBen Pfaff <blp@nicira.com>
Mon, 13 Jul 2009 16:41:26 +0000 (09:41 -0700)
committerBen Pfaff <blp@nicira.com>
Mon, 13 Jul 2009 18:21:50 +0000 (11:21 -0700)
Before commit 72ca14c1 "datapath: Fix race against workqueue in dp_dev and
simplify code," the dp_dev network device had a device queue, and we would
orphan packets before sticking them on the queue.  This screwed up socket
accounting a bit, but the effect was limited to the device queue length.

Now, after that commit, the dp_dev device has no device queue, but it still
orphans packets.  This screws up socket accounting a *lot*, because the
effect is now unlimited, since there is no queue to limit it.

The solution is to not orphan packets at all.  There is little need for it
now since packet transmission now happens immediately, not in a workqueue
whose execution may be delayed.

This should fix bug #1519, which tests "netperf -t UDP_STREAM" performance,
finding that an unrealistically high number of UDP packets could be sent
but that none at all were received.  The send rate is due to the orphaning,
the receive rate presumably because at least one out of approx. 65535/1500
= 44 fragments per full packet were dropped in each case.

datapath/dp_dev.c

index 5aa32f0481cbbf58bfa0d9af3c7dfdece6ba40f3..3902a8c5f2eb21e41070eeeb8dd777f63a421b08 100644 (file)
@@ -86,12 +86,6 @@ static int dp_dev_xmit(struct sk_buff *skb, struct net_device *netdev)
        struct dp_dev *dp_dev = dp_dev_priv(netdev);
        struct pcpu_lstats *lb_stats;
 
-       /* By orphaning 'skb' we will screw up socket accounting slightly, but
-        * the effect is limited to the device queue length.  If we don't
-        * do this, then the sk_buff will be destructed eventually, but it is
-        * harder to predict when. */
-       skb_orphan(skb);
-
        /* dp_process_received_packet() needs its own clone. */
        skb = skb_share_check(skb, GFP_ATOMIC);
        if (!skb)