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
