On 10/09/18 17:46, Eric Dumazet wrote: > > > On 10/09/2018 03:48 PM, Florian Fainelli wrote: >> This is based on Stephen's v4.14 patches, with the necessary merge >> conflicts, and the lack of timer_setup() on the 4.9 baseline. >> >> Perf results on a gigabit capable system, before and after are below. >> >> Series can also be found here: >> >> https://github.com/ffainelli/linux/commits/fragment-stack-v4.9 >> >> >> PerfTop: 457 irqs/sec kernel:74.4% exact: 0.0% [4000Hz cycles], (all, 4 CPUs) >> ------------------------------------------------------------------------------- >> >> 29.62% [kernel] [k] ip_defrag >> 6.57% [kernel] [k] arch_cpu_idle >> 1.72% [kernel] [k] v7_dma_inv_range >> 1.68% [kernel] [k] __netif_receive_skb_core >> 1.43% [kernel] [k] fib_table_lookup >> 1.30% [kernel] [k] finish_task_switch >> 1.08% [kernel] [k] ip_rcv >> 1.01% [kernel] [k] skb_release_data >> 0.99% [kernel] [k] __slab_free >> 0.96% [kernel] [k] bcm_sysport_poll >> 0.88% [kernel] [k] __netdev_alloc_skb >> 0.87% [kernel] [k] tick_nohz_idle_enter >> 0.86% [kernel] [k] dev_gro_receive >> 0.85% [kernel] [k] _raw_spin_unlock_irqrestore >> 0.84% [kernel] [k] __memzero >> 0.74% [kernel] [k] tick_nohz_idle_exit >> 0.73% ld-2.24.so [.] do_lookup_x >> 0.66% [kernel] [k] kmem_cache_free >> 0.66% [kernel] [k] bcm_sysport_rx_refill >> 0.65% [kernel] [k] eth_type_trans >> >> >> After patching: >> >> PerfTop: 170 irqs/sec kernel:86.5% exact: 0.0% [4000Hz cycles], (all, 4 CPUs) >> ------------------------------------------------------------------------------- >> >> 7.79% [kernel] [k] arch_cpu_idle >> 5.14% [kernel] [k] v7_dma_inv_range >> 4.20% [kernel] [k] ip_defrag >> 3.89% [kernel] [k] __netif_receive_skb_core >> 3.65% [kernel] [k] fib_table_lookup >> 2.16% [kernel] [k] finish_task_switch >> 1.93% [kernel] [k] _raw_spin_unlock_irqrestore >> 1.90% [kernel] [k] ip_rcv >> 1.84% [kernel] [k] bcm_sysport_poll >> 1.83% [kernel] [k] __memzero >> 1.65% [kernel] [k] __netdev_alloc_skb >> 1.60% [kernel] [k] __slab_free >> 1.49% [kernel] [k] __do_softirq >> 1.49% [kernel] [k] bcm_sysport_rx_refill >> 1.31% [kernel] [k] dma_cache_maint_page >> 1.25% [kernel] [k] tick_nohz_idle_enter >> 1.24% [kernel] [k] ip_route_input_noref >> 1.17% [kernel] [k] eth_type_trans >> 1.06% [kernel] [k] fib_validate_source >> 1.03% [kernel] [k] inet_frag_find >> >> Dan Carpenter (1): >> ipv4: frags: precedence bug in ip_expire() >> >> Eric Dumazet (22): >> inet: frags: change inet_frags_init_net() return value >> inet: frags: add a pointer to struct netns_frags >> inet: frags: refactor ipfrag_init() >> inet: frags: refactor ipv6_frag_init() >> inet: frags: refactor lowpan_net_frag_init() >> ipv6: export ip6 fragments sysctl to unprivileged users >> rhashtable: add schedule points >> inet: frags: use rhashtables for reassembly units >> inet: frags: remove some helpers >> inet: frags: get rif of inet_frag_evicting() >> inet: frags: remove inet_frag_maybe_warn_overflow() >> inet: frags: break the 2GB limit for frags storage >> inet: frags: do not clone skb in ip_expire() >> ipv6: frags: rewrite ip6_expire_frag_queue() >> rhashtable: reorganize struct rhashtable layout >> inet: frags: reorganize struct netns_frags >> inet: frags: get rid of ipfrag_skb_cb/FRAG_CB >> inet: frags: fix ip6frag_low_thresh boundary >> net: speed up skb_rbtree_purge() >> net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends >> net: add rb_to_skb() and other rb tree helpers >> net: sk_buff rbnode reorg >> >> Florian Westphal (1): >> ipv6: defrag: drop non-last frags smaller than min mtu >> >> Peter Oskolkov (4): >> ip: discard IPv4 datagrams with overlapping segments. >> net: modify skb_rbtree_purge to return the truesize of all purged >> skbs. >> ip: add helpers to process in-order fragments faster. >> ip: process in-order fragments efficiently >> >> Taehee Yoo (1): >> ip: frags: fix crash in ip_do_fragment() >> > > Strange, I do not see "ip: use rb trees for IP frag queue." in this list ? And it was not in Stephen's backport to 4.14 either, wait, looks like it was somehow squashed into "net: sk_buff rbnode reorg". Stephen, was there a reason for that? Let me go back and add bffa72cf7f9df842f0016ba03586039296b4caaf as well as eeea10b83a139451130df1594f26710c8fa390c8 to the rebase todo and see how things go from there. Thanks for taking a look. -- Florian
