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.)
