[ovs-discuss] OVS custom action
Luca Mancini
luca.mancini at outlook.com
Sat Apr 25 08:29:24 UTC 2020
Hi Ben,
Firstly thank you for the swift response,
In order to get a better understanding of what I was doing (I’ve starting working with openvswitch a week ago) I tried defining an action called OFPAT_RAW_BUFFER (that did absolutely nothing)
just like the FAQ says and my mininet topology did in fact recognize it as a valid action.
Now I was starting the actual implementation of the action and that’s where my problems arise, I know how I’m going to program it I just don’t know where I’m meant to implement it and it’s somewhat frustrating.
Based on what you said :
“You'll need to make the action send packets that need to be buffered to userspace, with a "userspace" kernel action”
How exactly is this done? I believe the kernel receives the packet, and the datapath folder contains the code where the packet is recvd and processed, how exactly is it then sent to userspace, I’m having a tough time understanding how packets work in ovs.
Diving in the code I found the ovs_dp_process_packet should be what I’m looking for, but I’m not quite sure.
I guess a more accurate question for my case would be, where does someone who is new to ovs start from in order to understand the ovs codebase and learn how to implement a new action such as this one? Thanks again!
L
From: Ben Pfaff<mailto:blp at ovn.org>
Sent: Friday, April 24, 2020 18:50
To: Luca Mancini<mailto:luca.mancini at outlook.com>
Cc: ovs-discuss at openvswitch.org<mailto:ovs-discuss at openvswitch.org>
Subject: Re: [ovs-discuss] OVS custom action
On Fri, Apr 24, 2020 at 02:50:43PM +0000, Luca Mancini wrote:
> I am trying to implement a new openflow action on an openvswitch, that upon request by the controller buffers a given packet.
>
> So assume a topology like H1—s1--s2—H2 where h1 sends packets to h2, the controller would specify a BUFFER action to all packets going from h1 to h2
> Making the s1 switch create a buffer where all these packets are stored until the buffer is full and then send the buffer (as a new packet) down the path to H2.
> I have found very little material regarding the implementation of a new openflow action to ovs:
>
> I followed this guide a little bit but I’m finding some things a bit confusing https://mcfelix.me/blog/modifying-ovs/
> Some questions I have are:
> -is this type of action possible?
> -where exactly do I need to code the actual action function?
> -how and where are packets defined in OVS? I’m having trouble understading if the packet I need to be storing is the sk_buff that is passed as a parameter or if it’s something else
This should be possible. You'll need to make the action send packets
that need to be buffered to userspace, with a "userspace" kernel
action. Then you can accumulate the packets in userspace until they
should be released.
Since you'll only be dealing with userspace packets, struct dp_packet is
primarily what you need to care about.
The FAQ says this:
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 the :doc:`/intro/install/general`, 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 add the
vendor to ``vendor_map`` in ``build-aux/extract-ofp-actions``. Also, you
will need to add support for the vendor to ``ofpact_decode_raw()`` and
``ofpact_put_raw()`` in ``lib/ofp-actions.c``. (If you have a choice of
how to design your vendor extension actions, it will be easier if you make
them resemble the ONF and OVS extension actions.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20200425/d39e2f65/attachment.html>
More information about the discuss
mailing list