[ovs-dev] [PATCH 3/4] connmgr: buffer multipart requests

[Simon Horman]

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 <horms at 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.