Hi Ben, Thanks for reply. I just have one doubt . Reply inline
Regards Anju -----Original Message----- From: Ben Pfaff [mailto:b...@ovn.org] Sent: Wednesday, January 23, 2019 5:57 AM To: Anju Thomas <anju.tho...@ericsson.com> Cc: d...@openvswitch.org; Keshav Gupta <keshugup...@gmail.com> Subject: Re: [ovs-dev] [PATCH v6] Improved Packet Drop Statistics in OVS On Mon, Jan 21, 2019 at 07:01:33AM +0000, Anju Thomas wrote: > On Thu, Jan 17, 2019 at 04:49:20AM +0000, Anju Thomas wrote: > > Currently OVS maintains explicit packet drop/error counters only on port > > level. Packets that are dropped as part of normal OpenFlow processing > > are > > counted in flow stats of “drop” flows or as table misses in table stats. > > These can only be interpreted by controllers that know the semantics of > > the configured OpenFlow pipeline. Without that knowledge, it is > > impossible > > for an OVS user to obtain e.g. the total number of packets dropped due > > to > > OpenFlow rules. > > Thanks for the patch! I agree with your motivations--it is useful to > understand why packets are dropped. I have some comments to add to Ilya's. > > It looks like the drop actions that this formats in > format_odp_drop_action() can't necessarily be parsed by > odp_actions_from_string(). Usually we expect this. (Probably the syntax > should be adjusted to make parsing more straightforward.) <Anju> > odp_actions_from string is used to convert string to action for parsing .But > we are using the drop action reason only fo display. We do not want to > provide an option for its parsing. Is my understanding correct. Why not? Ordinarily, anything that can be output can be input. It is useful for testing to be able to input datapath actions. Agreed. Ideally yes. But in this case the error are set due to some error during translation like *bridge not found *too many resubmits *recursion too deep *too many resubmits *sack too deeo *no recirculation context *too many mpls labels * invalid tunnel metadata * unsupported packet type * ecn mismatch at tunnel decapsulation * forwarding disabled * pipeline drop Except pipeline drop I don’t understand how it will make sense to inject others as input . Can you explain if I am missing something ? > It looks like xlate_error maps one-to-one to drop reasons (except why is > XLATE_FORWARDING_DISABLED mapped to OVS_DROP_REASON_MAX?), so do we really > want different enumerations? Mapping back and forth is a bit of a slog, and > there's already a way to translate xlate_errors to strings. > > <Anju> .We just kept it separate for better code readability and also that > XLATE_** error were more in the ofproto layer and we wanted something in the > datapath . If you believe that that is not justified compared to the slogging > then I will modify this . What do you say ? I'd leave them the same for now, until there's a need for them to be different. <Anju> Sure. I will keep them same error viz XLATE_** codes. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
