The corresponding userspace code is in lib/netdev-vport.c. There shouldn't be much to do there, mostly just making it aware of the new tunnel type. On Oct 2, 2011 1:27 PM, "Joseph Glanville" <[email protected]> wrote: > 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
