Yes, the first option will be easier to implement. For the second option, yes you are right. Implementing a dpif provider as Justin suggested is also be a very good choice. Really depends on your design goals.
On Mon, Mar 11, 2013 at 12:54 AM, 王国栋 <martin23...@gmail.com> wrote: > 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
