mirror of
https://github.com/torvalds/linux.git
synced 2024-11-08 21:21:47 +00:00
7f8a436eaa
Expose the kernel connection tracker via OVS. Userspace components can make use of the CT action to populate the connection state (ct_state) field for a flow. This state can be subsequently matched. Exposed connection states are OVS_CS_F_*: - NEW (0x01) - Beginning of a new connection. - ESTABLISHED (0x02) - Part of an existing connection. - RELATED (0x04) - Related to an established connection. - INVALID (0x20) - Could not track the connection for this packet. - REPLY_DIR (0x40) - This packet is in the reply direction for the flow. - TRACKED (0x80) - This packet has been sent through conntrack. When the CT action is executed by itself, it will send the packet through the connection tracker and populate the ct_state field with one or more of the connection state flags above. The CT action will always set the TRACKED bit. When the COMMIT flag is passed to the conntrack action, this specifies that information about the connection should be stored. This allows subsequent packets for the same (or related) connections to be correlated with this connection. Sending subsequent packets for the connection through conntrack allows the connection tracker to consider the packets as ESTABLISHED, RELATED, and/or REPLY_DIR. The CT action may optionally take a zone to track the flow within. This allows connections with the same 5-tuple to be kept logically separate from connections in other zones. If the zone is specified, then the "ct_zone" match field will be subsequently populated with the zone id. IP fragments are handled by transparently assembling them as part of the CT action. The maximum received unit (MRU) size is tracked so that refragmentation can occur during output. IP frag handling contributed by Andy Zhou. Based on original design by Justin Pettit. Signed-off-by: Joe Stringer <joestringer@nicira.com> Signed-off-by: Justin Pettit <jpettit@nicira.com> Signed-off-by: Andy Zhou <azhou@nicira.com> Acked-by: Thomas Graf <tgraf@suug.ch> Acked-by: Pravin B Shelar <pshelar@nicira.com> Signed-off-by: David S. Miller <davem@davemloft.net>
79 lines
2.3 KiB
Plaintext
79 lines
2.3 KiB
Plaintext
#
|
|
# Open vSwitch
|
|
#
|
|
|
|
config OPENVSWITCH
|
|
tristate "Open vSwitch"
|
|
depends on INET
|
|
select LIBCRC32C
|
|
select MPLS
|
|
select NET_MPLS_GSO
|
|
---help---
|
|
Open vSwitch is a multilayer Ethernet switch targeted at virtualized
|
|
environments. In addition to supporting a variety of features
|
|
expected in a traditional hardware switch, it enables fine-grained
|
|
programmatic extension and flow-based control of the network. This
|
|
control is useful in a wide variety of applications but is
|
|
particularly important in multi-server virtualization deployments,
|
|
which are often characterized by highly dynamic endpoints and the
|
|
need to maintain logical abstractions for multiple tenants.
|
|
|
|
The Open vSwitch datapath provides an in-kernel fast path for packet
|
|
forwarding. It is complemented by a userspace daemon, ovs-vswitchd,
|
|
which is able to accept configuration from a variety of sources and
|
|
translate it into packet processing rules.
|
|
|
|
See http://openvswitch.org for more information and userspace
|
|
utilities.
|
|
|
|
To compile this code as a module, choose M here: the module will be
|
|
called openvswitch.
|
|
|
|
If unsure, say N.
|
|
|
|
config OPENVSWITCH_CONNTRACK
|
|
bool "Open vSwitch conntrack action support"
|
|
depends on OPENVSWITCH
|
|
depends on NF_CONNTRACK
|
|
default OPENVSWITCH
|
|
---help---
|
|
If you say Y here, then Open vSwitch module will be able to pass
|
|
packets through conntrack.
|
|
|
|
Say N to exclude this support and reduce the binary size.
|
|
|
|
config OPENVSWITCH_GRE
|
|
tristate "Open vSwitch GRE tunneling support"
|
|
depends on OPENVSWITCH
|
|
depends on NET_IPGRE
|
|
default OPENVSWITCH
|
|
---help---
|
|
If you say Y here, then the Open vSwitch will be able create GRE
|
|
vport.
|
|
|
|
Say N to exclude this support and reduce the binary size.
|
|
|
|
If unsure, say Y.
|
|
|
|
config OPENVSWITCH_VXLAN
|
|
tristate "Open vSwitch VXLAN tunneling support"
|
|
depends on OPENVSWITCH
|
|
depends on VXLAN
|
|
default OPENVSWITCH
|
|
---help---
|
|
If you say Y here, then the Open vSwitch will be able create vxlan vport.
|
|
|
|
Say N to exclude this support and reduce the binary size.
|
|
|
|
If unsure, say Y.
|
|
|
|
config OPENVSWITCH_GENEVE
|
|
tristate "Open vSwitch Geneve tunneling support"
|
|
depends on OPENVSWITCH
|
|
depends on GENEVE_CORE
|
|
default OPENVSWITCH
|
|
---help---
|
|
If you say Y here, then the Open vSwitch will be able create geneve vport.
|
|
|
|
Say N to exclude this support and reduce the binary size.
|