Thanks Ben for the useful answer, following these directions I was able to add a new field and was able to successfully create a table entry specifying a value for that filed.
However, now I need to verify the packet extraction process done in miniflow_extract(). My question is: how can I debug this method ? flow.c does not import openvswitch/vlog.h, is there a reason for that ? should I just add support for logging in flow.c or is there another way to debug it ? Thanks again, Enas On Wed, Jan 6, 2016 at 10:20 PM, Ben Pfaff <b...@ovn.org> wrote: > On Wed, Jan 06, 2016 at 01:26:58PM +0300, Enas Ahmad wrote: > > I am designing a new protocol for IoT applications, and I would like to > > know if I can extend Open Flow match fields to add a new header field > > designed by my new protocol ? > > Also, can I define a new field for the set-field action ? > > The FAQ says: > > ### Q: How do I add support for a new field or header? > > A: Add new members for your field to "struct flow" in lib/flow.h, and > add new enumerations for your new field to "enum mf_field_id" in > lib/meta-flow.h, following the existing pattern. Also, add support > to miniflow_extract() in lib/flow.c for extracting your new field > from a packet into struct miniflow. Then recompile and fix all of > the new warnings, implementing new functionality for the new field > or header as needed. (If you configure with --enable-Werror, as > described in [INSTALL.md], then it is impossible to miss any > warnings.) > > If you want kernel datapath support for your new field, you also > need to modify the kernel module for the operating systems you are > interested in. This isn't mandatory, since fields understood only > by userspace work too (with a performance penalty), so it's > reasonable to start development without it. If you implement > kernel module support for Linux, then the Linux kernel "netdev" > mailing list is the place to submit that support first; please read > up on the Linux kernel development process separately. The Windows > datapath kernel module support, on the other hand, is maintained > within the OVS tree, so patches for that can go directly to > ovs-dev. > > ### 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. > -- ------------------------------ This message and its contents, including attachments are intended solely for the original recipient. If you are not the intended recipient or have received this message in error, please notify me immediately and delete this message from your computer system. Any unauthorized use or distribution is prohibited. Please consider the environment before printing this email.
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
