Well, does OF 1.0 really say anything about reordering at all? (And the nature of barrier is actually pretty unclear in the OF 1.0 spec, IMO, though it's certainly better in 1.1.) But yes, what you describe is not out-of-spec and I will agree with you.
The result is that just about every flow_mod in both NOX and POX should be followed by a barrier (or, possibly better, preceded by one). Except on switches (like HP) that don't support barrier, of course. Personally, I am not in a big hurry to do this myself, but I mostly run OVS and I don't THINK this has ever bitten me. (As a sidenote, POX does send a barrier after the initial clearing so at least on that one particular case, it should be okay.) -- Murphy On May 25, 2012, at 4:10 AM, Zoltán Lajos Kis wrote: > Hi Murphy, > > Unfortunately this is not the case. The specification explicitly says that > the switch is free to arbitrarily reorder messages. The controller must use a > barrier to ensure ordering (similar to memory barriers in programming). I > guess originally - up to OF 1.0 - this was not a big issue as there was only > a single table, and flow_mods rarely depended on each other. > Since OF 1.1, with multiple tables and groups you actually have to do a > group_mod - barrier - flow_mod - barrier - flow_mod - barrier - ... sequence > to make sure everything is OK. The problem with that is that barrier is > global, i.e. if you have independent applications, they'll end up blocking > each others' execution on the switch due to the barriers. > (I had a proposal for positive acknowledgements, and there was another one > for scoping barriers; unfortunately neither got accepted yet.) > > Regarding the issue, I think this is indeed a race condition (I guess by the > time NOX completes the handshake, and notifies the apps of the new switch, > the delete all flow_mod is most probably done on the switch). > > Regards, > Zoltan. > >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of >> Murphy McCauley >> Sent: Friday, May 25, 2012 12:54 PM >> To: Mabry Tyson >> Cc: NOX developers mailing list >> Subject: Re: [nox-dev] Possible bug in nox-classic nox.cc >> >> On May 25, 2012, at 3:23 AM, Mabry Tyson wrote: >> >>> I happened to notice this potential bug. I don't know >> whether there is something else that might avoid this. And, >> again, I saw this in Nox Classic. Maybe Nox/Pox does things >> differently, or maybe they have the same issue: >>> >>> nox.cc tells the switch to delete all the rules on >> registration of a switch. Shouldn't a barrier message be >> sent immediately after that? It would seem that otherwise a >> rule added after this might wind up getting deleted. >> >> Without having thought about this much, this doesn't seem >> like it could be an issue. Deleting flows and adding flows >> are both done with flow_mods. The problem you describe would >> only seem to be possible if flow_mods were reordered relative >> to other flow_mods. If flow_mods were reordered, it seems as >> if the only way you could ever get predictable behavior doing >> anything at all would be to always send a barrier after every >> flow_mod, which seems unreasonable. Thus, it seems to me >> that any switch where this is true is simply broken. >> >> No? >> >> -- Murphy >> >> (Incidentally, there's a tracker on github for bug reports -- >> https://github.com/noxrepo/nox-classic/issues)
