> On Aug 30, 2018, at 1:00 PM, Ben Pfaff <[email protected]> wrote:
> 
> Signed-off-by: Ben Pfaff <[email protected]>
> ---
> ofproto/ofproto.c | 84 +++++++++++++++++++++++++++++--------------------------
> 1 file changed, 44 insertions(+), 40 deletions(-)
> 
> diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c
> index d65a3fea1559..54f56d9f100e 100644
> --- a/ofproto/ofproto.c
> +++ b/ofproto/ofproto.c
> @@ -6344,49 +6344,60 @@ flow_monitor_delete(struct ofconn *ofconn, uint32_t 
> id)
> }
> 
> static enum ofperr
> -handle_flow_monitor_request(struct ofconn *ofconn, const struct ofp_header 
> *oh)
> +handle_flow_monitor_request(struct ofconn *ofconn, const struct ovs_list 
> *msgs)
>     OVS_EXCLUDED(ofproto_mutex)
> {
> ...
> +            if (request.table_id != 0xff

Do you think it would be worth using OFPTT_ALL?

> @@ -8398,7 +8400,7 @@ handle_single_part_openflow(struct ofconn *ofconn, 
> const struct ofp_header *oh,
>         return handle_port_desc_stats_request(ofconn, oh);
> 
>     case OFPTYPE_FLOW_MONITOR_STATS_REQUEST:
> -        return handle_flow_monitor_request(ofconn, oh);
> +        OVS_NOT_REACHED();

Grouping this with the OFPTYPE_TABLE_FEATURES_STATS_REQUEST case and adding a 
comment that they are handled by the multi-part requests might make it clearer 
why this should not be reached.

Acked-by: Justin Pettit <[email protected]>

--Justin


_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to