From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Declan Doherty <declan.doherty@intel.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v3 0/4] LACP control packet filtering acceleration
Date: Wed, 5 Jul 2017 12:35:39 +0100 [thread overview]
Message-ID: <b60ec965-b15a-2977-3029-e0cf9879a97e@intel.com> (raw)
In-Reply-To: <20170704164627.324-1-declan.doherty@intel.com>
On 7/4/2017 5:46 PM, Declan Doherty wrote:
> 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.
>
> V3:
> - Split hw filtering patch into 3 patches:
> - fix for calculating maximum number of tx/rx queues of bonding device
> - enable use of ptype hint for filtering of control plane packets in
> default enablement
> - enablement of dedicated queues for LACP control packet filtering.
>
> Declan Doherty (1):
> net/bond: calculate number of bonding tx/rx queues
>
> Tomasz Kulasek (3):
> net/bond: use ptype flags for LACP rx filtering
> net/bond: dedicated hw queues for LACP control traffic
> app/test-pmd: add cmd for dedicated LACP rx/tx queues
Series applied to dpdk-next-net/master, thanks.
(minor updates, mentioned in mail thread, done while applying.)
prev parent reply other threads:[~2017-07-05 11:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-27 11:27 [dpdk-dev] [PATCH 0/2] LACP control packet filtering offload 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 ` [dpdk-dev] [PATCH v2 0/2] LACP control packet filtering offload Tomasz Kulasek
2017-06-29 16:20 ` [dpdk-dev] [PATCH v2 1/2] " 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 ` Ferruh Yigit [this message]
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=b60ec965-b15a-2977-3029-e0cf9879a97e@intel.com \
--to=ferruh.yigit@intel.com \
--cc=declan.doherty@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).