i think the first option may be implemented more easily, in which i just implement the datapath kernel module. and in the second option, do you means that the whole project can be ported to SE mode(including ofproto and vswitch)?
2013/3/10 Andy Zhou <az...@nicira.com> > 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
