delta/openvswitch.git/datapath, branch master

make: Remove the Linux datapath.

2022-07-15T11:45:55+00:00

Update the necessary make and configure files to remove the Linux
datapath and then remove the datapath.

Move datapath/linux/compat/include/linux/openvswitch.h to
include/linux/openvswitch.h because it is needed to generate header
files used by the userspace switch.

Also remove references to the Linux datapath from auxiliary files
and utilities since it is no longer supported.

Signed-off-by: Greg Rose 
Reviewed-by: David Marchand 
Signed-off-by: Ilya Maximets

openvswitch.h: Align uAPI definition with the kernel.

2022-03-25T19:32:12+00:00

Upstream commit:
commit 1926407a4ab0e59d5a27bed7b82029b356d80fa0
Author: Ilya Maximets
Date: Wed Mar 9 23:20:33 2022 +0100

net: openvswitch: fix uAPI incompatibility with existing user space

Few years ago OVS user space made a strange choice in the commit [1]
to define types only valid for the user space inside the copy of a
kernel uAPI header. '#ifndef __KERNEL__' and another attribute was
added later.

This leads to the inevitable clash between user space and kernel types
when the kernel uAPI is extended. The issue was unveiled with the
addition of a new type for IPv6 extension header in kernel uAPI.

When kernel provides the OVS_KEY_ATTR_IPV6_EXTHDRS attribute to the
older user space application, application tries to parse it as
OVS_KEY_ATTR_PACKET_TYPE and discards the whole netlink message as
malformed. Since OVS_KEY_ATTR_IPV6_EXTHDRS is supplied along with
every IPv6 packet that goes to the user space, IPv6 support is fully
broken.

Fixing that by bringing these user space attributes to the kernel
uAPI to avoid the clash. Strictly speaking this is not the problem
of the kernel uAPI, but changing it is the only way to avoid breakage
of the older user space applications at this point.

These 2 types are explicitly rejected now since they should not be
passed to the kernel. Additionally, OVS_KEY_ATTR_TUNNEL_INFO moved
out from the '#ifdef __KERNEL__' as there is no good reason to hide
it from the userspace. And it's also explicitly rejected now, because
it's for in-kernel use only.

Comments with warnings were added to avoid the problem coming back.

(1 << type) converted to (1ULL << type) to avoid integer overflow on
OVS_KEY_ATTR_IPV6_EXTHDRS, since it equals 32 now.

[1] beb75a40fdc2 ("userspace: Switching of L3 packets in L2 pipeline")

Fixes: 28a3f0601727 ("net: openvswitch: IPv6: Add IPv6 extension header support")
Link: https://lore.kernel.org/netdev/3adf00c7-fe65-3ef4-b6d7-6d8a0cad8a5f@nvidia.com
Link: https://github.com/openvswitch/ovs/commit/beb75a40fdc295bfd6521b0068b4cd12f6de507c
Reported-by: Roi Dayan
Signed-off-by: Ilya Maximets
Acked-by: Nicolas Dichtel
Acked-by: Aaron Conole
Link: https://lore.kernel.org/r/20220309222033.3018976-1-i.maximets@ovn.org
Signed-off-by: Jakub Kicinski

Not adding OVS_KEY_ATTR_IPV6_EXTHDRS in this commit as this is not
necessary. Will be added along with the actual userspace
implementation.

This change should help avoiding incompatibility issues in the future.

Acked-by: Aaron Conole
Signed-off-by: Ilya Maximets

Encap & Decap actions for MPLS packet type.

2022-01-17T01:04:20+00:00

The encap & decap actions are extended to support MPLS packet type.
Encap & decap actions adds and removes MPLS header at start of the
packet.

The existing PUSH MPLS & POP MPLS actions inserts & removes MPLS
header between ethernet header and the IP header. Though this behaviour
is fine for L3 VPN where an IP packet is encapsulated inside a MPLS
tunnel, it does not suffice the L2 VPN requirements. In L2 VPN the
ethernet packets must be encapsulated inside MPLS tunnel.

