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
