From: Jesper Dangaard Brouer <jbrouer@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>,
netdev@vger.kernel.org, yoshfuji@linux-ipv6.org
Subject: Re: RFC crap-patch [PATCH] net: Per CPU separate frag mem accounting
Date: Thu, 14 Mar 2013 09:59:21 +0100 [thread overview]
Message-ID: <1363251561.14913.33.camel@localhost> (raw)
In-Reply-To: <1363245955.14913.21.camel@localhost>
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
next prev parent reply other threads:[~2013-03-14 8:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20130308221647.5312.33631.stgit@dragon>
[not found] ` <20130308221744.5312.14924.stgit@dragon>
2013-03-14 7:25 ` RFC crap-patch [PATCH] net: Per CPU separate frag mem accounting Jesper Dangaard Brouer
2013-03-14 8:59 ` Jesper Dangaard Brouer [this message]
2013-03-14 20:59 ` Ben Hutchings
2013-03-14 23:12 ` Hannes Frederic Sowa
2013-03-14 23:39 ` Ben Hutchings
2013-03-15 20:09 ` Hannes Frederic Sowa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1363251561.14913.33.camel@localhost \
--to=jbrouer@redhat.com \
--cc=eric.dumazet@gmail.com \
--cc=hannes@stressinduktion.org \
--cc=netdev@vger.kernel.org \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).