[ovs-discuss] How does OpenFlow protocol action become flow table entry?

[Ben Pfaff]

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" <blp at 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" <blp at 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.
> >> 
> >> 
> 
>