From: Tomasz Kulasek <tomaszx.kulasek@intel.com>
To: dev@dpdk.org
Subject: [dpdk-dev] [PATCH v2 0/2] LACP control packet filtering offload
Date: Thu, 29 Jun 2017 18:20:20 +0200 [thread overview]
Message-ID: <20170629162022.9984-1-tomaszx.kulasek@intel.com> (raw)
In-Reply-To: <1495884464-3548-1-git-send-email-tomaszx.kulasek@intel.com>
1. Overview
Packet processing in the current path for bonding in mode 4, requires
parse all packets in the fast path, to classify and process LACP
packets.
The idea of performance improvement is to use hardware offloads to
improve packet classification.
2. Scope of work
a) Optimization of software LACP packet classification by using
packet_type metadata to eliminate the requirement of parsing each
packet in the received burst.
b) Implementation of classification mechanism using flow director to
redirect LACP packets to the dedicated queue (not visible by
application).
- Filter pattern choosing (not all filters are supported by all
devices),
- Changing processing path to speed up non-LACP packets
processing,
- Handle LACP packets from dedicated Rx queue and send to the
dedicated Tx queue,
c) Creation of fallback mechanism allowing to select the most
preferable method of processing:
- Flow director,
- Packet type metadata,
- Software parsing,
3. Implementation
3.1. Packet type
The packet_type approach would result in a performance improvement
as packets data would no longer be required to be read, but with this
approach the bonded driver would still need to look at the mbuf of
each packet thereby having an impact on the achievable Rx
performance.
There's not packet_type value describing LACP packets directly.
However, it can be used to limit number of packets required to be
parsed, e.g. if packet_type indicates >L2 packets.
It should improve performance while well-known non-LACP packets can
be skipped without the need to look up into its data.
3.2. Flow director
Using rte_flow API and pattern on ethernet type of packet (0x8809),
we can configure flow director to redirect slow packets to separated
queue.
An independent Rx queues for LACP would remove the requirement to
filter all ingress traffic in sw which should result in a performance
increase. Other queues stay untouched and processing of packets on
the fast path will be reduced to simple packet collecting from
slaves.
Separated Tx queue for LACP daemon allows to send LACP responses
immediately, without interfering into Tx fast path.
RECEIVE
.---------------.
| Slave 0 |
| .------. |
| Fd | Rxq | |
Rx ======o==>| |==============.
| | +======+ | | .---------------.
| `-->| LACP |--------. | | Bonding |
| `------' | | | | .------. |
`---------------' | | | | | |
| >============>| |=======> Rx
.---------------. | | | +======+ |
| Slave 1 | | | | | XXXX | |
| .------. | | | | `------' |
| Fd | Rxq | | | | `---------------'
Rx ======o==>| |==============' .-----------.
| | +======+ | | / \
| `-->| LACP |--------+----------->+ LACP DAEMON |
| `------' | Tx <---\ /
`---------------' `-----------'
All slow packets received by slaves in bonding are redirected to the
separated queue using flow director. Other packets are collected from
slaves and exposed to the application with Rx burst on bonded device.
TRANSMIT
.---------------.
| Slave 0 |
| .------. |
| | | |
Tx <=====+===| |<=============.
| | |------| | | .---------------.
| `---| LACP |<-------. | | Bonding |
| `------' | | | | .------. |
`---------------' | | | | | |
| +<============| |<====== Tx
.---------------. | | | +======+ |
| Slave 1 | | | | | XXXX | |
| .------. | | | | `------' |
| | | | | | `---------------'
Tx <=====+===| |<=============' Rx .-----------.
| | |------| | | `-->/ \
| `---| LACP |<-------+------------+ LACP DAEMON |
| `------' | \ /
`---------------' `-----------'
On transmit, packets are propagated on the slaves. While we have
separated Tx queue for LACP responses, it can be sent regardless of
the fast path.
LACP DAEMON
In this mode whole slow packets are handled in LACP DAEMON.
Tomasz Kulasek (2):
LACP control packet filtering offload
test-pmd: add set bonding slow_queue hw/sw
app/test-pmd/cmdline.c | 75 ++++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 8 +
drivers/net/bonding/rte_eth_bond_8023ad.c | 160 ++++++--
drivers/net/bonding/rte_eth_bond_8023ad.h | 35 ++
drivers/net/bonding/rte_eth_bond_8023ad_private.h | 24 ++
drivers/net/bonding/rte_eth_bond_pmd.c | 424 +++++++++++++++++++++-
drivers/net/bonding/rte_eth_bond_version.map | 9 +
7 files changed, 693 insertions(+), 42 deletions(-)
--
1.9.1
next prev parent reply other threads:[~2017-06-29 16:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-27 11:27 [dpdk-dev] [PATCH " Tomasz Kulasek
2017-05-27 11:27 ` [dpdk-dev] [PATCH 1/2] " Tomasz Kulasek
2017-05-29 8:10 ` Adrien Mazarguil
2017-06-29 9:18 ` Declan Doherty
2017-05-27 11:27 ` [dpdk-dev] [PATCH 2/2] test-pmd: add set bonding slow_queue hw/sw Tomasz Kulasek
2017-06-29 16:20 ` Tomasz Kulasek [this message]
2017-06-29 16:20 ` [dpdk-dev] [PATCH v2 1/2] LACP control packet filtering offload Tomasz Kulasek
2017-06-29 16:20 ` [dpdk-dev] [PATCH v2 2/2] test-pmd: add set bonding slow_queue hw/sw Tomasz Kulasek
2017-07-04 16:46 ` [dpdk-dev] [PATCH v3 0/4] LACP control packet filtering acceleration Declan Doherty
2017-07-04 16:46 ` [dpdk-dev] [PATCH v3 1/4] net/bond: calculate number of bonding tx/rx queues Declan Doherty
2017-07-04 16:46 ` [dpdk-dev] [PATCH v3 2/4] net/bond: use ptype flags for LACP rx filtering Declan Doherty
2017-07-04 19:54 ` Declan Doherty
2017-07-04 16:46 ` [dpdk-dev] [PATCH v3 3/4] net/bond: dedicated hw queues for LACP control traffic Declan Doherty
2017-07-04 19:55 ` Declan Doherty
2017-07-05 11:19 ` Ferruh Yigit
2017-07-05 11:33 ` Ferruh Yigit
2017-12-13 8:16 ` linhaifeng
2017-12-13 12:41 ` Kulasek, TomaszX
2017-07-04 16:46 ` [dpdk-dev] [PATCH v3 4/4] app/test-pmd: add cmd for dedicated LACP rx/tx queues Declan Doherty
2017-07-04 19:56 ` Declan Doherty
2017-07-05 11:33 ` Ferruh Yigit
2017-07-05 11:35 ` [dpdk-dev] [PATCH v3 0/4] LACP control packet filtering acceleration Ferruh Yigit
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=20170629162022.9984-1-tomaszx.kulasek@intel.com \
--to=tomaszx.kulasek@intel.com \
--cc=dev@dpdk.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).