In this change the encap & decap actions are extended to support MPLS
packet type. The encap & decap adds and removes MPLS header at the
start of packet as depicted below.

Encapsulation:

Actions - encap(mpls),encap(ethernet)

Incoming packet -> | ETH | IP | Payload |

1 Actions -  encap(mpls) [Datapath action - ADD_MPLS:0x8847]

        Outgoing packet -> | MPLS | ETH | Payload|

2 Actions - encap(ethernet) [ Datapath action - push_eth ]

        Outgoing packet -> | ETH | MPLS | ETH | Payload|

Decapsulation:

Incoming packet -> | ETH | MPLS | ETH | IP | Payload |

Actions - decap(),decap(packet_type(ns=0,type=0))

1 Actions -  decap() [Datapath action - pop_eth)

        Outgoing packet -> | MPLS | ETH | IP | Payload|

2 Actions - decap(packet_type(ns=0,type=0)) [Datapath action - POP_MPLS:0x6558]

        Outgoing packet -> | ETH  | IP | Payload|

Signed-off-by: Martin Varghese 
Acked-by: Eelco Chaudron 
Signed-off-by: Ilya Maximets

compat: handle NF_REPEAT error on nf_conntrack_in.

2021-12-09T14:18:23+00:00

In patch [1] rpl_nf_conntrack_in was backported as static inline
function without do..while loop handling NF_REPEAT error.
In patch [2] rpl_nf_conntrack_in backported function was removed
from compat/include/net/netfilter/nf_conntrack_core.h as an unused.

As a result the do..while loop around nf_conntrack_in was lost and
this caused problems on old RHEL kernels with the tcp SYN
loss on a connection with same 5-tuple, which ran in last
nf_conntrack_tcp_timeout_time_wait. The connection could be
initiated on a tcp SYN retry after one second.

1: https://github.com/openvswitch/ovs/commit/4fdec8986a203b0dc9d9c183c932826967572e0f
2: https://github.com/openvswitch/ovs/commit/e9b33ad780f3bc712a5de6be9e1e0803fadcd249

Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-September/387623.html
Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-October/388424.html
Signed-off-by: Vladislav Odintsov 
Reviewed-by: Greg Rose 
Signed-off-by: Ilya Maximets

dpctl: dpif: Allow viewing and configuring dp cache sizes.

2021-11-08T20:48:05+00:00

This patch adds a general way of viewing/configuring datapath
cache sizes. With an implementation for the netlink interface.

The ovs-dpctl/ovs-appctl show commands will display the
current cache sizes configured:

 $ ovs-dpctl show
 system@ovs-system:
   lookups: hit:25 missed:63 lost:0
   flows: 0
   masks: hit:282 total:0 hit/pkt:3.20
   cache: hit:4 hit-rate:4.54%
   caches:
     masks-cache: size:256
   port 0: ovs-system (internal)
   port 1: br-int (internal)
   port 2: genev_sys_6081 (geneve: packet_type=ptap)
   port 3: br-ex (internal)
   port 4: eth2
   port 5: sw0p1 (internal)
   port 6: sw0p3 (internal)

A specific cache can be configured as follows:

 $ ovs-appctl dpctl/cache-set-size DP CACHE SIZE
 $ ovs-dpctl cache-set-size DP CACHE SIZE

For example to disable the cache do:

 $ ovs-dpctl cache-set-size system@ovs-system masks-cache 0
 Setting cache size successful, new size 0.

Signed-off-by: Eelco Chaudron 
Acked-by: Paolo Valerio 
Acked-by: Flavio Leitner 
Signed-off-by: Ilya Maximets

dpctl: dpif: Add kernel datapath cache hit output.

2021-11-08T20:48:05+00:00

This patch adds cache usage statistics to the output:

 $ ovs-dpctl show
 system@ovs-system:
   lookups: hit:24 missed:71 lost:0
   flows: 0
   masks: hit:334 total:0 hit/pkt:3.52
   cache: hit:4 hit-rate:4.21%
   port 0: ovs-system (internal)
   port 1: genev_sys_6081 (geneve: packet_type=ptap)
   port 2: br-int (internal)
   port 3: br-ex (internal)
   port 4: eth2
   port 5: sw1p1 (internal)
   port 6: sw0p4 (internal)

Signed-off-by: Eelco Chaudron 
Acked-by: Flavio Leitner 
Acked-by: Paolo Valerio 
Signed-off-by: Ilya Maximets

datapath: handle DNAT tuple collision.

2021-10-12T15:49:11+00:00

Upstream commit:
    commit 8aa7b526dc0b5dbf40c1b834d76a667ad672a410
    Author: Dumitru Ceara 
    Date:   Wed Oct 7 17:48:03 2020 +0200

    openvswitch: handle DNAT tuple collision

    With multiple DNAT rules it's possible that after destination
    translation the resulting tuples collide.

    For example, two openvswitch flows:
    nw_dst=10.0.0.10,tp_dst=10, actions=ct(commit,table=2,nat(dst=20.0.0.1:20))
    nw_dst=10.0.0.20,tp_dst=10, actions=ct(commit,table=2,nat(dst=20.0.0.1:20))

    Assuming two TCP clients initiating the following connections:
    10.0.0.10:5000->10.0.0.10:10
    10.0.0.10:5000->10.0.0.20:10

    Both tuples would translate to 10.0.0.10:5000->20.0.0.1:20 causing
    nf_conntrack_confirm() to fail because of tuple collision.

    Netfilter handles this case by allocating a null binding for SNAT at
    egress by default.  Perform the same operation in openvswitch for DNAT
    if no explicit SNAT is requested by the user and allocate a null binding
    for SNAT for packets in the "original" direction.

    Reported-at: https://bugzilla.redhat.com/1877128
    Suggested-by: Florian Westphal 
    Fixes: 05752523e565 ("openvswitch: Interface with NAT.")
    Signed-off-by: Dumitru Ceara 
    Signed-off-by: Jakub Kicinski 

Fixes: f8f97cdce9ad ("datapath: Interface with NAT.")
Signed-off-by: Dumitru Ceara 
Acked-by: Paolo Valerio 
Signed-off-by: Ilya Maximets

dpif-netlink: Introduce per-cpu upcall dispatch.

2021-07-16T18:05:03+00:00

The Open vSwitch kernel module uses the upcall mechanism to send
packets from kernel space to user space when it misses in the kernel
space flow table. The upcall sends packets via a Netlink socket.
Currently, a Netlink socket is created for every vport. In this way,
there is a 1:1 mapping between a vport and a Netlink socket.
When a packet is received by a vport, if it needs to be sent to
user space, it is sent via the corresponding Netlink socket.

This mechanism, with various iterations of the corresponding user
space code, has seen some limitations and issues:

* On systems with a large number of vports, there is correspondingly
a large number of Netlink sockets which can limit scaling.
(https://bugzilla.redhat.com/show_bug.cgi?id=1526306)
* Packet reordering on upcalls.
(https://bugzilla.redhat.com/show_bug.cgi?id=1844576)
* A thundering herd issue.
(https://bugzilla.redhat.com/show_bug.cgi?id=1834444)

This patch introduces an alternative, feature-negotiated, upcall
mode using a per-cpu dispatch rather than a per-vport dispatch.

In this mode, the Netlink socket to be used for the upcall is
selected based on the CPU of the thread that is executing the upcall.
In this way, it resolves the issues above as:

a) The number of Netlink sockets scales with the number of CPUs
rather than the number of vports.
b) Ordering per-flow is maintained as packets are distributed to
CPUs based on mechanisms such as RSS and flows are distributed
to a single user space thread.
c) Packets from a flow can only wake up one user space thread.

