From: Felix Manlunas <felix.manlunas@cavium.com>
To: Tom Herbert <tom@herbertland.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Linux Kernel Network Developers <netdev@vger.kernel.org>,
raghu.vatsavayi@cavium.com, derek.chickles@cavium.com,
satananda.burla@cavium.com,
VSR Burru <veerasenareddy.burru@cavium.com>
Subject: Re: [PATCH v2 net-next] liquidio: improve UDP TX performance
Date: Tue, 21 Feb 2017 22:57:37 -0800 [thread overview]
Message-ID: <20170222065737.GA1201@felix.cavium.com> (raw)
In-Reply-To: <CALx6S35HE=8bwXMy7U=+kOSaP1fBmRjPUKn1neW6O=h38P0K2A@mail.gmail.com>
Tom Herbert <tom@herbertland.com> wrote on Tue [2017-Feb-21 15:27:54 -0800]:
> On Tue, Feb 21, 2017 at 1:09 PM, Felix Manlunas
> <felix.manlunas@cavium.com> wrote:
> > From: VSR Burru <veerasenareddy.burru@cavium.com>
> >
> > Improve UDP TX performance by:
> > * reducing the ring size from 2K to 512
>
> It looks like liquidio supports BQL. Is that not effective here?
Response from our colleague, VSR:
That's right, BQL is not effective here. We reduced the ring size because
there is heavy overhead with dma_map_single every so often. With iommu=on,
dma_map_single in PF Tx data path was taking longer time (~700usec) for
every ~250 packets. Debugged intel_iommu code, and found that PF driver is
utilizing too many static IO virtual address mapping entries (for gather
list entries and info buffers): about 100K entries for two PF's each using
8 rings. Also, finding an empty entry (in rbtree of device domain's iova
mapping in kernel) during Tx path becomes a bottleneck every so often; the
loop to find the empty entry goes through over 40K iterations; this is too
costly and was the major overhead. Overhead is low when this loop quits
quickly.
next prev parent reply other threads:[~2017-02-22 6:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-21 21:09 [PATCH v2 net-next] liquidio: improve UDP TX performance Felix Manlunas
2017-02-21 21:18 ` Rick Jones
2017-02-21 23:27 ` Tom Herbert
2017-02-22 6:57 ` Felix Manlunas [this message]
2017-02-22 13:52 ` Eric Dumazet
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=20170222065737.GA1201@felix.cavium.com \
--to=felix.manlunas@cavium.com \
--cc=davem@davemloft.net \
--cc=derek.chickles@cavium.com \
--cc=netdev@vger.kernel.org \
--cc=raghu.vatsavayi@cavium.com \
--cc=satananda.burla@cavium.com \
--cc=tom@herbertland.com \
--cc=veerasenareddy.burru@cavium.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.