Subject: Re: RFC crap-patch [PATCH] net: Per CPU separate frag mem accounting

From: Jesper Dangaard Brouer <[email-masked]>
Date: Thu, 14 Mar 2013 09:59:21 +0100

On Thu, 2013-03-14 at 08:25 +0100, Jesper Dangaard Brouer wrote:
> This is NOT the patch I just mentioned in the other thread, of removing
> the LRU list.  This patch does real per cpu mem acct, and LRU per CPU.
> 
> I get really good performance number with this patch, but I still think
> this might not be the correct solution.

The reason is this depend on fragments entering the same HW queue, some
NICs might not put the first fragment (which have the full header
tuples) and the remaining fragments on the same queue. In which case
this patch will loose its performance gain.

> My current best results, which got applied recently, compared to this
> patch:
>  - Test-type:  Test-20G64K    Test-20G3F  20G64K+DoS   20G3F+DoS
>  - Patch-06:   18486.7 Mbit/s  10723.20     3657.85     4560.64 Mbit/s
>  - curr-best:  19041.0 Mbit/s  12105.20    10160.40    11179.30 Mbit/s

I noticed that this also included some other patches in my stack
 - New patchset-B:
 - PatchB-07: Fix LRU list head multi CPU race
 - PatchB-07:  18731.5 Mbit/s  10721.9      4079.22     5208.73 Mbit/s
 - PatchB-08: Per hash bucket locking
 - PatchB-08:  15959.5 Mbit/s  10968.9      4294.63     6365.16 Mbit/s

As you can see I'm looking into why "PatchB-08" which implement per hash
bucket locking is reducing throughput in Test-20G64K.

> Thus, I have almost solved DoS effect Test-20G3F 12GBit/s -> 11Gbit/s
> under DoS. The 64K+DoS case is not perfect yet, 19Gbit/s -> 11 Gbit/s.
> 
> --Jesper