Age | Commit message (Collapse) | Author | Files | Lines |
|
VPP sometimes takes some time to come up, this causes VPP interface detection
to fail. This patch adds retries for interface discovery so we can properly
identify state of VPP interfaces.
Also contains minor fixes for regex for VPP configs generation code to prevent
cases where we might edit configs that are commented out.
Change-Id: I915d5455acb8d496438b9c9e851639d3a43e6fa9
Signed-off-by: Feng Pan <fpan@redhat.com>
(cherry picked from commit 1c50db100a7b7ff797a5ab7e1a6f7567adeb658e)
|
|
The pci address of the DPDK NIC needs to be specified as dpdk-devargs
when adding the DPDK port. This is required for using DPDK with
OvS 2.7
Change-Id: I4975130961199ee04dd002ec987081299e3ddd4a
Closes-Bug: #1702457
Signed-off-by: Karthik S <ksundara@redhat.com>
|
|
|
|
Currently os-net_config will map nics from a user-supplied mapping file
only if the nic is active (operstate = up). This can cause problems
if a nic is in a bond and one of the bond's nics has no carrier.
This fix will map the nic from the mapping file if the nic is defined
on the system, regardless of the operstate status.
The fix implements a new function to return a list of available nics
(no check of operstate) for use if a mapping file is supplied. The
list of active nics must still be used in the default case when
numbering nics (no mapping file supplied). There is also some
cleanup to check if a user-supplied mac is in the mapping file before
attempting to convert the mac to a nic.
Change-Id: Ia5d8c8b49b7ac0b51ee42a754f06e5e53587a5f6
Closes-Bug: 1679787
|
|
Vector Packet Processing (VPP) is a high performance packet processing
stack that runs in user space in Linux. VPP is used as an alternative to
kernel networking stack for accelerated network data path. VPP uses DPDK
poll-mode drivers to bind system interfaces rather than kernel drivers.
VPP bound interfacees are not visible to kernel networking stack and
therefore require different configuration steps in os-net-config.
VPP interface will be used in Openstack by either Neutron ML2 driver
networking-vpp as an alternative to OVS, or by Opendaylight SDN
controller with Honeycomb agent.
This patch adds interface configuration support to os-net-config.
The kernel nic specified to be VPP interface type will be bound to
VPP with a DPDK poll-mode driver. Note that os-net-config will only
configure those settings that affect interface binding, all other
configurations for VPP will be configured throught TripleO Heat
Templates.
Implements: blueprint fdio-integration-tripleo
Change-Id: Iebb40b7c5b252c51e86b6f44bcf36ed206101390
Signed-off-by: Feng Pan <fpan@redhat.com>
|
|
SR-IOV Virtual Functions will be present as an interface in the
directory '/sys/class/net'. As these are virtual interface created
during the deployment process, it has to be ignored in the nic
numbering logic.
Closes-Bug: #1653097
Change-Id: I118a7314d496b531c52be45521d393123cdfe915
|
|
When using mapping file with mac address, mapping logic will try
to fetch the mac address of the interface, which will fail. Storing
the mac address also in the DPDK mapping file so that we can satisfy
mapping logic.
Closes-Bug: #1619330
Change-Id: I92ba7f589c8d848feb083f07c3f937b50aca388e
|
|
* os-net-config is called multiple times during the deploy.
Once the interface is bound to a driver, it will not be
listed for ethtool to get the pci address, which will
through exception. Handled this exception.
* Stored the DPDK bound nic configs at '/var/lib/os-net-config/
dpdk_mappings.yaml' file to emulate the same nic numbering
after the nic has been bound to the DPDK driver.
Partial-Bug: #1619330
Change-Id: I6b1e45003f851f1fcf5b8730890c75331e8d0f8f
|
|
This way device eth10 is after eth9, and not directly after eth1
Change-Id: I81eba97cccf6c4f314f9037d16ee1f244dbade02
Closes-Bug: #1482818
|
|
Implements a new active NIC abstraction and naming convention
that allows nic1, nic2, etc. to be translated to actual (active)
network device names like em1, em2 (or eth0, eth1).
This includes some logic to map ordered active nics to the
nic1, nic2 naming scheme. Embedded nics are always listed
first (in sort order) followed by any other active Nics
on the system.
With the new code:
{"type": "interface", "name": "nic1" }
is automatically translated (internally) to:
{"type": "interface", "name": "em1" }
This works for all top level "interface" devices, vlans, bonds, and
bridges alike. For vlans the 'device' name is translated instead
of the device name per vlan object conventions.
|