See questions below: > On Mar 21, 2017, at 7:42 AM, Jozef Bacigál <[email protected]> > wrote: > > Luis, > > Sal---services you can use one by one and the ordering can by managed by > downstream projects itself. > Config on the other side /FRM or FRS/ just push the mods as it comes. > One difference between FRM and FRS is that FRM push the mods as it comes/find > in configDS
If FRM pushes the mods as they come, what is the order issue then? > and FRS make the diff between configDS and inventoryDS and try to push only > changes as BULK services. Bulk means it keeps ordering groups before flows > etc. and if needed it send a barrier to be sure that the mods are properly > installed into device. If you are getting individual mods from application, how does FRS prepare a bulk request? > > Jozef > > -----Original Message----- > From: Luis Gomez [mailto:[email protected]] > Sent: Tuesday, March 21, 2017 3:36 PM > To: Jozef Bacigál <[email protected]> > Cc: Kochba, Alon <[email protected]>; Jamo Luhrsen <[email protected]>; > [email protected] > Subject: Re: [openflowplugin-dev] Bug 8025 - missing method to use barrier > when installing rules and giving packet_out > > Jozef, do you mean using SalFlowService/SalGroupService (RPC) keeps order but > writing in config (FRM) does not guarantee order? Also if you say this will > be fixed in FRS, what is the time plan for that? Nitrogen? > >> On Mar 21, 2017, at 4:07 AM, Jozef Bacigál <[email protected]> >> wrote: >> >> Hi Alon, >> >> Yes you right config is unpredictable. Still you can use >> SalFlowService/SalGroupService instead of config and you got the requested >> functionality. >> But if you use config to put flow mods even barrier, it can later on device >> than packet out. >> The second case (group mod + flow mod) it is well working with FRS instead >> of FRM, because FRS sending barrier when needed. >> >> Jozef >> >> -----Original Message----- >> From: Kochba, Alon [mailto:[email protected]] >> Sent: Tuesday, March 21, 2017 10:56 AM >> To: Jozef Bacigál <[email protected]>; Jamo Luhrsen >> <[email protected]>; [email protected] >> Subject: RE: [openflowplugin-dev] Bug 8025 - missing method to use barrier >> when installing rules and giving packet_out >> >> Hi Jozef, >> >> Thanks for the reply. >> We understand we can use statistics for this today - but we want to avoid >> that as relying on statistics does not scale very well. >> >> We would like openflowplugin to expose an API that takes advantage of the >> barrier feature as defined in the openflow spec (flow_mod + barrier + packet >> out, or group_mod + barrier + flow_mod). >> >> --alon >> >> >> -----Original Message----- >> From: Jozef Bacigál [mailto:[email protected]] >> Sent: Tuesday, 21 March 2017 10:47 >> To: Jamo Luhrsen <[email protected]>; >> [email protected]; Kochba, Alon <[email protected]> >> Subject: RE: [openflowplugin-dev] Bug 8025 - missing method to use barrier >> when installing rules and giving packet_out >> >> Hi Jamo, >> >> If I got it, you need to install two flows, and then send a packet in this >> order. So only solution right now, quite easy is, to push the flows into >> configuration and wait for statistics to be sure flow are installed and then >> and only then send the packet. You don't need to run statistics >> periodically, there is an direct RPC statistics gathering, you can run it to >> ensure the flows are installed. >> >> Jozef >> >> -----Original Message----- >> From: Jamo Luhrsen [mailto:[email protected]] >> Sent: Monday, March 20, 2017 11:42 PM >> To: [email protected]; Kochba, Alon <[email protected]> >> Subject: [openflowplugin-dev] Bug 8025 - missing method to use barrier when >> installing rules and giving packet_out >> >> Hi OFP, >> >> I just raised a bug/enhancement-request: >> >> https://bugs.opendaylight.org/show_bug.cgi?id=8025 >> >> Alon had sent an initial inquiry (see bug) about this, but we didn't hear >> back. >> Hoping that it can get some visibility with OFP at some point. >> >> The general problem for netvirt which consumes the plugin is that we are >> running in to race conditions which are ugly (hard to reproduce, hard to >> debug) and will be painful for end users when they hit them. The thinking is >> that with this ability exposed, we can eliminate the races in a fundamental >> way provided by the openflow protocol. >> >> Thanks, >> JamO >> _______________________________________________ >> openflowplugin-dev mailing list >> [email protected] >> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev >> _______________________________________________ >> openflowplugin-dev mailing list >> [email protected] >> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev > _______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
