From: Alexander Duyck <alexander.duyck@gmail•com>
To: David Miller <davem@davemloft•net>, netdev@vger•kernel.org
Cc: therbert@google•com, jhs@mojatatu•com,
hannes@stressinduktion•org, edumazet@google•com,
jeffrey.t.kirsher@intel•com, rusty@rustcorp•com.au
Subject: Re: [PATCH 0/3] Basic deferred TX queue flushing infrastructure.
Date: Sat, 23 Aug 2014 16:25:05 -0700 [thread overview]
Message-ID: <53F922D1.70409@gmail.com> (raw)
In-Reply-To: <20140823.132811.751469424156827125.davem@davemloft.net>
On 08/23/2014 01:28 PM, David Miller wrote:
>
> Over time, and specifically and more recently at the Networking
> Workshop during Kernel SUmmit in Chicago, we have discussed the idea
> of having some way to optimize transmits of multiple TX packets at
> a time.
>
> There are several areas of overhead that could be amortized with such
> schemes. One has to do with locking and transactional overhead, the
> other has to do with device specific costs.
>
> This patch set here is more aimed at device specific costs.
>
> Typically a device queues up a packet in the TX queue and then has to
> do something to have the device start processing that new entry.
> Sometimes this is composed of doing an MMIO write to a "tail"
> register, and in other cases it can involve something as expensive as
> a hypervisor call.
The MMIO call isn't an issue until you encounter a locked operation, at
least on x86 architecture. So this often shows up in perf traces as a
hit on the qdisc lock right after completing a transmit. I've seen it
at around 20% of CPU utilization when I was doing routing work with ixgbe.
Thanks,
Alex
next prev parent reply other threads:[~2014-08-23 23:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-23 20:28 [PATCH 0/3] Basic deferred TX queue flushing infrastructure David Miller
2014-08-23 23:25 ` Alexander Duyck [this message]
2014-08-24 12:58 ` Jesper Dangaard Brouer
2014-08-24 3:39 ` Tom Herbert
2014-08-24 4:26 ` David Miller
2014-08-24 4:38 ` David Miller
2014-08-24 14:57 ` Jamal Hadi Salim
2014-08-24 19:08 ` David Miller
2014-08-24 17:37 ` Eric Dumazet
2014-08-24 19:11 ` David Miller
2014-08-25 22:21 ` Cong Wang
2014-08-25 22:31 ` David Miller
2014-08-25 22:37 ` Eric Dumazet
2014-08-25 22:41 ` David Miller
2014-08-25 22:45 ` Jon Maloy
2014-08-25 23:24 ` Vlad Yasevich
2014-09-01 7:40 ` Jesper Dangaard Brouer
2014-09-01 21:40 ` David Miller
2014-08-25 6:10 ` 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=53F922D1.70409@gmail.com \
--to=alexander.duyck@gmail$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=edumazet@google$(echo .)com \
--cc=hannes@stressinduktion$(echo .)org \
--cc=jeffrey.t.kirsher@intel$(echo .)com \
--cc=jhs@mojatatu$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=rusty@rustcorp$(echo .)com.au \
--cc=therbert@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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