If you simply want a faster datapath implementation, you may want to consider just optimizing the kernel datapath code using OCTEON SDK APIs.
As you may already know, most of the SE API are ported the kernel as the base APIs for OCTEON NIC driver. This approach will allow you to speed up datapath performance by taking advantage of the OCTEON packet parsing and handling capabilities. Another benefit of this approach is that you can leave user land code unchanged, so can be simpler to implement. A more ambitious attempt can be to port the openvswitch, (userland + datapath) to userland SE. Having both datapath and userland running in the same address space, you may achieve a much higher flow set up rate (cutting out the netlink layer). By taking advantage of the OCTEON hardware tags, you may end up with an implementation that linearly scale up the performance, taking full advantage of the multi-core capabilities. If you don't mind, please share your final design choice. On Fri, Mar 8, 2013 at 8:59 AM, Justin Pettit <jpet...@nicira.com> wrote: > 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 >
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
