Eric Dumazet 93f154b594 net: release dst entry in dev_hard_start_xmit()
One point of contention in high network loads is the dst_release() performed
when a transmited skb is freed. This is because NIC tx completion calls
dev_kree_skb() long after original call to dev_queue_xmit(skb).

CPU cache is cold and the atomic op in dst_release() stalls. On SMP, this is
quite visible if one CPU is 100% handling softirqs for a network device,
since dst_clone() is done by other cpus, involving cache line ping pongs.

It seems right place to release dst is in dev_hard_start_xmit(), for most
devices but ones that are virtual, and some exceptions.

David Miller suggested to define a new device flag, set in alloc_netdev_mq()
(so that most devices set it at init time), and carefuly unset in devices
which dont want a NULL skb->dst in their ndo_start_xmit().

List of devices that must clear this flag is :

- loopback device, because it calls netif_rx() and quoting Patrick :
    "ip_route_input() doesn't accept loopback addresses, so loopback packets
     already need to have a dst_entry attached."
- appletalk/ipddp.c : needs skb->dst in its xmit function

- And all devices that call again dev_queue_xmit() from their xmit function
(as some classifiers need skb->dst) : bonding, vlan, macvlan, eql, ifb, hdlc_fr

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-18 22:19:19 -07:00
..
2009-04-07 10:23:34 +01:00
2009-03-18 19:45:11 -07:00
2009-03-05 14:39:32 -05:00
2009-02-12 09:40:14 +11:00
2009-04-01 08:59:23 -07:00
2009-04-01 08:59:23 -07:00
2009-05-02 15:36:10 -07:00
2009-04-22 08:35:10 +02:00
2009-04-23 10:06:35 +01:00
2009-04-03 14:53:32 -07:00
2009-03-27 14:43:59 -04:00
2009-03-01 00:19:35 -08:00
2009-04-03 14:53:32 -07:00
2009-02-10 00:41:26 +01:00
2009-03-16 08:32:27 -06:00
2009-02-18 15:37:56 -08:00
2009-03-30 15:14:53 +02:00
2009-04-03 09:48:29 -07:00
2009-04-08 14:13:03 +02:00
2009-04-02 19:04:53 -07:00
2009-05-18 22:11:22 -07:00
2009-02-11 15:27:15 +11:00
2009-02-02 21:40:58 +05:30
2009-04-13 15:04:29 -07:00
2009-04-21 13:41:48 -07:00
2009-04-21 13:41:48 -07:00
2009-01-30 23:58:41 +05:30
2009-01-30 23:59:44 +05:30
2009-01-31 00:00:06 +05:30
2009-05-09 10:49:41 -04:00
2009-04-06 16:06:26 +01:00
2009-04-01 08:59:17 -07:00
2009-04-07 08:12:38 +02:00
2009-04-29 17:32:35 -07:00
2009-01-31 00:00:35 +05:30
2009-04-02 19:04:48 -07:00
2009-03-26 10:56:35 -07:00
2009-01-31 00:01:11 +05:30
2009-03-20 10:48:14 -07:00
2009-03-15 19:59:13 -07:00
2009-04-03 17:41:23 -07:00
2009-04-01 13:28:15 -04:00
2009-04-03 17:41:12 -07:00
2009-03-10 20:33:18 -04:00
2009-04-30 15:32:11 +00:00
2009-04-01 08:59:13 -07:00
2009-04-01 08:59:13 -07:00
2009-01-31 00:02:54 +05:30
2009-01-31 00:03:40 +05:30
2009-04-24 08:54:21 +02:00
2009-04-01 08:59:13 -07:00
2009-03-13 16:09:12 -07:00
2009-03-30 15:22:01 +02:00
2009-03-26 02:18:35 +01:00
2009-01-31 00:05:59 +05:30
2009-02-26 23:42:11 -08:00
2009-03-30 14:28:58 -07:00
2009-04-22 16:54:27 -04:00
2009-05-09 10:49:41 -04:00
2009-04-01 08:59:24 -07:00
2009-02-16 00:03:10 -08:00
2009-04-08 14:33:38 -07:00
2009-02-27 16:53:50 +09:00
2009-04-13 15:04:29 -07:00
2009-01-31 00:06:33 +05:30
2009-05-18 22:11:22 -07:00
2009-04-03 12:23:06 +02:00
2009-02-20 17:57:48 -08:00
2009-04-21 19:40:00 -07:00
2009-04-03 12:23:06 +02:00
2009-04-27 02:45:02 -07:00
2009-03-27 12:18:56 -04:00
2009-01-31 00:07:00 +05:30
2009-04-01 08:59:15 -07:00
2009-04-02 19:05:01 -07:00
2009-02-18 15:37:53 -08:00
2009-02-03 11:23:12 +11:00
2009-03-26 18:14:21 +01:00
2009-04-17 10:50:27 -07:00