Our of curiosity what would be the case when flow_mods fail to install? (I would just guess, only if the switch has a full flow table?, I'm sure there are probably other reasons).
Thanks, Aaron 2011/9/14 Zoltán Lajos Kis <zoltan.lajos....@ericsson.com>: > 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 > 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 > http://noxrepo.org/mailman/listinfo/nox-dev > > > > _______________________________________________ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev > > -- Aaron O. Rosen Masters Student - Network Communication 306B Fluor Daniel _______________________________________________ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
