Yep, fair enough. After I have implemented the code in the datapath where should I be looking to extend the utilties to manage it?
Joseph. On 3 October 2011 07:12, Jesse Gross <[email protected]> wrote: > On Oct 2, 2011 4:44 AM, "Joseph Glanville" < > [email protected]> wrote: > > > > Hi, > > > > I am exploring creating a new vport type for a zeroconf virtual network > (similar to a multicast GRE tunnel) > > So far I have reviewed most of the kernel module code and have worked out > how to create a new vport (adding to vport.c struct, defining vport in > vport.h and creating vport-newport.c) but when reviewing vport-gre.c I > noticed tunnel.c/.h which seems to be all of the IP resolution, transmission > stuff etc. > > > > My new vport will probably be using Infinband ibverbs rather than IP as > the transport network for tunneled packets. > > Would it be better to extend tunnel.c to handle native Infinband and > define a new protocol IB_<type> in tunnel.h or just build everything into > vport-newport.c? > > I wouldn't just dump a bunch of Infiband stuff in tunnel.c since it's > already overgrown. At some point it will need to be split apart for IPv6 > into v4, v6, and common code. Maybe the time for that is now and Infiniband > can be one of those categories. It depends on how much common code there > is. If it's completely different then maybe it makes sense to keep it > contained in the new vport. > -- * Founder | Director | VP Research Orion Virtualisation Solutions* | www.orionvm.com.au | Phone: 1300 56 99 52 | Mobile: 0428 754 846
_______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
