Well, I wasn't being over pedantic. In fact I'm setting up MPLS LSPs, which involves sending a number of flow entries to different switches. In this case I don't want to blindly install flows, as if one of them fails I would have to explicitly remove the successful ones (with yet another flow_mods :).
Regards, Zoltan. ________________________________ From: Murphy McCauley [mailto:jam...@nau.edu] Sent: Tuesday, September 13, 2011 7:58 AM To: Zoltán Lajos Kis Cc: nox-dev@noxrepo.org Subject: Re: [nox-dev] Cooperative threading vs. blocking send I'd just send both commands regardless and only ever look at pendingFlow again in the barrier and error handlers. I think that sidesteps the need to worry about synchronization. At any rate, good luck. :) -- Murphy On Sep 12, 2011, at 10:44 PM, Zoltán Lajos Kis wrote: I could do that, but it probably gets me into the territory of volatiles - and perhaps locks: ... pendingFlow = new PendingFlow(mod->header->xid, barrier->xid); send_openflow_command(datapath_id, &mod->header, true); if (pendingFlow != NULL) { send_openflow_command(datapath_id, barrier, true); } ... Anyway, thanks for the confirmation. Regards, Zoltan. ________________________________ From: Murphy McCauley [mailto:jam...@nau.edu] Sent: Monday, September 12, 2011 8:42 PM To: Zoltán Lajos Kis Cc: nox-dev@noxrepo.org<mailto:nox-dev@noxrepo.org> Subject: Re: [nox-dev] Cooperative threading vs. blocking send I'd have to look into it to be sure, but I think the scenario you describe may well be possible. However... couldn't you just put the creation/registration of the PendingFlow *before* sending either of the commands? -- Murphy On Sep 12, 2011, at 7:10 AM, Zoltán Lajos Kis wrote: Hi, In my C++ NOX (Zaku) app I would like to make sure that a flow is installed on the switch. Having no better solution, I send a barrier request right after the flow_mod, and then wait for either an error, or a barrier reply. For this I register the flow_mod's and barrier's xids, and then compare incoming events against those. See the pseudoish code below for an example. Could someone familiar with the cooperative thread implementation in NOX tell me, whether it is possible that a blocking send_openflow_command() result in the current thread actually blocking and yielding to another one? Particularly in this code, can it happen that sending the flow_mod completes, but then the second call to send blocks, yielding to another thread. Then on this other thread the incoming error message is received and dispatched to the handler method? Resulting in the error being discarded as at that time the PendingFlow was not even registered... And if so, is there a way to temporarily disable this yielding, or do I better start making the code more complex? Thank you, Zoltan. ------------------------------ struct PendingFlow { uint32_t modXid; uint32_t barrierXid; ... } class Example { PendingFlow *pendingFlow; ... void Example::install_flow(ofp_flow_mod *mod) { ofp_header *barrier = make_barrier(); mod->header->xid = generate_xid(); barrier->xid = generate_xid(); send_openflow_command(pi.datapath_id, &mod->header, true); send_openflow_command(pi.datapath_id, barrier, true); pendingFlow = new PendingFlow(mod->header->xid, barrier->xid); ... } Disposition Example::handleError(const Event &e) { const Error_event& err = assert_cast<const Error_event&>(e); if (pendingFlow != NULL && pendingFlow.modXid == getErrorXid(err)) { delete pendingFlow; pendingFlow = NULL; // Process error } ... return CONTINUE; } Disposition Example::handleBarrier(const Event &e) { const Barrier_reply_event& barrier = assert_cast<const Barrier_reply_event>(e); if (pendingFlow != NULL && pendingFlow.barrierXid == getBarrierXid(barrier)) { delete pendingFlow; pendingFlow = NULL; // Process completion } .. return CONTINUE; } ... } _______________________________________________ nox-dev mailing list nox-dev@noxrepo.org<mailto:nox-dev@noxrepo.org> http://noxrepo.org/mailman/listinfo/nox-dev
_______________________________________________ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
