There's a couple of layers here. ofp-actions translates raw OpenFlow actions into ofpact structures. (This translation allows the rest of the Open vSwitch code not to have to deal with differences between OpenFlow versions.) Later, ofproto-dpif-xlate translates ofpacts into the Netlink format used by the Linux kernel module. (This translation simplifies a lot of OpenFlow concepts into simpler datapath ones.) The Linux kernel module implements the datapath actions.
So you need to define a datapath action, have ofproto-dpif-xlate translate into those actions, then implement your datapath action in the kernel module. On Fri, May 01, 2015 at 10:13:37AM -0500, David Evans wrote: > Hi Ben, > > What I mean is - how does a new packet action in action.c - aka > OVS_ACTION_ATTR_STRIP_FOO strip_foo_header end up getting called on a > packet from OpenFlow flow rule? > > I can¹t make the connection between open flow handling code (ofp_action.c > ofproto-dpif-xlate.c) to the ovs code for manipulating packets. > Am I completely off track here? > Where do I put my packet modifier on skbuf¹s coming into the sw. And how > do I connect them up to the Open Flow side. > > I would have expected to write a fn in packets.c and reference that in > action.c via OVS_ACTION_ATTR* enum, and ?somehow? generate that by > behaviour in a flow table entry from the open flow side (ofp_action etc..). > I only see parse,encode,decode,format types of functions in ofp_action.c > and some magically generated put_* and ofpact_put_* fns in ofp-action.inc2 > > So I know I need an entry in ofp_raw_action_type > /* ZZ1.0+(4): void. */ > ZZ_RAW_STRIP_FOO, > And it¹s relevant parse,encode,decode,format fns.. But what next? > > > > Thanks for your enlightenment so far.. :) > > Dave. > > > On 4/27/15, 3:52 PM, "Ben Pfaff" <b...@nicira.com> wrote: > > >Do you mean, where is the code that actually performs the action? > >Usually that's in ofproto/ofproto-dpif-xlate.c, as part of action > >translation. > > > >On Mon, Apr 27, 2015 at 03:50:13PM -0500, David Evans wrote: > >> Thanks Ben > >> Yes. > >> And I have that side of it written, but which part pushes the action > >>into > >> the tables for a bridge? > >> How is it dispatched when ovs is running? > >> > >> > >> Regards, > >> Dave. > >> > >> On 4/27/15, 3:18 PM, "Ben Pfaff" <b...@nicira.com> wrote: > >> > >> >On Mon, Apr 27, 2015 at 03:01:16PM -0500, David Evans wrote: > >> >> I have been trolling through the source looking for how OXM/NXM > >> >>actions end > >> >> up as functioning entries in flow tables. > >> >> I understand that ofp-actions.c and the ofp_raw_action_type > >>enumeration > >> >>is > >> >> at the centre of it all. > >> >> I get how the incoming OpenFlow command strings are processed by > >> >> encode/decode fns but that?s about it? > >> >> But I don?t understand the path of adding these actions > >> >> > >> >> I want to use the ActionExperimenter from RYU to drive new arbitrary > >> >>packet > >> >> modifiers via the experimenter extension to open flow. > >> >> I know I could use ovs-ofctl and actions.c and add new instructions > >> >>that > >> >> way, but I want to stick to OpenFlow so I can drive with other > >> >>controllers > >> >> like Ryu. > >> > > >> >Did you read the FAQ? > >> > > >> >### Q: How do I add support for a new OpenFlow action? > >> > > >> >A: Add your new action to "enum ofp_raw_action_type" in > >> > lib/ofp-actions.c, following the existing pattern. Then recompile > >> > and fix all of the new warnings, implementing new functionality for > >> > the new action as needed. (If you configure with --enable-Werror, > >> > as described in [INSTALL.md], then it is impossible to miss any > >> > warnings.) > >> > > >> > If you need to add an OpenFlow vendor extension action for a vendor > >> > that doesn't yet have any extension actions, then you will also > >> > need to edit build-aux/extract-ofp-actions. > >> > >> > > _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
