On Tue, May 27, 2014 at 06:05:38PM +0900, Simon Horman wrote: > Buffer a multi-part requests until all its parts are received. > > This is achieved by initialising the list_node field of messages > and passing them to ofmp_req_filter(). > > * If the message is not recognised as part of a multi-part requests it is > simply returned and processing continues as before. > > * If the messages part of a multipart request but is not the last message > of that request then it is buffered and ofmp_req_filter() returns NULL > indicating that the message should be skipped for now. > > * Otherwise, if the message is the last part of a multipart request then > the first message that is the part of the request is returned and any > subsequent parts are accessible via its list_head field. > > Some implementation notes: > > * As the list_head field may now contain messages ofpbuf_list_delete > should be used to delete them as necessary. I am not sure that I have > covered all such cases. > > * This implementations does not place any limits on how many > multipart requests may be buffered. It seems to me that it > would be wise to add some limit, hard coded or configurable, > to reduce the possibility of resource exhaustion. > > * multipart requests are still rejected handle_openflow__() > as no messages handlers can deal with them. In the short term > I plan to address this for a limited number of messages. > In the longer term I would like to extend coverage to all multipart > requests.
It doesn't make sense to cover all multipart requests. OpenFlow 1.3.3 made this explicit: Every multipart requests or replies is defined either as a single structure or as an array of 0 or more structures of the same type. If the multipart request or reply is defined as a single structure, it must use a single multipart message and the whole request or reply must be included in the body. If the multipart request or reply is defined as an array of structures, the body field must contain an integral number of objects, and no object can be split across two messages. The only OF1.3 multipart request for which the request is an array is OFPMP_TABLE_FEATURES. > Signed-off-by: Simon Horman <ho...@verge.net.au> The implementation here seems more like an RFC than a final version due to the points mentioned in the implementation notes. The code seems OK as far as it goes. Thanks, Ben. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev