[ovs-dev] Creating a new tunnel/vport type.

Joseph Glanville joseph.glanville at orionvm.com.au
Sun Oct 2 20:27:55 UTC 2011


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 <jesse at nicira.com> wrote:

> On Oct 2, 2011 4:44 AM, "Joseph Glanville" <
> joseph.glanville at orionvm.com.au> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20111003/12c3c334/attachment-0003.html>


More information about the dev mailing list