All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, therbert@google.com,
	hannes@stressinduktion.org, edumazet@google.com,
	jeffrey.t.kirsher@intel.com, rusty@rustcorp.com.au,
	dborkman@redhat.com
Subject: Re: [PATCH 0/2] Get rid of ndo_xmit_flush
Date: Tue, 26 Aug 2014 10:40:28 -0400	[thread overview]
Message-ID: <53FC9C5C.1070200@mojatatu.com> (raw)
In-Reply-To: <20140826121347.0ec7f2ac@redhat.com>

On 08/26/14 06:13, Jesper Dangaard Brouer wrote:
>
> On Tue, 26 Aug 2014 08:28:15 +0200 Jesper Dangaard Brouer <brouer@redhat.com> wrote:
>> On Mon, 25 Aug 2014 16:34:58 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>>
>>> Given Jesper's performance numbers, it's not the way to go.
>>>
>>> Instead, go with a signalling scheme via new boolean skb->xmit_more.
>>
>> I'll do benchmarking based on this new API proposal today.
>
> While establish an accurate baseline for my measurements.  I'm
> starting to see too much variation in my trafgen measurements.
> Meaning that we unfortunately cannot use it to measure variations on
> the nanosec scale.
>
> I'm measuring the packets per sec via "ifpps", and calculating an
> average over the measurements, via the following oneliner:
>
>   $ ifpps -clod eth5 -t 1000 | awk 'BEGIN{txsum=0; rxsum=0; n=0} /[[:digit:]]/ {txsum+=$11;rxsum+=$3;n++; printf "instant rx:%u tx:%u pps n:%u average: rx:%d tx:%d pps\n", $3, $11, n, rxsum/n, txsum/n }'
>
> Below is measurements done on the *same* kerne:
>   - M1: instant tx:1572766 pps n:215 average: tx:1573360 pps (reboot#1)
>   - M2: instant tx:1561930 pps n:173 average: tx:1557064 pps (reboot#2)
>   - M3: instant tx:1562088 pps n:300 average: tx:1559150 pps (reboot#2)
>   - M4: instant tx:1564404 pps n:120 average: tx:1564948 pps (reboot#3)
>
>   M1->M2: +6.65ns
>   M1->M3: +5.79ns
>   M1->M4: +3.42ns
>   M3->M4: -2.38ns
>
> I cannot explain the variations, but some options could be
>   1) how well the SKB is cache-hot cached via kmem_cache
>   2) other interrups on CPU#0 could disturb us
>   3) interactions with scheduler
>   4) interactions with transparent hugepages
>   5) CPU "turbostat" interactions
>

The clock source used in your system may be an issue as well.
I am not sure if that matters these days but it used to be.
I think back then you could pick ACPI, Jiffies etc to use
as a qdisc clock source.

cheers,
jamal

  parent reply	other threads:[~2014-08-26 14:40 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-25 23:34 [PATCH 0/2] Get rid of ndo_xmit_flush David Miller
2014-08-26  6:28 ` Jesper Dangaard Brouer
2014-08-26 10:13   ` Jesper Dangaard Brouer
2014-08-26 12:52     ` Jesper Dangaard Brouer
2014-08-26 16:43       ` Alexander Duyck
2014-08-27  7:48         ` Jesper Dangaard Brouer
2014-08-27  8:37           ` Jesper Dangaard Brouer
2014-08-26 14:40     ` Jamal Hadi Salim [this message]
2014-09-01  0:37     ` Rusty Russell
2014-08-27 12:19 ` Jesper Dangaard Brouer
2014-08-27 20:43   ` David Miller
2014-08-27 12:31 ` Hannes Frederic Sowa
2014-08-27 13:23   ` Eric Dumazet
2014-08-27 13:56     ` Jesper Dangaard Brouer
2014-08-27 14:09       ` Eric Dumazet
2014-08-27 20:48       ` David Miller
2014-08-27 20:46     ` David Miller
2014-08-27 20:45   ` David Miller
2014-08-28  1:42     ` Hannes Frederic Sowa
2014-08-30  3:22       ` David Miller
2014-08-30 10:23         ` Jesper Dangaard Brouer
2014-09-01 20:05         ` Hannes Frederic Sowa
2014-09-01 21:56           ` David Miller
2014-09-01 22:31             ` Hannes Frederic Sowa
2014-09-01 22:35               ` David Miller
2014-08-27 18:28 ` Cong Wang
2014-08-27 19:31   ` Tom Herbert
2014-08-27 20:53     ` David Miller
2014-08-27 20:51   ` David Miller

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=53FC9C5C.1070200@mojatatu.com \
    --to=jhs@mojatatu.com \
    --cc=brouer@redhat.com \
    --cc=davem@davemloft.net \
    --cc=dborkman@redhat.com \
    --cc=edumazet@google.com \
    --cc=hannes@stressinduktion.org \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=therbert@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.