On Mon, 10 Jul 2023 20:39:11 +0200 Ilya Maximets wrote: > > As far as I understand what you're proposing, yes :) > > OK. Just to spell it all out: > > Userspace will install a flow with an OVS_FLOW_CMD_NEW: > > match:ip,tcp,... actions:something,something,drop(0) > match:ip,udp,... actions:something,something,drop(42) > > drop() here represents the OVS_ACTION_ATTR_DROP. > > Then, in net/openvswitch/actions.c:do_execute_actions(), while executing > these actions: > > case OVS_ACTION_ATTR_DROP: > kfree_skb_reason(skb, nla_get_u32(a) ? OVS_DROP_ACTION_WITH_ERROR > : OVS_DROP_ACTION); > > Users can enable traces and catch the OVS_DROP_ACTION_WITH_ERROR. > Later they can dump flows with OVS_FLOW_CMD_GET and see that the > error value was 42.
nod > >> Eric, Adrian, Aaron, do you see any problems with such implementation? > >> > >> P.S. There is a plan to add more drop reasons for other places in > >> openvswitch > >> module to catch more regular types of drops like memory issues or > >> upcall > >> failures. So, the drop reason subsystem can be extended later. > >> The explicit drop action is a bit of an odd case here. > > > > If you have more than ~4 OvS specific reasons, I wonder if it still > > makes sense to create a reason group/subsystem for OvS (a'la WiFi)? > > I believe, we will easily have more than 4 OVS-specific reasons. A few > from the top of my head: > - upcall failure (failed to send a packet to userspace) > - reached the limit for deferred actions > - reached the recursion limit > > So, creation of a reason group/subsystem seems reasonable to me. SG. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
