On Fri, Jan 11, 2019 at 10:09:05AM -0800, Justin Pettit wrote: > > > 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]>
Thanks, I fixed that stuff and applied this to master. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
