Hi,
Thanks for the rapid answer.
Following your advice, I went over the porting document ,( hope I understood it
correctly)
Please correct me if I'm wrong:
1. I understand now that I'm expected to implement either "ofproto provider"
(such as ofproto_dpif.c) or a "dpif provider" (such as dpif-linux.c) , not both
2. since my implementation is HW related, implementing "ofproto provider" is a
better approach,
3. Considering that 1 && 2 are correct, how do I remove the "dpif provider"
module in the most elegant way?
Is it enough to stop its registration (just comment out the line:
&dpif_linux_class in the structure below:
static const struct dpif_class *base_dpif_classes[] = {
#ifdef LINUX_DATAPATH
&dpif_linux_class,
#endif
&dpif_netdev_class,
};
Which later on performs:
for (i = 0; i < ARRAY_SIZE(base_dpif_classes); i++) {
dp_register_provider(base_dpif_classes[i]);
}
or do you have another idea?
-----Original Message-----
From: Ben Pfaff [mailto:b...@nicira.com]
Sent: Thursday, July 17, 2014 8:50 PM
To: Eyal Nissim
Cc: discuss@openvswitch.org
Subject: Re: [ovs-discuss] configuring a new flow originated from remote
controller to network processor via vswitchd thread directly
On Thu, Jul 17, 2014 at 12:59:31PM +0000, Eyal Nissim wrote:
> I would like Vswitch to control a network processor, in my case I'd
> like to perform synchronous configuration via vswitchd This means that
> when a remote controller adds a new flow for example, the flow will be
> written by Vswitchd thread to the Network processor (To my
> understanding, according to previous answers in the forum, currently
> the configuration is done only when data packets arrive at the upcall thread)
> Is it logical to perform this mission from "rule_insert" function?
> (ofproto->ofproto_class->rule_insert) , or is there a better place?
We mostly talk about the OVS all-software switch on ovs-discuss, since that's
what most users are using. But if you're actually passing flows along to a
network processor, then you might want to hook in at a higher level, by
implementing an ofproto provider instead of a dpif provider. Please read the
PORTING file at the top level of the source tree to understand the tradeoffs.
This email message and any attachments are intended solely for the use of the
addressees hereof.
This message and any attachments may contain information that is confidential,
privileged and exempt from disclosure under applicable law.
If you are not the intended recipient of this message, you are prohibited from
reading, disclosing, reproducing, distributing, disseminating or otherwise
using this transmission.
If you have received this message in error, please promptly notify the sender
at Ceragon by reply E-mail and immediately delete this message from your system.
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
