On Tue, Jan 29, 2013 at 01:34:49PM -0500, soaring eagle wrote: > Thanks for the quick response. I agree with your assessment that > Asynchronous seems like the right path for a robust solution. We just > wanted to get some feedback out from folks like you who have several years > of real experience developing controller and openflow agent. > > In your experience developing controllers, have you run into issues like > this where controller getting blocked due to openflow agents being slow. > It's probably not so much of an issue on soft-switches.
I haven't run into it, but I don't develop controllers (only switches) and the Open vSwitch soft switch can handle thousands of new OpenFlow flows per seconds. > Couple of other questions: > - Where is the hard-coded limit of 50 outstanding messages set. If we do > asynchronous and want to avoid blocking, then in the worst case ofproto may > need to have outstanding messages equal to max number of flows. It's at the top of handle_flow_mod__() in ofproto/ofproto.c. > - How much data is stored for each outstanding flow. Trying to understand > how much memory impact of bumping the number of outstanding messages would > be The main cost of an outstanding flow is the flow itself. Tracking the ongoing operations is a small additional cost, probably less than 100 bytes per outstanding operation. There's one "struct ofopgroup" per outstanding flow_mod and one "struct ofoperation" per OpenFlow flow modified by the flow_mod (usually just one). > - We want to use the OF 1.2/1.3 support in OVS. I understand that it is > experimental and there are several key pieces missing like support for > Groups. Do we have a list somewhere which tells if anyone is working on a > particular feature for OF 1.2/1.3 like group support. We don't want to take > on a functionality if someone is already doing the feature. Where I know that someone is working on a feature, the OPENFLOW-1.1+ file at the top of the tree mentions it. If you plan to work on a feature (and contribute it), please let me know so I can add a note there. > Thanks > On Tue, Jan 29, 2013 at 12:59 PM, Ben Pfaff <b...@nicira.com> wrote: > > > On Tue, Jan 29, 2013 at 10:43:02AM -0500, soaring eagle wrote: > > > We are considering porting OVS datapath to a new ASIC hardware platform > > by > > > writing a provider for the hardware. We have few basic design questions > > > that we are looking to get some feedback on: > > > > > > 1) We are trying to decide whether to implement the provider > > > rule->construct, destruct routines synchronously or asynchronously. One > > > hardware flow update generally takes less than 1 ms on single ASIC but > > can > > > take several ms if several ASICs have to be updated and some of the ASICs > > > are not on the same board (stacking/chassis designs) and RPC has to done > > to > > > update the remote ASICs. > > > > > > With a synchronous rule provider, the concern is that ofproto can get > > > blocked when the controller is trying to update several hundred flows. > > This > > > may cause couple of issues: > > > > > > - Controller will get blocked/slow updating the flows on a switch and may > > > not be able to service flow updates for other switches > > > - Controller may not be able to send control keepalive packets if it is > > > implementing a time sensitive protocol and ofproto is serializing all the > > > operations > > > > > > Do you think these are valid concerns? Making the rule routines > > > asynchronous adds more complexity to the implementation, so we want to > > make > > > sure there would be benefits of going the asynchronous path. > > > > It sounds like asynchronous implementation will produce better > > results, even if it's more work. > > > > > b) Assuming we do asynchronous rule operations, what does ofproto do > > when > > > a rule construct fails. Does it send asynchronous message to the > > controller > > > informing the flow could not be added. We are trying to understand how > > > would a controller know whether the flow was successfully added or not. > > > > It sends an OpenFlow error message to the controller. > > > > > c) While a given rule construct operation is in progress asynchronously, > > > would the ofproto issue new rule construct operations. How many such new > > > rule construct operations can ofproto issue before it expects an > > > acknowledgement on a pending operation. > > > > There's currently a hard-coded limit of 50 outstanding OpenFlow > > flow_mod operations at any given time. After that, it waits for a > > flow_mod to complete before allowing another one to issue. > > _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
