[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