Hi Ivan,
About enabling/disabling RSS dynamically (without dev_stop/dev_start):
As I know 82599 spec explicitly states that RSS shouldn't be enabled/disabled
dynamically.
>From section 7.1.2.8 Receive-Side Scaling (RSS):
"...
Enabling rules:
* RSS is enabled in the MRQC register.
* RSS enabling c
2014-05-01 09:14, Neil Horman:
> On Wed, Apr 30, 2014 at 02:46:41AM +0200, Thomas Monjalon wrote:
> > The goal of this patch serie is to be able to package DPDK
> > for RPM-based distributions.
> >
> > The file naming currently doesn't allow to install different DPDK
> > versions.
> > But the pack
2014-05-01 16:50, Neil Horman:
> On Wed, Apr 30, 2014 at 10:57:00PM +0200, Thomas Monjalon wrote:
> > If some DPDK libraries are installed on the system, the linker was trying
> > to use them before searching in -L path.
> > The obscure reason is that we were prefixing -L with -Wl, to pass it
> > d
2014-05-01 06:28, Neil Horman:
> On Thu, May 01, 2014 at 08:53:02AM +0200, Thomas Monjalon wrote:
> > 2014-04-30 11:22, Neil Horman:
> > > On Wed, Apr 30, 2014 at 01:09:38PM +0200, Thomas Monjalon wrote:
> > > > The 4 spec files are used to build 4 different git trees with their
> > > > own
> > > >
On Wed, Apr 30, 2014 at 10:57:00PM +0200, Thomas Monjalon wrote:
> If some DPDK libraries are installed on the system, the linker was trying
> to use them before searching in -L path.
> The obscure reason is that we were prefixing -L with -Wl, to pass it
> directly to the linker.
> But -L is also a
Hi David, Didier,
> + /* Set memory amount per socket; round up to be sure that
> sum of all */
> + /* sockets allocation is greater than requested memory size
> */
> + for (socket_id=0 ; socket_id socket_id++) {
> + internal_config.socket_me
> From: Didier Pallard
>
> In current version, coremask can only be specified using a bitmask.
> It will now be possible to specify core masks in 2 different ways:
> - Using a bitmask (-c 0xnnn): bitmask must be in hex format and start with 0x
> - Using a core set description in following format:
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk at oracle.com]
> Sent: Thursday, May 01, 2014 6:07 PM
> To: Samuel Monderer
> Cc: xen-devel at lists.xen.org; Shimon Zadok; Eyal Ben Saadon; Andrew
> Sergeev
> Subject: Re: [Xen-devel] dpdk kernel module when calling
>
On Thu, 1 May 2014 11:06:12 +
"Burakov, Anatoly" wrote:
>
> #
> +# Unloads VFIO modules.
> +#
> +remove_vfio_module()
> +{
> + echo "Unloading any existing VFIO module"
> + /sbin/lsmod | grep -s vfio > /dev/null
> + if [ $? -eq 0 ] ; then
> + sudo /sbin/rmmod vfio-p
Hi David,
> Looking at bsd implementation, we can see that there is a potential mem
> leak in linux implementation. Fix this.
>
> Signed-off-by: David Marchand
> ---
> lib/librte_eal/linuxapp/eal/eal_pci.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/librte_eal/linuxapp/eal/
Support for loading/unloading VFIO drivers, binding/unbinding
devices to/from VFIO, also setting up correct userspace permissions.
Signed-off-by: Anatoly Burakov
diff --git a/tools/setup.sh b/tools/setup.sh
index 39be8fc..2ffa55a 100755
--- a/tools/setup.sh
+++ b/tools/setup.sh
@@ -187,6 +187,52
Since igb_uio no longer has a PCI ID list, the script will no
longer distinguish between supported and unsupported NICs.
There's a weird behaviour of sysfs when a new device ID is added to
new_id. Subsequent writing to "bind" will result in IOError on
closing the file. This error is harmless but i
Note that since igb_uio no longer has a PCI ID list, it can now be
bound to any device, not just those explicitly supported by DPDK. In
other words, it now behaves similar to PCI stub, VFIO and other generic
PCI drivers.
Therefore to bind a new device to igb_uio, the user will now have to
first wr
Renaming the igb_uio_bind script to dpdk_nic_bind to have a generic
name since we're now supporting two drivers.
Signed-off-by: Anatoly Burakov
create mode 100755 tools/dpdk_nic_bind.py
delete mode 100755 tools/igb_uio_bind.py
diff --git a/tools/dpdk_nic_bind.py b/tools/dpdk_nic_bind.py
new f
Adding unit tests for VFIO interrupt type command-line parameter.
We don't know if VFIO is compiled (eal_vfio.h header is internal
to Linuxapp EAL), we check this flag regardless.
Also, quick-fixed a bug in base_virtaddr parsing that prevented it
from working (making unit test fail), will later in
Unlike igb_uio, VFIO interrupt type is not set by kernel module
parameters but is set up via ioctl() calls at runtime. This warrants
a new EAL command-line parameter. It will have no effect if VFIO is
not compiled, but will set VFIO interrupt type to either "legacy" or
"msix" if VFIO support is com
This makes it possible to run DPDK without hugepage memory when VFIO
is used, as VFIO uses virtual addresses to set up DMA mappings.
Signed-off-by: Anatoly Burakov
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
b/lib/librte_eal/linuxapp/eal/eal_memory.c
index 73a6394..b075145 100644
---
Add support for binding VFIO devices if RTE_PCI_DRV_NEED_IGB_UIO
is set for this driver. Try VFIO first, if not mapped then try
IGB_UIO too.
Signed-off-by: Anatoly Burakov
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index dc21645..3f659ff 100644
--
VFIO is kernel 3.6+ only, and so is only compiled when DPDK config
option CONFIG_RTE_EAL_VFIO is enabled, and kernel 3.6 or higher is
detected, thus preventing compile failures on older kernels if VFIO is
enabled in config (and it is, by default).
Since VFIO cannot be used to map the same device t
Creating code to handle VFIO interrupts in EAL interrupts, and also
adding a header eal_vfio.h.
This header checks two things:
* checks if CONFIG_RTE_EAL_VFIO was enabled during build time
* checks that kernel version is 3.6+ so that DPDK would still compile
on older kernels despite VFIO compila
Make VFIO compilation optional for all configs.
Signed-off-by: Anatoly Burakov
diff --git a/config/defconfig_i686-default-linuxapp-gcc
b/config/defconfig_i686-default-linuxapp-gcc
index ea90f12..5410f57 100644
--- a/config/defconfig_i686-default-linuxapp-gcc
+++ b/config/defconfig_i686-default-
Moving interrupt type enum out of igb_uio and renaming it to be more
generic. Such a strange header naming and separation is done mostly to
make coming virtio patches easier to port to dpdk.org tree.
Signed-off-by: Anatoly Burakov
create mode 100644 lib/librte_eal/common/include/rte_pci_dev_fea
Currently, igb_uio is always compiled. Since no Linux distribution
would want to include igb_uio by default or even with DPDK, we need
to make sure that igb_uio compilation can be optional (i.e. some
distributions could ship DPDK with VFIO support only).
Signed-off-by: Anatoly Burakov
diff --git
Rename the RTE_PCI_DRV_NEED_IGB_UIO to be more generic,
retain old macro for backwards compatibility. Probably should
be removed in one of the next releases.
Signed-off-by: Anatoly Burakov
diff --git a/app/test/test_pci.c b/app/test/test_pci.c
index 445cf57..e13f635 100644
--- a/app/test/test_pc
Currently, EAL does not distinguish between actual failures and
expected initialization errors. E.g. sometimes the driver fails to
initialize because it was not supposed to be initialized in the
first place, such as device not being managed by said driver.
This patch makes EAL fail on actual initi
In order to make the code a bit more clean while using multiple
drivers, IGB_UIO mapping has been separated into its own file.
Signed-off-by: Anatoly Burakov
create mode 100644 lib/librte_eal/linuxapp/eal/eal_pci_uio.c
create mode 100644 lib/librte_eal/linuxapp/eal/include/eal_pci_init.h
diff
This patchset adds support for using VFIO instead of IGB_UIO to
map the device BARs.
VFIO is a kernel 3.6+ driver allowing secure DMA from userspace
by means of using IOMMU instead of working directly with physical
memory like igb_uio does.
Short summary:
* Adding support for VFIO in EAL PCI code
* Stephen Hemminger (stephen at networkplumber.org) wrote:
> On Thu, 1 May 2014 11:05:38 +
> "Burakov, Anatoly" wrote:
>
> > This patchset adds support for using VFIO instead of IGB_UIO to
> > map the device BARs.
> >
> > VFIO is a kernel 3.6+ driver allowing secure DMA from userspace
> > by
On Wed, Apr 30, 2014 at 02:46:41AM +0200, Thomas Monjalon wrote:
> The goal of this patch serie is to be able to package DPDK
> for RPM-based distributions.
>
> The file naming currently doesn't allow to install different DPDK versions.
> But the packaging naming should be ready to manage differen
On Thu, 1 May 2014 11:05:38 +
"Burakov, Anatoly" wrote:
> This patchset adds support for using VFIO instead of IGB_UIO to
> map the device BARs.
>
> VFIO is a kernel 3.6+ driver allowing secure DMA from userspace
> by means of using IOMMU instead of working directly with physical
> memory li
2014-04-30 11:22, Neil Horman:
> On Wed, Apr 30, 2014 at 01:09:38PM +0200, Thomas Monjalon wrote:
> > The 4 spec files are used to build 4 different git trees with their own
> > versioning:
> > http://dpdk.org/browse
> >
> > So I think it's saner to keep them in their repository.
[...]
>
> Ye
On Thu, May 01, 2014 at 08:53:02AM +0200, Thomas Monjalon wrote:
> 2014-04-30 11:22, Neil Horman:
> > On Wed, Apr 30, 2014 at 01:09:38PM +0200, Thomas Monjalon wrote:
> > > The 4 spec files are used to build 4 different git trees with their own
> > > versioning:
> > > http://dpdk.org/browse
> > >
32 matches
Mail list logo
