Using SE, I would imagine you'd implement a datapath there. In the Linux core running ovs-vswitchd, I would imagine you'd implement a dpif provider that that spoke to the datapaths running in your simple executive cores.
--Justin On Mar 8, 2013, at 12:16 AM, 王国栋 <martin23...@gmail.com> wrote: > In the SE mode, i must implement the datapath module, dpif provider and dpif > as showed in the graph without other module changes, is this right? > right now i'm on the stage of doing some research and experiments, i prepare > to accelerate OVS. then, maybe used in campus network in future. what i want > to prove is just the feasibility right now. > thanks to your answer. > > 2013/3/8 Justin Pettit <jpet...@nicira.com> > Please keep this on the list. > > I'm somewhat familiar with Cavium's platforms. One option would be to bring > up the cores in Linux, and I think you could run the kernel module > essentially unchanged. Another option, which would be a lot more work but > would almost certainly be faster, is to port dpif to their simple executive > and run the userspace portion on a core running Linux. > > I've heard rumors that Cavium ported OVS to their platform, so it may be > worth contacting your rep, too. > > What are you looking to do with this port? What solution are you looking to > provide? > > --Justin > > > On Mar 7, 2013, at 11:33 PM, 王国栋 <martin23...@gmail.com> wrote: > > > i use the Cavium NP and the kernel is linux2.6. is that means if i do not > > have the TCAM, i only can accelerate the exact-match procedure through the > > platform? > > do the datapath kernel module need to change or something while > > porting,give me some suggestions please. > > thanks again! > > > > 2013/3/8 Justin Pettit <jpet...@nicira.com> > > What operating system and platform are you porting it to? The ofproto > > provider pushes flows that have wildcards, and are very similar to OpenFlow > > flows. The dpif provider only pushes exact-match flows. If you have > > access to something like a TCAM that supports priorities and wildcards, > > then implementing an ofproto provider would be the way to go. If this is > > pure software, then you probably want to implement a dpif, since you can do > > the flow lookups with a hash function, which is much faster in software. > > Most of this should be explained in the PORTING file, so you may want to > > take another look at it. > > > > --Justin > > > > > > On Mar 7, 2013, at 11:09 PM, 王国栋 <martin23...@gmail.com> wrote: > > > > > i have some question about PORTING file. there is a graph in this file as > > > follow: > > > <image.png> > > > now i am willing to port the source code to a network processor ,which is > > > MIPS arch. my goal is implement the kernel module in the platform.but i > > > still cannot figure out a clear procedure about it. which part should i > > > change? and the difference between ofproto provider and dpif provider is > > > the challenge, can you tell me about it? > > > thank you in advance! > > > > > > regards, > > > > > > martin > > > _______________________________________________ > > > dev mailing list > > > dev@openvswitch.org > > > http://openvswitch.org/mailman/listinfo/dev > > > > > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
