Age | Commit message (Collapse) | Author | Files | Lines |
|
more generic version of clib_sysfs_link_to_name with support for
format strings...
Type: improvement
Change-Id: I0cb263748970378c661415196eb7e08450370677
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Type: improvement
Change-Id: I4e2b2e4f227dfcb3df36166db13c8aa5c0b603f5
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
struct dirent *e is freed when calling closedir(). Use ifname instead.
Type: fix
Change-Id: Icc9ca52c33ecc1dee7a9e28802149e4e3e4c8ac0
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
now startup.conf supports confuguration for VMBUS
devices as for PCI devices for whitelisting/blacklisting
dpdk { dev fa5a6e7a-cf3a-4b98-9569-addb479b84bc }
with sub-configuration as for PCI devices
dpdk { blacklist fa5a6e7a-cf3a-4b98-9569-addb479b84bc }
where fa5a6e7a-cf3a-4b98-9569-addb479b84bc - example of UUID
struct vlib_vmbus_addr_t changed to union with UUID described
fields
Added device_config_index_by_vmbus_addr
blacklist_by_vmbus_addr
to enumerate available device configs
hash_key is as_u32[0] field(last 4 bytes of UUID)
Lost of precision against full UUID, but 2^32 is enough
to handle all the devices available
Added is_blacklisted check while creating vnet devices in
order to supress creation of dev if it's blacklisted
Type: feature
Signed-off-by: Vladimir Ratnikov <vratnikov@netgate.com>
Change-Id: Id82611e54fed082190e488c7e5fbe14ecbe5b2ab
|
|
The vlib init function subsystem now supports a mix of procedural and
formally-specified ordering constraints. We should eliminate procedural
knowledge wherever possible.
The following schemes are *roughly* equivalent:
static clib_error_t *init_runs_first (vlib_main_t *vm)
{
clib_error_t *error;
... do some stuff...
if ((error = vlib_call_init_function (init_runs_next)))
return error;
...
}
VLIB_INIT_FUNCTION (init_runs_first);
and
static clib_error_t *init_runs_first (vlib_main_t *vm)
{
... do some stuff...
}
VLIB_INIT_FUNCTION (init_runs_first) =
{
.runs_before = VLIB_INITS("init_runs_next"),
};
The first form will [most likely] call "init_runs_next" on the
spot. The second form means that "init_runs_first" runs before
"init_runs_next," possibly much earlier in the sequence.
Please DO NOT construct sets of init functions where A before B
actually means A *right before* B. It's not necessary - simply combine
A and B - and it leads to hugely annoying debugging exercises when
trying to switch from ad-hoc procedural ordering constraints to formal
ordering constraints.
Change-Id: I5e4353503bf43b4acb11a45fb33c79a5ade8426c
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: Ifd34aed8692d5acaa370d4976d974ac573e43705
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
If uio_hv_generic is not loaded, then the startup code will
fallback to the older failsafe/tap method of initialization
in DPDK. Therefore don't put out scary message in the log.
Also, reorder startup to avoid manipulating lower device until/unless
uio is going to work.
Change-Id: Ie1cc77b4b5359c04f00a93d01a772eccf3bbab37
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
|
|
VPP supports two DPDK drivers for managing netvsc devices on
Azure/Hyper-V. The new netvsc PMD looks a lot like other PCI-based
PMDs but it requires recently added kernel support (>=4.17). The
older vdev_netvsc is an abstraction that manages the mlx4 VF
and tap device underlying the netvsc interface using the failsafe PMD.
Distros with older kernels (e.g. RHEL/CentOS 7.x) have to use vdev_netvsc.
At startup, netvsc devices are processed and an attempt is made to
initialize them for management by the netvsc PMD. If that fails, then
vlib_vmbus_bind_to_uio() returns early and the device can be initialized
for management by vdev_netvsc.
The operation that is supposed to fail if the netvsc PMD cannot be used
is registration of the netvsc device type ID with the uio_hv_generic
driver. This operation is attempted exactly once so it does not fail
for netvsc devices processed after the first one and they end up in a
state where they cannot be initialized for use by vdev_netvsc.
Only unset uio_new_id_needed if uio_hv_generic registration succeeds.
Change-Id: I6be925d422b87ed24e0f4611304cc3a6b07a34fd
Signed-off-by: Matthew Smith <mgsmith@netgate.com>
|
|
The code that was manipulating interface names with ifreq was
causing warnings about possible truncation and non terminated
strings.
These are warnings only since kernel would allow a interface
name > 15 characters anyway.
Change-Id: I794a94fe310b8568403d4e3523c61d53468a6f02
Reported-by: Burt Silverman <burtms@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
|
|
This patch adds support for VMBus to the VPP infrastructure.
Since the only device that matters is the netvsc Poll Mode Driver
in DPDK, the infrastructure is much simpler than PCI.
Change-Id: Ie96c897ad9c426716c2398e4528688ce2217419b
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
|