On Tue, May 27, 2014 at 09:57:09AM -0700, Ben Pfaff wrote: > 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.
Thanks I now understand. > > 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. I had meant to mark this as an RFC, sorry for omitting that. I'll try and polish things up and add OFPMP_TABLE_FEATURES multipart request support on top. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev