[ovs-dev] OVS porting

[Abhijit Bhadra]

So I am trying to write our own ofproto provider. And we tend to allocate and initialize resources in the beginning itself when the switch is coming up. So in that case, if during my initialization for my version of openflow, if I call ofproto_class_register with my ofproto class, and call ofproto_create with my device_name as name and type as NULL, will that be sufficient? I am further assuming I don't need to call init from ofproto class handler. Is that sufficient or do I need to call ofproto_init somewhere? And if yes, where and how?
Abhijit

-----Original Message-----
From: Ben Pfaff [mailto:blp at nicira.com] 
Sent: Friday, February 27, 2015 12:39 AM
To: Abhijit Bhadra
Cc: dev at openvswitch.org
Subject: Re: [ovs-dev] OVS porting

There's a 38-line, 2,212-character comment describing packet_out.
Please read it, then tell me what needs elaboration.

On Thu, Feb 26, 2015 at 01:42:48PM +0000, Abhijit Bhadra wrote:
> And what is the significance of packet_out in ofproto_class?
> Regards,
> Abhijit
> 
> 
> 
> 
> -----Original Message-----
> From: Abhijit Bhadra 
> Sent: Thursday, February 26, 2015 6:32 PM
> To: 'Ben Pfaff'
> Cc: dev at openvswitch.org
> Subject: RE: [ovs-dev] OVS porting
> 
> If I am trying to implement my own ofproto, where do I need to store the interface information in OVS, which structure, like interface index and name?
> Regards,
> Abhijit
> 
> 
> 
> -----Original Message-----
> From: Ben Pfaff [mailto:blp at nicira.com] 
> Sent: Wednesday, February 18, 2015 1:01 AM
> To: Abhijit Bhadra
> Cc: dev at openvswitch.org
> Subject: Re: [ovs-dev] OVS porting
> 
> Please don't drop the list.
> 
> That seems wrong.  ofproto internally calls those functions as
> necessary.  You should only need to implement the functions in struct
> ofproto_class to interface with your hardware.
> 
> On Tue, Feb 17, 2015 at 01:45:30PM +0000, Abhijit Bhadra wrote:
> > Adding further,
> > I believe I can take some help from ofp-util.c, here is see routines like ofputil_match_from_ofp10_match, I believe that is a reference for mapping my internal flows to OVS flows, similarly ofputil_match_to_ofp10_match is to map OVS flows to my internal flows. Is that correct or is it the other way? Thanks for your time and patience.
> > Regards,
> > Abhijit
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From: Abhijit Bhadra 
> > Sent: Tuesday, February 17, 2015 1:34 PM
> > To: 'Ben Pfaff'
> > Subject: RE: [ovs-dev] OVS porting
> > 
> > Ok,
> > I understand that. Any pointer on how to implement an ofproto driver, I have my own switching software/tables/Ethernet driver to do the needful. Only thing I need to know is how to create the connect between ofproto and the underlying driver. Is there any sample or reference I can look into?
> > Regards,
> > Abhijit
> > 
> > 
> > 
> > -----Original Message-----
> > From: Ben Pfaff [mailto:blp at nicira.com] 
> > Sent: Monday, February 16, 2015 11:28 PM
> > To: Abhijit Bhadra
> > Cc: dev at openvswitch.org
> > Subject: Re: [ovs-dev] OVS porting
> > 
> > On Mon, Feb 16, 2015 at 09:40:49AM +0000, Abhijit Bhadra wrote:
> > > I am trying to port the latest OVS into our code. We used to run a
> > > much earlier version of code which used WDP(wildcard), now I think it
> > > needs to be replaced by ofproto class. I would like get some pointers
> > > regarding that.
> > >
> > > Like for example, what should be a suitable replacement for
> > > wdp_flow_put struct etc.? Is there any porting guide regarding this?
> > 
> > wdp.  Wow.  The last commit to that branch was almost 4 years ago, and
> > that was only for a merge and a couple of bug fixes; the bulk of the
> > code was written about 5 years ago.  So this question is something like
> > "I've got a driver for Linux 2.6.34, do you have a porting guide to get
> > it up to 3.19?"
> > 
> > The simple answer is "no".  The slightly longer answer is that the new
> > ofproto interface does more work in common code, so probably a good
> > place to start is by deleting code from the wdp implementation that is
> > no longer needed.