-
Notifications
You must be signed in to change notification settings - Fork 136
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Manager to NF Message Passing (#166)
This brings an interface to pass messages from the manager to NFs. Messages are described by the `onvm_nf_msg` struct by having an ONVM manager defined type and abstract data pointer. These messages can be created with the manager function `onvm_nf_send_msg`. Each NF now has a message queue alongside their preexisting Rx and Tx queues. NFs check for messages in their critical path, and can use the `packet_handler` interface, or the interface where they have direct access to their own rings. Commit log: * Implement basic mgr to NF Messaging We want the manager to be able to send messages to NFs. This commit: - Defines a simple message struct (with type, destination, and data) - Creates a mempool/ring for messages to be passed to NFs - Adds an interface for the manage to enqueue a message - nflib maps the ring into its space and can read from it * Use one msg ring per NF It is impossible to use one single message queue with the DPDK rings. One the consumer side, we'd want each NF to "peek" at the head of the queue and only dequeue if it is the recipient of that message. The DPDK ring library doesn't support "peek", and that would approach would also leave the messages vulnerable to denial-of-service by other NFs that never dequeue their messages. Probably not a decision we want to use... Instead, create one ring per NF, like we do TX and RX queues. Each NF can then look up its own ring and use it without fear of inteferance. Plus, we can simply use `rte_ring_count` to see if there are any available messages to be processed. * Read and process messages in nflib * Fix comment, typo fixes * Refactor nflib packet processing loop I did a few things here to make the code simpler: - Typedef'd the pkt_handler function signature - Extracted the packet and message checking code into their own two functions. This means there aren't any confusing semantics with their prior use of continue (e.g. even if there are no packets to process, then we still want to check for messages) * Increase the size of the message mempool This lets us allocate enough msg structs to fill all the NF rings. This should be an excessive amount... * Always inline the new packet processing functions I have them split out for cleanliness, but we can avoid the performance regression of two function calls each packet handler loop by doing this. * Bump msg pool size, add log message on alloc fail
- Loading branch information
1 parent
4557802
commit 125e6dd
Showing
8 changed files
with
250 additions
and
37 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,55 @@ | ||
/********************************************************************* | ||
* openNetVM | ||
* https://sdnfv.github.io | ||
* | ||
* BSD LICENSE | ||
* | ||
* Copyright(c) | ||
* 2015-2016 George Washington University | ||
* 2015-2016 University of California Riverside | ||
* 2010-2014 Intel Corporation | ||
* All rights reserved. | ||
* | ||
* Redistribution and use in source and binary forms, with or without | ||
* modification, are permitted provided that the following conditions | ||
* are met: | ||
* | ||
* * Redistributions of source code must retain the above copyright | ||
* notice, this list of conditions and the following disclaimer. | ||
* * Redistributions in binary form must reproduce the above copyright | ||
* notice, this list of conditions and the following disclaimer in | ||
* the documentation and/or other materials provided with the | ||
* distribution. | ||
* * The name of the author may not be used to endorse or promote | ||
* products derived from this software without specific prior | ||
* written permission. | ||
* | ||
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS | ||
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT | ||
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR | ||
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT | ||
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, | ||
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT | ||
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, | ||
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY | ||
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT | ||
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE | ||
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. | ||
* | ||
* onvm_msg_common.h - Shared structures relating to message passing | ||
between the manager and NFs | ||
********************************************************************/ | ||
|
||
#ifndef _MSG_COMMON_H_ | ||
#define _MSG_COMMON_H_ | ||
|
||
#include <stdint.h> | ||
|
||
#define MSG_NOOP 0 | ||
|
||
struct onvm_nf_msg { | ||
uint8_t msg_type; /* Constant saying what type of message is */ | ||
void *msg_data; /* These should be rte_malloc'd so they're stored in hugepages */ | ||
}; | ||
|
||
#endif |
Oops, something went wrong.