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

Reply via email to