On Thu, Oct 13, 2011 at 4:28 PM, Ben Pfaff <[email protected]> wrote: > 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.
While Ben is correct about what the protocol allows, my personal belief is that the "one stats request -> multiple stats replies" behavior should be discouraged and I would love to see it deprecated. It was a pain to deal with in the flowvisor (extra logic for stats, totally different from any other request type), I've heard lots of anecdotes of it causing problems for people when a certain vendor's implementation used this feature in a demo (which they've since changed), and it's not clear what the benefit was given the cost from a byte efficiency model. I suppose if you have a very distributed (e.g., large multi-chassis) switch where the process of querying all of the ports, for example, might be better handled asynchronously for each line card, than using this mechanism, you could send replies for each line card as it became available rather than queuing the replies and sending them all at once. But, there are many processes in multi-chassis that have this problem (flow table modifications, feature negotiation, listing ports, etc.) that it seems inconsistent to only expose this functionality for stats. Does anyone else know of another use case for this? I really don't see the benefit. - Rob . _______________________________________________ openflow-discuss mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
