dnf5 requires the group ID (e.g., development-tools) rather than the group
name (e.g., Development Tools) used in previous versions of dnf and in yum.
Updated documentation to reflect this change.
Signed-off-by: Timothy Redaelli <tredaelli@redhat.com>
Acked-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Kevin Traynor <ktraynor@redhat.com>
Remove documentation relating to OOT kernel module.
Support for the OOT module was removed in the v3.0 release of Open vSwitch.
And is now no longer supported by any maintained versions of Open vSwitch.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Simon Horman <horms@ovn.org>
Remove documentation relating to kernel module installation options for
Debian as the only option should now be to use the module supplied
by the Linux kernel.
Support for the OOT module was removed in the v3.0 release of Open vSwitch.
And is now no longer supported by any maintained versions of Open vSwitch.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Simon Horman <horms@ovn.org>
STT and LISP tunnel types were deprecated and marked for removal in
the following commits in the OVS 3.5 release:
3b37a6154a ("netdev-vport: Deprecate STT tunnel port type.")
8d7ac031c0 ("netdev-vport: Deprecate LISP tunnel port type.")
Main reasons were that STT was rejected in upstream kernel and the
LISP was never upstreamed as well and doesn't really have a supported
implementation. Both protocols also appear to have lost their former
relevance.
Removing both now. While at it, also fixing some small documentation
issues and comments.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Acked-by: Alin Serdean <aserdean@ovn.org>
Acked-by: Kevin Traynor <ktraynor@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
All the ssl.OP_NO_* options are deprecated since OpenSSL 1.1.0.
Use minimum/maximum_version configuration instead.
Unfortunately, those only available in Python 3.7, so increasing
the minimal supported Python version. Python 3.7+ should be
available in most modern distributions. It is also EoL at this
point, but there is no need to require higher versions.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The check is still looking for Pythn 3.4, instead of 3.6.
Also, RHEL documentation points to EPEL for RHEL 6, but it
only contains Python 3.4, so remove the pointer.
Fixes: 4d55a364ff ("python: Add async DNS support.")
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
SSL protocol family is not actually being used or supported in OVS.
What we use is actually TLS.
Terms "SSL" and "TLS" are often used interchangeably in modern
software and refer to the same thing, which is normally just TLS.
Let's replace "SSL" with "SSL/TLS" in documentation and user-visible
messages, where it makes sense. This may make it more clear what
is meant for a less experienced user that may look for TLS support
in OVS and not find much.
We're not changing any actual code, because, for example, most of
OpenSSL APIs are using just SSL, for historical reasons. And our
database is using "SSL" table. We may consider migrating to "TLS"
naming for user-visible configuration like command line arguments
and database names, but that will require extra work on making sure
upgrades can still work. In general, a slightly more clear
documentation should be enough for now, especially since term SSL
is still widely used in the industry.
"SSL/TLS" is chosen over "TLS/SSL" simply because our user-visible
configuration knobs are using "SSL" naming, e.g. '--ssl-cyphers'
or 'ovs-vsctl set-ssl'. So, it might be less confusing this way.
We may switch that, if we decide on re-working the user-visible
commands towards "TLS" naming, or providing both alternatives.
Some other projects did similar changes. For example, the python ssl
library is now using "TLS/SSL" in the documentation whenever possible.
Same goes for OpenSSL itself.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
STT tunnel implementation was rejected in the upstream Linux kernel
long time ago and will probably never be there. So, the only
implementation for Linux is in the OOT kernel module shipped with
OVS 2.17. It is deprecated and will reach end of life in Feb 2025.
In addition, modern network interface cards support various hardware
offload features with UDP tunnels, diminishing the main selling point
of STT - the ability to reuse hardware offload features meant for TCP.
Deprecate the port type now, so it can be removed once 2.17 is EoL.
There is another implementation for this tunnel type in the Windows
datapath. However, the protocol itself is considered harmful as it
may confuse stateful network hardware by pretending to be TCP (hence
the reason it was rejected in the Linux kernel). So, it is better if
we deprecate this implementation and stop supporting it as well.
The standard draft for the protocol itself is also expired and
archived with the latest update made in 2016:
https://datatracker.ietf.org/doc/draft-davie-stt/
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This patch replaces all remaining uses of wget with curl to
ensure a consistent tool across all tests.
It also removes the wget dependency from the documentation,
and CI.
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Acked-by: Simon Horman <horms@ovn.org>
The previously enabled 'hacking' checks were only applicable to Python 2
code. OVS doesn't support Python 2 for a while now so it's fine to
remove the dependency on hacking.
A similar change landed in OVN a while ago:
https://github.com/ovn-org/ovn/commit/271186fa7d76
Acked-by: Simon Horman <horms@ovn.org>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Recently OVS adopted a policy of using the inclusive naming word list v1
[1, 2].
In keeping with this policy rename the primary development branch from
'master' to 'main'. This patch does not actually make that change, but
rather updates references to the branch in documentation in the source
tree. It is intended to be applied at (approximately) the same time
that the change is made.
OVS is currently hosted on GitHub. We can expect the following behaviour
after the rename:
1. GitHub pull requests against are renamed branch are automatically
re-homed on new branch
2. GitHub Issues do not seem to be affected - at least the test issue I
created had no association with a branch
3. URLs accessed via the GitHub web UI are automatically renamed
(so long as a new branch called master is not created).
4. Using the git cli command, fetch will fetch the new branch (main),
and fetch -p will remove (prune) the old branch (master)
[1] df5e5cf431 ("Documentation: Add section on inclusive language.")
[2] https://inclusivenaming.org/word-lists/
Signed-off-by: Simon Horman <horms@ovn.org>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Acked-by: Ilya Maximets <i.maximets@ovn.org>
---
Notes:
* Now is the time to raise any concerns regarding this patch.
It is planned to implement this change next week.
* If you have an automation that fetches the master branch then
the suggested action is:
1. Before the branch rename occurs: update the automation to pull main an
fall back to pulling master if that fails
2. After the rename occurs: Update the automation to only fetch main
* After the change it may be necessary to update your local
git configuration for checked out branches.
For example:
# Fetch origin: new remote main branch; remote master branch is deleted
git fetch -tp origin
# Rename local branch
git branch -m master main
# Update local main branch to use remote main branch as it's upstream
git branch --set-upstream-to=origin/main main
* As a follow-up, after the rename, I plan to post a patch which removes
references to master in CI jobs
Recently OVS adopted a policy of using the inclusive naming word list v1
[1, 2].
This patch addresses the use of the term master repository by
using the term main repository instead.
This is as distinct from addressing the use of a master branch,
which remains as a follow-up task.
[1] df5e5cf ("Documentation: Add section on inclusive language.")
[2] https://inclusivenaming.org/word-lists/
Signed-off-by: Simon Horman <horms@ovn.org>
Acked-by: Kevin Traynor <ktraynor@redhat.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
OpenSSL 1.1.0 changed the library names from libeay32 and ssleay32 to
standard libssl and libcrypto. All the versions of OpenSSL that used
old names reached their official EoL, so it should be safe to just
migrate to new names. They can still be supported via premium support
option, but I don't think that is important for us.
Also, OpenSSL installers for older versions had the following folder
structure:
C:\OPENSSL-WIN64\
+---bin
+---include
| +---openssl
+---lib
| libeay32.lib
| ssleay32.lib
+---VC
libeay32MD.lib
libeay32MDd.lib
libeay32MT.lib
libeay32MTd.lib
ssleay32MD.lib
ssleay32MDd.lib
ssleay32MT.lib
ssleay32MTd.lib
With newer OpenSSL 3+ the structure is different:
C:\OPENSSL-WIN64
+---bin
+---include
| +---openssl
+---lib
+---VC
+---x64
+---MD
| libcrypto.lib
| libssl.lib
+---MDd
| libcrypto.lib
| libssl.lib
+---MT
| libcrypto.lib
| libssl.lib
+---MTd
libcrypto.lib
libssl.lib
Basically, instead of one generic library in the lib folder and a bunch
of differently named versions of it for different type of linkage, we
now have multiple instances of the library located in different folders
based on the linkage type. So, we have to provide an exact path in
order to find the library.
'lib/VC/x64/MT' was chosen in this patch since it is a way used for
building in build-aux/ccl.
MD stands for dynamic linking, MT is static, 'd' stands for debug
versions of the libraries.
While at it, fixing documentation examples to point to Win64 default
installation folder.
Acked-by: Simon Horman <horms@ovn.org>
Acked-by: Alin-Gabriel Serdean <aserdean@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Correct spelling errors in .rst files flagged by codespell.
Also correct some minor grammar errors in nearby documentation.
Signed-off-by: Simon Horman <horms@ovn.org>
Acked-by: Mike Pattrick <mkp@redhat.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
For better usability, the function pairs get_config() and
set_config() for netdevs should be symmetric: Options which are
accepted by set_config() should be returned by get_config() and the
latter should output valid options for set_config() only. This patch
also moves key-value pairs which are not valid options from get_config()
to the get_status() callback.
The documentation in vswitchd/vswitch.xml for status columns has been
updated accordingly.
Reported-at: https://bugzilla.redhat.com/1949855
Signed-off-by: Jakob Meng <code@jakobmeng.de>
Signed-off-by: Kevin Traynor <ktraynor@redhat.com>
This adds a Python version of the async DNS support added in:
771680d96 DNS: Add basic support for asynchronous DNS resolving
The above version uses the unbound C library, and this
implimentation uses the SWIG-wrapped Python version of that.
In the event that the Python unbound library is not available,
a warning will be logged and the resolve() method will just
return None. For the case where inet_parse_active() is passed
an IP address, it will not try to resolve it, so existing
behavior should be preserved in the case that the unbound
library is unavailable.
Intentional differences from the C version are as follows:
OVS_HOSTS_FILE environment variable can bet set to override
the system 'hosts' file. This is primarily to allow testing to
be done without requiring network connectivity.
Since resolution can still be done via hosts file lookup, DNS
lookups are not disabled when resolv.conf cannot be loaded.
The Python socket_util module has fallen behind its C equivalent.
The bare minimum change was done to inet_parse_active() to support
sync/async dns, as there is no equivalent to
parse_sockaddr_components(), inet_parse_passive(), etc. A TODO
was added to bring socket_util.py up to equivalency to the C
version.
Signed-off-by: Terry Wilson <twilson@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Sphinx linkcheck complains with:
Warning, treated as error:
.../Documentation/intro/install/windows.rst:1093:broken link:
www.appveyor.com ()
Add a https scheme in link to AppVeyor website.
Signed-off-by: David Marchand <david.marchand@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
With this change we will try to detect all the netdev-afxdp
dependencies and enable AF_XDP support by default if they are
present at the build time.
Configuration script behaves in a following way:
- ./configure --enable-afxdp
Will check for AF_XDP dependencies and fail if they are
not available.
- ./configure --disable-afxdp
Disables checking for AF_XDP. Build will not support
AF_XDP even if all dependencies are installed.
- Just ./configure or ./configure --enable-afxdp=auto
Will check for AF_XDP dependencies. Will print a warning
if they are not available, but will continue without AF_XDP
support. If dependencies are available in a system, this
option is equal to --enable-afxdp.
'--disable-afxdp' added to the debian and fedora package builds
to keep predictable behavior.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Necessary bits was removed from the kernel's libbpf in 6.0 release,
so the instructions on how to build libbpf from kernel sources are
now incorrect. Suggest to use libbpf and libxdp packaged by
distributions instead.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
There was a small typo that slipped in when updating to v22.11.1 tag.
Fixes: a77c7796f2 ("dpdk: Update to use v22.11.1.")
Signed-off-by: David Marchand <david.marchand@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Update OVS CLI and relevant documentation to use DPDK 21.11.2.
DPDK 21.11.2 contains fixes for the CVEs listed below:
CVE-2022-28199 [1]
CVE-2022-2132 [2]
A bug was introduced in DPDK 21.11.1 by the commit
01e3dee29c02 ("vhost: fix unsafe vring addresses modifications").
This bug can cause a deadlock when vIOMMU is enabled and NUMA
reallocation of the virtqueues happen.
A fix [3] has been posted and pushed to the DPDK 21.11 branch.
If a user wishes to avoid the issue then it is recommended to use
DPDK 21.11.0 until the release of DPDK 21.11.3.
It should be noted that DPDK 21.11.0 does not benefit from the
numerous bug and CVE fixes addressed since its release.
If a user wishes to benefit from these fixes it is recommended to
use DPDK 21.11.2.
[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28199
[2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2132
[3] https://patches.dpdk.org/project/dpdk/patch/20220725203206.427083-2-david.marchand@redhat.com/
Signed-off-by: Michael Phelan <michael.phelan@intel.com>
Acked-by: Kevin Traynor <ktraynor@redhat.com>
Signed-off-by: Ian Stokes <ian.stokes@intel.com>
This patch mainly support alg field in ct action when process
ftp/tftp traffic. Tftp with alg mainly parse the tftp packet
(IPv4/IPv6), extract connect info from the tftp packet and
create the related connection. For ftp, previous version has
supported process of ftp traffic. However, previous version
regard traffic from or to port 21 as ftp traffic, this is
incorrect in some scenario. This version adds alg field in ct for
ftp traffic, we could use ct(alg=ftp) to process any ftp traffic
from/to any port.
IPv4/IPv6.
Test cases:
1) ftp ipv4/ipv6 use alg field in the normal and nat scenario.
2) tftp ipv4/ipv6 use alg field in the normal and nat scenario.
Signed-off-by: ldejing <ldejing@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
As of Open vSwitch release 2.18 the OVS kernel module is no longer
supported. Pull the documentation references.
Reviewed-by: David Marchand <david.marchand@redhat.com>
Signed-off-by: Greg Rose <gvrose8192@gmail.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
On the back of changing the debian/ubuntu packaging, update the
docs to refer to existing packages.
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Modify ci linux build script to use the latest DPDK stable release 21.11.1.
Modify Documentation to use the latest DPDK stable release 21.11.1.
Update NEWS file to reflect the latest DPDK stable release 21.11.1.
FAQ is updated to reflect the latest DPDK for each OVS branch.
Signed-off-by: Michael Phelan <michael.phelan@intel.com>
Acked-by: Kevin Traynor <ktraynor@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Implementation on Windows:
Currently, IPv4 conntrack was supported on the windows platform.
In this patch we have implemented ipv6 conntrack functions according
to the current logic of the IPv4 conntrack. This implementation has
included TcpV6(nat and normal scenario), UdpV6(nat and normal scenario),
IcmpV6 conntrack of echo request/reply packet and
FtpV6(nat and normal scenario).
Testing Topology:
On the Windows VM runs on the ESXi host, two hyper-v ports attached
to the ovs bridge; one hyper-v port worked as client and the
other port worked as server.
Testing Case:
1. TcpV6
a) Tcp request/reply conntrack for normal scenario.
In this scenario, 20::1 as client, 20::2 as server, it will generate
following conntrack entry:
(Origin(src=20::1, src_port=1555, dst=20::2, dst_port=1556),
reply(src=20::2,src_port=1556,dst=20::1,dst_port=1555),protocol=tcp)
b) Tcp request/reply conntrack for nat scenario.
In this scenario, 20::1 as client, 20::10 as floating ip, 21::3 as server,
it will generate following conntrack entry:
(Origin(src=20::1, src_port=1555, dst=20::10, dst_port=1556),
reply(src=21::3, src_port=1556, dst=20::1, dst_port= 1555),protocol=tcp)
2. UdpV6
a) Udp request/reply conntrack for normal scenario.
(Origin(src=20::1, src_port=1555, dst=20::2, dst_port=1556),
reply(src=20::2,src_port=1556,dst=20::1,dst_port=1555),protocol=udp)
b) Udp request/reply conntrack for nat scenario.
(Origin(src=20::1, src_port=1555, dst=20::10, dst_port=1556),
reply(src=21::3, src_port=1556, dst=20::1, dst_port= 1555),protocol=udp)
3. IcmpV6:
a) Icmpv6 request/reply conntrack for normal scenario.
Currently Icmpv6 only support to construct conntrack for
echo request/reply packet, take (20::1 -> 20::2) for example,
it will generate following conntrack entry:
(origin(src = 20::1, dst=20::2), reply(src=20::2, dst=20::1), protocol=icmp)
b) Icmp request/reply conntrack for dnat scenario,
for example (20::1->20::10->21::3), 20::1 is
client, 20::10 is floating ip, 21::3 is server ip.
It will generate flow like below:
(origin(src=20::1, dst=20::10), reply(src=21::3, dst=20::1), protocol=icmp)
4. FtpV6
a) Ftp request/reply conntrack for normal scenario.
In this scenario, take 20::1 as client, 20::2 as server, it will generate
two conntrack entries:
Ftp active mode
(Origin(src=20::1, src_port=1555, dst=20::2, dst_port=21),
reply(src=20::2, src_port=21, dst=20::1, dst_port=1555), protocol=tcp)
(Origin(src=20::2, src_port=20, dst=20::1, dst_port=1556),
reply(src=20::1, src_port=1556, dst=20::2, dst_port=20), protocol=tcp)
Ftp passive mode
(Origin(src=20::1, src_port=1555, dst=20::2, dst_port=21),
reply(src=20::2,src_port=21,dst=20::1,dst_port=1555),protocol=tcp)
(Origin(src=20::1, src_port=1556, dst=20::2, dst_port=1557),
reply(src=20::2,src_port=1557, dst=20::1, dst_port=1556) protocol=tcp)
b) Ftp request/reply conntrack for nat scenario.
Ftp passive mode,
In this secnario, 20::1 as client, 20::10 as floating ip, 21::3 as server
ip. It will generate following flow:
(Origin(src=20::1, src_port=1555, dst=20::10, dst_port=21),
reply(src=21::3, src_port=21, dst=20::1, dst_port= 1555),protocol=tcp)
(Origin(src=20::1, src_port=1556, dst=20::10, dst_port=1557),
reply(src=21::3, src_port=1557, dst=20::1, dst_port= 1556),protocol=tcp)
5. Regression test for IpV4 in Antrea project (about 60 test case)
Future work:
1) IcmpV6 redirect packet conntrack.
2) IpV6 fragment support on Udp.
3) Support napt for IPv6.
4) FtpV6 active mode for nat.
Signed-off-by: ldejing <ldejing@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
In the first step OVS Windows will support IPv6 tunnel(Geneve IPv6 tunnel).
Implementation on Windows
-------------------------
1. For the IPv6 tunnel support, OvsIPTunnelKey will replace original
OvsIPv4TunnelKey in the related flow context handing.
2. The related src and dst address will be changed to SOCKADDR_INET type from UINT32.
3. For the IPv6 tunnel, one node running OVS-Windows could encapsulate IPv4/IPv6
Packets via IPV6 Geneve Tunnel, and the node could also encapsulate IPv4/IPv6 packet
Via IPv4 Geneve tunnel.
4. Related IPHelper data structure will be adapted to support IPv6 Tunnel. In the IPHelper
part the related Windows API(such as GetUnicastIpAddressTable/GetBestRoute2/GetIpNetEntry2/
ResolveIpNetEntry2) and Windows data structure(MIB_IPFORWARD_ROW2/MIB_IPNET_ROW2/IP_ADDRESS_PREFIX)
Have already supported both IPv4 and IPV6. Now OVS Windows has been adjusted some functions
And data structured to support IPV6 tunnel also.
5. OVS_TUNNEL_KEY_ATTR_IPV6_SRC and OVS_TUNNEL_KEY_ATTR_IPV6_DST filed will be supported in
OVS-Windows kernel for IPV6 tunnel.
Testing done.
-------------------------
Related topo, 1 Windows VM(Win2019) and 2 Ubuntu 16.04 server. Both VMs
Are running on one ESX host.
1. Setup one IPV6 Geneve Tunnel between 1 Windows VM and 1 Ubuntu server.
Windows VM, vif0( 6000::2/40.1.1.10) vif1(5000::2)—— Ubuntu VM Eth2(5000::9), name space ns1
with interface ns1_link_peer(6000::9/40.1.1.2)
Related tunnnel,
ovs-vsctl.exe add-port br-int bms-tun0 -- set interface bms-tun0 type=Geneve options:csum=true
options:key=flow options:local_ip="5000::2" options:remote_ip=flow
In this topo, traffic from Vif0(Win) to ns1_link_peer(Ubuntu) will be gone through the Geneve tunnel
(5000::2—>5000::9) for both IPv4 traffic(40.1.1.10-->40.1.1.2) and IPv6 traffic(6000::2—>6000::9)
2. Setup one IPV4 Geneve Tunnel between Windows VM and 1 Ubuntu server.
Windows VM, vif0( 6000::2/40.1.1.10) vif1(50.1.1.11)—— Ubuntu, Eth2(50.1.1.9), name space ns1
with interface ns1_link_peer(6000::19/40.1.1.9)
Related tunnnel,
ovs-vsctl.exe -- set Interface bms-tun0 type=geneve options:csum=true options:key=flow
options:local_ip="50.1.1.11" options:remote_ip=flow
In this topo, traffic from Vif0(Win) to ns1_link_peer(Ubuntu) will be gone through the Geneve Tunnel
(50.1.1.11—>50.1.1.9) for both IPv4 traffic(40.1.1.10-->40.1.1.9) and IPv6 traffic(6000::2—>6000::19).
3.Regression test for IpV4 in Antrea project (about 60 test case) is PASS
Future Work
-----------
Add other type IPv6 tunnel support for Gre/Vxlan/Stt.
Signed-off-by: Wilson Peng <pweisong@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
It seems versions older than 0.6.2 generate false positives. Bump the
recommended version and make sure we use the right headers from the ovs
tree.
Suggested-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This commit adds support for DPDK v21.11, it includes the following
changes.
1. ci: Install python elftools for DPDK 21.02.
2. ci: Update meson requirement for DPDK 21.05.
3. netdev-dpdk: Fix build with 21.05.
4. ci: Compile DPDK in non developer mode.
http://patchwork.ozlabs.org/project/openvswitch/list/?series=242480&state=*
5. netdev-dpdk: Remove access to DPDK internals.
6. netdev-dpdk: Remove unused attribute from rte_flow rule.
7. netdev-dpdk: Fix mbuf macros namespace with 21.11-rc1.
8. netdev-dpdk: Fix vhost namespace with 21.11-rc2.
http://patchwork.ozlabs.org/project/openvswitch/list/?series=271159&state=*
In addition documentation and DPDK unit tests were also updated in this
commit for use with DPDK v21.11.
For credit all authors of the original commits to 'dpdk-latest' with the above
changes have been added as co-authors for this commit.
Signed-off-by: David Marchand <david.marchand@redhat.com>
Co-authored-by: David Marchand <david.marchand@redhat.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Tested-by: Emma Finn <emma.finn"intel.com>
Tested-by: Seamus Ryan <seamus.ryan@intel.com>
Acked-by: Kevin Traynor <ktraynor@redhat.com>
Signed-off-by: Ian Stokes <ian.stokes@intel.com>
dpdkvhostuser ports are deprecated, but are still being recommended to
users through the documentation. Fix this.
Signed-off-by: Cian Ferriter <cian.ferriter@intel.com>
Acked-by: Kevin Traynor <ktraynor@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Directly copying the CMD from either the .rst file or the docs on the
web caused errors in the QEMU command because of how it was wrapped.
Signed-off-by: Cian Ferriter <cian.ferriter@intel.com>
Acked-by: Kevin Traynor <ktraynor@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This change removes the default values for EAL args socket-mem and
socket-limit. As DPDK supports dynamic memory allocation, there is no
need to allocate a certain amount of memory on start-up, nor limit the
amount of memory available, if not requested.
Currently, socket-mem has a default value of 1024 when it is not
configured by the user, and socket-limit takes on the value of
socket-mem, 1024, by default. With this change, socket-mem is not
configured by default, meaning that socket-limit is not either.
Neither, either or both options can be set.
Removed extra logs that announce this change and fixed documentation.
Reported at: https://bugzilla.redhat.com/show_bug.cgi?id=1949850
Signed-off-by: Rosemarie O'Riorden <roriorde@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Deprecate current OVS provided defaults for DPDK socket-mem and
socket-limit that are planned to be removed in OVS 2.17. At that point
DPDK defaults will be used instead. Warnings have been added to alert
users in advance.
Signed-off-by: Rosemarie O'Riorden <roriorde@redhat.com>
Acked-by: Kevin Traynor <ktraynor@redhat.com>
Signed-off-by: Ian Stokes <ian.stokes@intel.com>
