With the rte_bus infrastructure present in 17.02 it is possible to refactor
the virtual device probing into a bus. This series also introduces the
rte_vdev_device to better keep track of devices.
This patchset depends on:
http://dpdk.org/dev/patchwork/patch/20416/
http://dpdk.org/dev/patchwork/pat
This is a refactoring of the virtual device probing which moves into into
a proper bus structure.
Signed-off-by: Jan Blunck
Tested-by: Ferruh Yigit
Acked-by: Shreyansh Jain
---
lib/librte_eal/common/eal_common_dev.c | 22 -
lib/librte_eal/common/eal_common_vdev.c | 58
Signed-off-by: Jan Blunck
Tested-by: Ferruh Yigit
Acked-by: Shreyansh Jain
---
lib/librte_eal/bsdapp/eal/eal.c | 3 ---
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 1 -
lib/librte_eal/common/eal_common_dev.c | 6 --
lib/librte_eal/common/include/rte_dev.h
Also see commit f4ce209a ("eal: postpone vdev initialization").
Signed-off-by: Jan Blunck
---
lib/librte_eal/common/eal_common_bus.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/common/eal_common_bus.c
b/lib/librte_eal/common/eal_common_bus
Make sure that the PCI devices are probed before the virtual devices after
the legacy virtual device probing has been moved to a bus.
Signed-off-by: Jan Blunck
Tested-by: Ferruh Yigit
Acked-by: Shreyansh Jain
---
lib/librte_eal/bsdapp/eal/eal.c | 8
lib/librte_eal/linuxapp/eal/eal.c
This is a preparation for the introduction of the struct rte_vdev_device.
Signed-off-by: Jan Blunck
Tested-by: Ferruh Yigit
Acked-by: Shreyansh Jain
---
lib/librte_eal/common/eal_common_vdev.c | 44 -
1 file changed, 33 insertions(+), 11 deletions(-)
diff --git
This adds the rte_vdev_device structure which embeds a generic rte_device.
Signed-off-by: Jan Blunck
Tested-by: Ferruh Yigit
Acked-by: Shreyansh Jain
---
lib/librte_eal/common/eal_common_vdev.c | 5 +
lib/librte_eal/common/include/rte_vdev.h | 5 +
2 files changed, 10 insertions(+)
d
This allows the virtual bus to be rescanned and probed by tracking the
creation of rte_vdev_device.
Signed-off-by: Jan Blunck
Tested-by: Ferruh Yigit
Acked-by: Shreyansh Jain
---
lib/librte_eal/common/eal_common_vdev.c | 195 +---
1 file changed, 155 insertions(+),
This is a preparation to embed the generic rte_device into the rte_eth_dev
also for virtual devices.
Signed-off-by: Jan Blunck
---
drivers/crypto/null/null_crypto_pmd.c | 18 --
drivers/net/af_packet/rte_eth_af_packet.c | 11 ++-
drivers/net/bonding/rte_eth_bond_pmd.c
This adds the rte_vdev_device_name() helper function to retrieve the
rte_vdev_device name which makes moving the name of the low-level
device into struct rte_device easier in the future.
Signed-off-by: Jan Blunck
Acked-by: Shreyansh Jain
---
lib/librte_eal/common/include/rte_vdev.h | 9
This adds the rte_vdev_device_args() helper function to prepare for
changing the virtual drivers probe() functions take a rte_vdev_device
pointer instead of the name+args strings.
Signed-off-by: Jan Blunck
---
lib/librte_eal/common/include/rte_vdev.h | 8
1 file changed, 8 insertions(+)
On 2/24/2017 9:11 PM, Trahe, Fiona wrote:
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Pablo de Lara
Sent: Thursday, February 23, 2017 12:34 PM
To: Doherty, Declan
Cc: dev@dpdk.org; De Lara Guarch, Pablo
Subject: [dpdk-dev] [PATCH 0/4] New crypto algorithm
Hi,
I sent a patchset to the to the mailing list last night for which I received
several coding style warnings. Having discovered that I was using an older
version of checkpatch.pl I downloaded the latest and set out to fix the
warnings. The tool is flagging the usage of PRIx64 and PRIu64 in
In many cases, it's enough to simply let the application know that the
call to initialize DPDK has failed. A complete halt can then be
decided by the application based on error returned (and the app could
even attempt a possible re-attempt after some corrective action by the
user or application).
When attempting to scan hugepages, signal to the eal.c that an error has
occurred, rather than performing a panic.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal_hugepage_info.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal
After this change, the EAL CPU NUMA node resolution step can no longer
emit an rte_panic. This aligns with the code in rte_eal_init, which
expects failures to return an error code.
Signed-off-by: Aaron Conole
---
lib/librte_eal/common/eal_common_lcore.c | 7 ---
1 file changed, 4 insertions
There may be no way to gracefully recover, but the application
should be notified that a failure happened, rather than completely
aborting. This allows the user to proceed with a "slow-path" type
solution.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 13 +++--
1 f
If we fail to acquire hugepage information, simply signal an error to
the application. This clears the run_once counter, allowing the user or
application to take a corrective action and retry.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 8 ++--
1 file changed, 6 inse
It's possible that the application could take a corrective action here,
and either prompt the user for different arguments, or at least perform
a better logging. Exiting this early prevents any useful information
gathering from the application layer.
Signed-off-by: Aaron Conole
---
lib/librte_e
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 0005ebc..beb786e 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_e
It's now possible to gracefully exit the application, or for
applications which support non-dpdk datapaths working in concert with
DPDK datapaths, there no longer is the possibility of exiting for
unsupported CPUs.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 6 +-
1 f
When memzone initialization fails, report the error to the calling
application rather than panic(). Without a good way of detaching /
releasing hugepages, at this point the application will have to restart.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 7 +--
1 file ch
This adds a new API to check for the eal cpu versions.
Signed-off-by: Aaron Conole
---
lib/librte_eal/common/eal_common_cpuflags.c | 13 +++--
lib/librte_eal/common/include/generic/rte_cpuflags.h | 9 +
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/lib
When log initialization fails, it's generally because the fopencookie
failed. While this is rare in practice, it could happen, and it is
likely because of memory pressure. So, flag the error, and allow the
user to retry.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 8 +++
This can only happen when access to hugepages (either as primary or
secondary process) fails (and that is usually permissions). Since the
manner of failure is not reversible, we cannot allow retry.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 7 +--
1 file changed, 5
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 5534b4b..0e7e8c8 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/libr
rte_eal_alarm_init() call uses the linux timerfd framework to create a
poll()-able timer using standard posix file operations. This could fail
for a few reasons given in the man-pages, but many could be
corrected by the user application. No need to panic.
Signed-off-by: Aaron Conole
---
lib/li
There are some theoretical racy conditions in the system that _could_
cause early tailq init to fail; however, no need to panic the
application. While it can't continue using DPDK, it could make better
alerts to the user.
Signed-off-by: Aaron Conole
---
lib/librte_eal/common/eal_common_tailqs.
After code inspection, there is no way for eal_timer_init() to fail. It
simply returns 0 in all cases. As such, this test could either go-away
or stay here as 'future-proofing'.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 7 +--
1 file changed, 5 insertions(+), 2 de
This will usually be an issue because of permissions. However, it could
also be caused by OOM. In either case, errno will contain the
underlying cause. It is safe to re-init the system here, so allow the
application to take corrective action and reinit.
Signed-off-by: Aaron Conole
---
lib/lib
When initializing the interrupt thread, there are a number of possible
reasons for failure - some of which are correctable by the application.
Do not panic() needlessly, and give the application a change to reflect
this information to the user.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linu
Plugins are useful and important. However, it seems crazy to abort
everything just because they don't initialize properly.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/l
There could be some confusion as to why the call failed - this change
will always reflect the value of the error in rte_error.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal_interrupts.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/linux
Some devices may be inaccessible for a variety of reasons, or the
PCI-bus may be unavailable causing the whole thing to fail. Still,
better to continue attempts at probes.
Signed-off-by: Aaron Conole
---
lib/librte_eal/common/eal_common_pci.c | 15 ++-
1 file changed, 10 insertions(
It may even be possible to simply log the error and continue on letting
the user check the logs and restart the application when things are failed.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/lib
Seems like it's possible to continue. At least, the error is reflected
properly in the logs. A user could then go and correct or investigate
the situation.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/
Even if one vdev should fail, there's no need to prevent further
processing. Log the error, and reflect it to the higher levels to
decide.
Signed-off-by: Aaron Conole
---
lib/librte_eal/common/eal_common_dev.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/librte_e
For now, do an abort. It's likely that even aborting the initialization
is premature in this case, as it may be possible to proceed even if one
bus or another is not available.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 7 +--
1 file changed, 5 insertions(+), 2 dele
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 803cdd2..c94ac9b 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librt
The rte_eal_init function will now pass failure reason hints to the
application. To help app developers deciper this, add some brief
information about what the codes are indicating.
Signed-off-by: Aaron Conole
---
lib/librte_eal/common/include/rte_eal.h | 27 ++-
1 file
On Thursday 23 February 2017 08:05 PM, Ferruh Yigit wrote:
> On 2/21/2017 9:27 AM, Shijith Thotton wrote:
>> Added doc/guides/nics/liquidio.rst and
>> doc/guides/nics/features/liquidio.ini. Updated release notes.
>>
>> Signed-off-by: Shijith Thotton
>> Signed-off-by: Jerin Jacob
>> Signed-off-b
In vmxnet3 version 3, the emulation added support for the vmxnet3 driver
to communicate information about the memory regions the driver will use
for rx/tx buffers. The driver can also indicate which rx/tx queue the
memory region is applicable for. If this information is communicated
to the emulatio
vmxnet3 driver preallocates buffers for receiving packets and posts the
buffers to the emulation. In order to deliver a received packet to the
guest, the emulation must map buffer(s) and copy the packet into it.
To avoid this memory mapping overhead, this patch introduces the receive
data ring - a
vmxnet3 driver supports transmit data ring viz. a set of fixed size
buffers used by the driver to copy packet headers. Small packets that
fit these buffers are copied into these buffers entirely.
Currently this buffer size of fixed at 128 bytes. This patch extends
transmit data ring implementation
Shared memory is used to exchange information between the vmxnet3 driver
and the emulation. In order to request emulation to perform a task, the
driver first populates specific fields in this shared memory and then
issues corresponding command by writing to the command register(CMD). The
layout of
This command is reserved.
Signed-off-by: Shrikrishna Khare
Acked-by: Yong Wang
Acked-by: Jin Heo
---
drivers/net/vmxnet3/base/vmxnet3_defs.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/vmxnet3/base/vmxnet3_defs.h
b/drivers/net/vmxnet3/base/vmxnet3_defs.h
Cleanup some code in preparation of vmxnet3 version 3 changes.
Signed-off-by: Shrikrishna Khare
Acked-by: Yong Wang
Acked-by: Jin Heo
---
drivers/net/vmxnet3/vmxnet3_ethdev.c | 17 +
drivers/net/vmxnet3/vmxnet3_ethdev.h | 9 +
2 files changed, 22 insertions(+), 4 delet
vmxnet3 emulation has recently added several new features which includes
support for new commands the driver can issue to emulation, change in
descriptor fields etc. This patch series extends the vmxnet3 driver to
leverage these new features.
Compatibility is maintained using existing vmxnet3 vers
With all vmxnet3 version 3 changes incorporated in the vmxnet3 driver,
the driver can configure emulation to run at vmxnet3 version 3, provided
the emulation advertises support for version 3.
Signed-off-by: Shrikrishna Khare
Acked-by: Yong Wang
Acked-by: Jin Heo
---
drivers/net/vmxnet3/vmxnet3
49 matches
Mail list logo
