Thanks Ben. That's a bit buried in the spec given that the value appears in the text and the flag name, though defined in openflow.h, doesn't appear in the spec.
-Dan On Thursday, October 13, 2011 at 4:28 PM, Ben Pfaff wrote: > On Thu, Oct 13, 2011 at 04:23:58PM -0700, Dan Talayco wrote: > > Recently a question came up about the number of responses that may result > > from a request. I don't recall seeing anything in the spec about this. > > > > There are places where this might be optional (each port stats or flow > > stats entry could be put in a different message). But there may be places > > where it's required. For example, when a flow stats request is made, there > > is a possibility that the size of the response is too big for one OF > > message (the header length field is 16 bits and there are switches that > > support tens of thousands of flows). I'd be interested in others' > > experiences and thoughts. A couple of notes: > > > > * Correct me if I'm wrong, but nothing prevents the switch from always > > responding with small OF messages, e.g., one entry per OF message. Should > > this be advised against? > > > > * All the messages in response to the request will have the same > > transaction ID. Controllers need to be prepared for this. > > > > => Is there an issue here in that we can't identify the last message > > associated with the transaction? A barrier request could be used by the > > controller; presumably the barrier reply would get queued behind the > > previous transaction response. Might be considered expensive for every > > stats query. > > A non-stats request has 0 or 1 reply messages. A barrier can be used > to verify that the request had 0 replies. > > A stats message has 1 or more reply message. Every message before the > last one has the "more" flag set. The last message does not have the > "more" flags set. _______________________________________________ openflow-discuss mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