Reported-at: https://bugzilla.redhat.com/1844576
Signed-off-by: Mark Gray 
Acked-by: Flavio Leitner 
Acked-by: Aaron Conole 
Signed-off-by: Ilya Maximets

tunnel: Bareudp Tunnel Support.

2020-12-22T11:51:22+00:00

There are various L3 encapsulation standards using UDP being discussed to
leverage the UDP based load balancing capability of different networks.
MPLSoUDP (__ https://tools.ietf.org/html/rfc7510) is one among them.

The Bareudp tunnel provides a generic L3 encapsulation support for
tunnelling different L3 protocols like MPLS, IP, NSH etc. inside a UDP
tunnel.

An example to create bareudp device to tunnel MPLS traffic is
given

$ ovs-vsctl add-port br_mpls udp_port -- set interface udp_port \
             type=bareudp options:remote_ip=2.1.1.3
             options:local_ip=2.1.1.2 \
             options:payload_type=0x8847 options:dst_port=6635

The bareudp device supports special handling for MPLS & IP as
they can have multiple ethertypes. MPLS procotcol can have ethertypes
ETH_P_MPLS_UC (unicast) & ETH_P_MPLS_MC (multicast). IP protocol can have
ethertypes ETH_P_IP (v4) & ETH_P_IPV6 (v6).

The bareudp device to tunnel L3 traffic with multiple ethertypes
(MPLS & IP) can be created by passing the L3 protocol name as string in
the field payload_type. An example to create bareudp device to tunnel
MPLS unicast & multicast traffic is given below.::

$ ovs-vsctl add-port  br_mpls udp_port -- set interface
            udp_port \
            type=bareudp options:remote_ip=2.1.1.3
            options:local_ip=2.1.1.2 \
            options:payload_type=mpls options:dst_port=6635

Signed-off-by: Martin Varghese 
Acked-By: Greg Rose 
Tested-by: Greg Rose 
Acked-by: Eelco Chaudron 
Signed-off-by: Ilya Maximets

datapath: ovs_ct_exit to be done under ovs_lock

2020-11-27T13:31:27+00:00

Upstream commit:
    commit 27de77cec985233bdf6546437b9761853265c505
    Author: Tonghao Zhang 
    Date:   Fri Apr 17 02:57:31 2020 +0800

    net: openvswitch: ovs_ct_exit to be done under ovs_lock

    syzbot wrote:
    | =============================
    | WARNING: suspicious RCU usage
    | 5.7.0-rc1+ #45 Not tainted
    | -----------------------------
    | net/openvswitch/conntrack.c:1898 RCU-list traversed in non-reader section!!
    |
    | other info that might help us debug this:
    | rcu_scheduler_active = 2, debug_locks = 1
    | ...
    |
    | stack backtrace:
    | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
    | Workqueue: netns cleanup_net
    | Call Trace:
    | ...
    | ovs_ct_exit
    | ovs_exit_net
    | ops_exit_list.isra.7
    | cleanup_net
    | process_one_work
    | worker_thread

    To avoid that warning, invoke the ovs_ct_exit under ovs_lock and add
    lockdep_ovsl_is_held as optional lockdep expression.

    Link: https://lore.kernel.org/lkml/000000000000e642a905a0cbee6e@google.com
    Fixes: 11efd5cb04a1 ("openvswitch: Support conntrack zone limit")
    Cc: Pravin B Shelar 
    Cc: Yi-Hung Wei 
    Reported-by: syzbot+7ef50afd3a211f879112@syzkaller.appspotmail.com
    Signed-off-by: Tonghao Zhang 
    Acked-by: Pravin B Shelar 
    Signed-off-by: David S. Miller 

Cc: Tonghao Zhang 
Fixes: cb2a5486a3a3 ("datapath: conntrack: Support conntrack zone limit")
Signed-off-by: Greg Rose 
Acked-by: Tonghao Zhang 
Signed-off-by: Ilya Maximets