I see. So the Barrier( ) is more of an operation which ensures that all
messages until that point have been "taken care of" (usually without
dropping). The spec gives the impression that it is more equivalent to a
transaction commit (the barrier reply message actually carries a xid).
Probably that
Oops.. typos.
> One can interpret "finish processing" as having dropped. I am *not*
> suggesting we do, but this is apparently not an impossibility. It is a
> rare event nonetheless.
On 19 December 2010 23:41, kk yap wrote:
> Hi Syed,
>
> One can interpret "finish processing" as having dropped
Hi Syed,
One can interpret "finish processing" as having dropped. I am
suggesting we do, but this is apparently not a impossibility. It is a
rare event nonetheless.
Regards
KK
On 19 December 2010 23:37, Syed Akbar Mehdi
wrote:
> Hi KK,
>
> Thanks for detailed explanation. However this conflic
Hi KK,
Thanks for detailed explanation. However this conflicts somewhat with the
OpenFlow Spec v1.0. In section 5.3.7 (page 36) of the OpenFlow1.0 spec it is
written that:
"Upon receipt, the switch must finish processing *all* previously received
messages before executing any messages beyond the
Hi Syed,
The barrier function is only there to tell you that a preceding
message is processed (i.e., the command is carried out, dropped or
error code is returned). So, you can imagine if you want to check the
flow mod is inserted or not, you can do the following:
1) send flow mod
2) send barrier
Hi KK,
You say that:
"Meaning, it is perfectly okay for a switch to
send a reply to the barrier and ignore the flow mod before that."
How is the barrier reply useful then, if it does not guarantee this?
--
Regards,
Syed Akbar Mehdi,
School of EECS (SEECS),
National University of Sciences and T
Hi Derek,
This question is better asked on openflow-spec or openflow-discuss. :)
Regards
KK
On 19 December 2010 22:11, Derek Cormier wrote:
> Thanks KK, that clears everything up. May I ask, what is the main reason for
> not including a flow mod reply in the OpenFlow protocol? Is it speed? Isn
Thanks KK, that clears everything up. May I ask, what is the main reason
for not including a flow mod reply in the OpenFlow protocol? Is it
speed? Isn't OpenFlow fast enough?
-Derek
On 12/20/2010 02:38 PM, kk yap wrote:
Hi Derek,
Some comments inline. Hope they help.
Regards
KK
On 19 Dece
Hi Derek,
Some comments inline. Hope they help.
Regards
KK
On 19 December 2010 21:10, Derek Cormier wrote:
> I noticed that the flow mod event fires in response to a successful NOX API
> call for adding a flow. It gives the impression that it was successfully
> added to the switch, but, this i
I noticed that the flow mod event fires in response to a successful NOX
API call for adding a flow. It gives the impression that it was
successfully added to the switch, but, this is not always the case. For
example, if I send two identical /ofp_flow_mod/ requests with the
*OFPFF_CHECK_OVERLAP*
10 matches
Mail list logo
