[ovs-dev] [PATCH 0/4] Adds capability to return packets back to the kernel

[Chris Luke]

This list has been busy just recently, so I am wondering if my teeny
patchset has been overlooked. :)

Cheers,
Chris.


> -----Original Message-----
> From: dev-bounces at openvswitch.org [mailto:dev-
> bounces at openvswitch.org] On Behalf Of Chris Luke
> Sent: Wednesday, January 15, 2014 8:22 PM
> To: dev at openvswitch.org
> Subject: [ovs-dev] [PATCH 0/4] Adds capability to return packets back to
the
> kernel
> 
> 
> Jesse, all,
> 
> This patchset provides a method to return packets to the kernel for
> handling as though OVS never touched them.
> 
> To support this, we extend the datapath on kernels since 2.6.39 to be
> able to pass packets back by providing a 'back_to_kernel' action which
> causes the network input hook to return RX_HANDLER_PASS and userspace
> packets to be re-submitted to the input queue.
> 
> The latter, the re-submission, can happen in one of two ways: Either
> with a new function in the kernel that can deliver an skb to the lower
> half of __netif_receive_skb_core() (see the patch at the HEAD of
> https://github.com/chrisy/linux/tree/feature/netif-receive-finish )
> or on other kernels without this function by submitting the packet to
> the queue with netif_rx_ni().
> 
> The downside of using netif_rx_ni() is that the packet has already
> traversed much of the input path and this risks duplication of action.
> We mitigate this using a flag that causes some steps to be skipped, but
> this is a hack (though the way we use this is cute in that the existing
> implementation resets the flag for us so it seems there are no side
> effects!)
> 
> Next, we add the 'back_to_kernel' action to OpenFlow which triggers a
> datapath output action using the datapath 'back_to_kernel' action.
> 
> Suggestions for better names for 'back_to_kernel' welcome. :)
> 
> TODO:
> - When using netif_rx_ni() to send packets back from userspace, we may
>   be double-counting the first packet of a flow in the stats. This is
>   since we have no way to avoid having the packet hit the rx_handler
>   hook a second time and relying on it matching its flow.
> - In the userspace datapath, look at whether AF_PACKET can reinsert
>   packets at the right place in the input path, otherwise use a tap
>   interface to do same.
> 
> Signed-off-by: Chris Luke <chris_luke at cable.comcast.com>
> ---
> Revision 1:
> - Alter kernel hook to be able to return packets to the kernel.
> - Add tweak to vswitch to use this feature instead of a learning
>    switch when it encounters OFPP_NORMAL.
> 
> Revision 2:  (supercedes patch 2606)
> - Refactor the path taken through the datapath to remove one skb clone
>    and lots of value returns.
> - Add capability to insert a packet back to the kernel input queue.
> - Add openflow action to send a packet back_to_kernel.
> - Update tests/docs.
> 
> Revision 3:  (supercedes patch 2651)
> - Break the patch into several;
>   - Datapath back_to_kernel action.
>   - OpenFlow action back_to_kernel. (requires datapath patch)
> - Add tests for back_to_kernel method.
> - Abandon the port_normal_mode and OFPP_NORMAL handling in vswitch
> patch.
> - Alter datapath method from a special output port to a discrete action.
> - skb header pointer "cleanup" has proven unnecessary.
> - Alter how packets that went via userspace are reinput to the kernel
>   (no more PACKET_LOOPBACK crud):
>   - Hijack the tc_verd field, if we have it, in the skb to signal that
>     the taps can be skipped. This works back to at least 2.6.36
>     (which is when the current rx_handler logic was introduced.)
>   - Proof of concept kernel patch to make this much more efficient.
> 
> 
> Chris Luke (4):
>   datapath: Action for returning packets to the kernel
>   datapath: New kernel function to insert packets async
>   lib,ofproto: Add 'back_to_kernel' OpenFlow action
>   doc: Documentation updates for the back_to_kernel patches
> 
>  AUTHORS                       |    1 +
>  FAQ                           |   87 ++++++++++++++++++++++++++++++-----
>  NEWS                          |    2 +
>  acinclude.m4                  |    3 ++
>  datapath/actions.c            |   40 +++++++++++++++++
>  datapath/datapath.c           |   23 ++++++++--
>  datapath/datapath.h           |    9 +++-
>  datapath/flow_netlink.c       |    6 ++-
>  datapath/vport-netdev.c       |  100
> ++++++++++++++++++++++++++++++++++++-----
>  datapath/vport.c              |   26 ++++++++++-
>  datapath/vport.h              |    4 +-
>  include/linux/openvswitch.h   |    1 +
>  include/openflow/nicira-ext.h |    1 +
>  lib/dpif-netdev.c             |    1 +
>  lib/dpif.c                    |    1 +
>  lib/odp-execute.c             |    4 ++
>  lib/odp-util.c                |   12 +++++
>  lib/ofp-actions.c             |   30 +++++++++++++
>  lib/ofp-actions.h             |    8 ++++
>  lib/ofp-parse.c               |    4 ++
>  lib/ofp-util.def              |    1 +
>  ofproto/ofproto-dpif-xlate.c  |   27 +++++++++++
>  tests/odp.at                  |    1 +
>  tests/ofproto-dpif.at         |   15 +++++++
>  tests/ovs-ofctl.at            |    2 +
>  utilities/ovs-ofctl.8.in      |    7 +++
>  26 files changed, 386 insertions(+), 30 deletions(-)
> 
> --
> 1.7.9.5
> 
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>