On Wed, Oct 3, 2018 at 1:56 PM Burakov, Anatoly
wrote:
> On 31-Aug-18 1:50 PM, Alejandro Lucero wrote:
> > Although VT-d emulation currently only supports 39 bits, it could
> > be iovas being within that supported range. This patch allows
> > IOVA mode in such a case.
&
On Thu, Oct 4, 2018 at 4:39 PM Burakov, Anatoly
wrote:
> On 04-Oct-18 1:59 PM, Alejandro Lucero wrote:
> > I sent this email only to Anatoly. Sending it again to mailing list.
> >
> > On Wed, Oct 3, 2018 at 1:43 PM Burakov, Anatoly <
> anatoly.bura...@intel.com>
&g
On Thu, Oct 4, 2018 at 4:43 PM Burakov, Anatoly
wrote:
> On 04-Oct-18 2:15 PM, Alejandro Lucero wrote:
> >
> >
> > On Thu, Oct 4, 2018 at 1:08 PM Burakov, Anatoly
> > mailto:anatoly.bura...@intel.com>> wrote:
> >
> >
On Thu, Oct 4, 2018 at 4:49 PM Burakov, Anatoly
wrote:
> On 04-Oct-18 2:35 PM, Alejandro Lucero wrote:
> >
> >
> > On Wed, Oct 3, 2018 at 1:56 PM Burakov, Anatoly
> > mailto:anatoly.bura...@intel.com>> wrote:
> >
> > On 31-Aug-18 1:50 PM, Ale
.
Another usage is for emulated IOMMU hardware with addressing
limitations.
It is necessary to save the most restricted dma mask for checking out
memory allocated dynamically after initialization.
Signed-off-by: Alejandro Lucero
---
doc/guides/rel_notes/release_18_11.rst| 10
lib
bits or less for
most systems. And this is likely 100% true for VMs.
Signed-off-by: Alejandro Lucero
---
drivers/bus/pci/linux/pci.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
index a871549..5cf78d7 100644
--- a
NFP devices can not handle DMA addresses requiring more than
40 bits. This patch uses rte_dev_check_dma_mask with 40 bits
and avoids device initialization if memory out of NFP range.
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfp_net.c | 8
1 file changed, 8 insertions
-off-by: Alejandro Lucero
---
drivers/bus/pci/linux/pci.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
index 04648ac..a871549 100644
--- a/drivers/bus/pci/linux/pci.c
+++ b/drivers/bus/pci/linux/pci.c
@@ -620,8
I sent a patchset about this to be applied on 17.11 stable. The memory
code has had main changes since that version, so here it is the patchset
adjusted to current master repo.
This patchset adds, mainly, a check for ensuring IOVAs are within a
restricted range due to addressing limitations with s
: Alejandro Lucero
---
lib/librte_eal/common/eal_common_memory.c | 34 ++-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/common/eal_common_memory.c
b/lib/librte_eal/common/eal_common_memory.c
index 7555e76..366e454 100644
--- a/lib/librte_eal
NFP can handle IOVA as VA. It requires to check those IOVAs
being in the supported range what is done during initialization.
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfp_net.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/nfp/nfp_net.c b
On Fri, Oct 5, 2018 at 1:15 PM Burakov, Anatoly
wrote:
> On 05-Oct-18 1:06 PM, Alejandro Lucero wrote:
> > A device can suffer addressing limitations. This function checks
> > memsegs have iovas within the supported range based on dma mask.
> >
> > PMDs shou
I sent a patchset about this to be applied on 17.11 stable. The memory
code has had main changes since that version, so here it is the patchset
adjusted to current master repo.
This patchset adds, mainly, a check for ensuring IOVAs are within a
restricted range due to addressing limitations with s
: Alejandro Lucero
Reviewed-by: Anatoly Burakov
---
lib/librte_eal/common/eal_common_memory.c | 34 ++-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/common/eal_common_memory.c
b/lib/librte_eal/common/eal_common_memory.c
index c482f0d..853c44c
-off-by: Alejandro Lucero
Acked-by: Anatoly Burakov
---
drivers/bus/pci/linux/pci.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
index 04648ac..a871549 100644
--- a/drivers/bus/pci/linux/pci.c
+++ b/drivers/bus
bits or less for
most systems. And this is likely 100% true for VMs.
Signed-off-by: Alejandro Lucero
Acked-by: Anatoly Burakov
---
drivers/bus/pci/linux/pci.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
index
.
Another usage is for emulated IOMMU hardware with addressing
limitations.
It is necessary to save the most restricted dma mask for checking out
memory allocated dynamically after initialization.
Signed-off-by: Alejandro Lucero
Reviewed-by: Anatoly Burakov
---
doc/guides/rel_notes/release_18_11.rst
NFP devices can not handle DMA addresses requiring more than
40 bits. This patch uses rte_dev_check_dma_mask with 40 bits
and avoids device initialization if memory out of NFP range.
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfp_net.c | 8
1 file changed, 8 insertions
NFP can handle IOVA as VA. It requires to check those IOVAs
being in the supported range what is done during initialization.
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfp_net.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/nfp/nfp_net.c b
On Fri, Oct 5, 2018 at 2:01 PM Ferruh Yigit wrote:
> On 10/3/2018 9:44 PM, Thomas Monjalon wrote:
> > + Cc more people
> >
> > 27/09/2018 13:26, Alejandro Lucero:
> >> Primary and secondary processes share a per-device private data. With
> >> current des
similar
requirements for per-process device data.
v2:
- changing library version
- report shared library change in release notes
Signed-off-by: Alejandro Lucero
---
doc/guides/rel_notes/release_18_11.rst | 1 +
lib/librte_ethdev/Makefile | 2 +-
lib/librte_ethdev/meson.build
On Fri, Oct 5, 2018 at 5:37 PM Andrew Rybchenko
wrote:
> On 10/5/18 7:16 PM, Alejandro Lucero wrote:
>
> Primary and secondary processes share a per-device private data. With
> current design it is not possible to have data per-device per-process.
> This is required for handling p
On Wed, Oct 10, 2018 at 10:00 AM Tu, Lijuan wrote:
> Hi
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Alejandro Lucero
> > Sent: Friday, October 5, 2018 8:45 PM
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] [PATCH v3
On Fri, Sep 7, 2018 at 3:55 PM Darek Stojaczyk
wrote:
> This allows DPDK to use RTE_IOVA_VA with VFIO/UIO-bound PCI
> devices present on the system, but not attached to any
> rte_pci_driver at the time of init.
>
> So far we used RTE_IOVA_VA whenever there was at least one
> device attached to a
similar
requirements for per-process device data.
v2:
- changing library version
- report shared library change in release notes
v3:
- fix shared library version
Signed-off-by: Alejandro Lucero
---
doc/guides/rel_notes/release_18_11.rst | 1 +
lib/librte_ethdev/Makefile | 2
On Mon, Oct 15, 2018 at 1:12 PM Andrew Rybchenko
wrote:
> On 10/15/18 12:00 PM, Alejandro Lucero wrote:
> > Primary and secondary processes share a per-device private data. With
> > current design it is not possible to have data per-device per-process.
> > This is required
similar
requirements for per-process device data.
v2:
- changing library version
- report shared library change in release notes
v3:
- fix shared library version
v4:
- fix release notes
Signed-off-by: Alejandro Lucero
---
doc/guides/rel_notes/release_18_11.rst | 2 +-
lib/librte_ethdev
On Thu, Oct 18, 2018 at 5:26 PM Burakov, Anatoly
wrote:
> On 27-Sep-18 1:30 PM, Alejandro Lucero wrote:
> > Invoking rte_pci_read/write_config functions requires device with
> > a intr_handle type for using VFIO or UIO driver related functions.
> >
> > Secondar
On Fri, Oct 19, 2018 at 9:02 AM Burakov, Anatoly
wrote:
> On 18-Oct-18 5:41 PM, Alejandro Lucero wrote:
> >
> >
> > On Thu, Oct 18, 2018 at 5:26 PM Burakov, Anatoly
> > mailto:anatoly.bura...@intel.com>> wrote:
> >
> > On 27-Sep-18 1:30 PM
tions to access PCI config")
Signed-off-by: Alejandro Lucero
---
drivers/bus/pci/linux/pci.c | 36 ++--
1 file changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
index 5cf78d7..135b82c 100644
---
Hi Ferruh,
On Thu, Jun 14, 2018 at 10:17 AM, Ferruh Yigit
wrote:
> On 6/11/2018 10:50 AM, Alejandro Lucero wrote:
> > TX descriptor eop_offset field is not initialized and it could
> > contain garbage. This patch fixes the potential problem setting
> > EOP as the onl
On Mon, Jun 18, 2018 at 8:53 PM, Dariusz Stojaczyk <
dariuszx.stojac...@intel.com> wrote:
> Since secondary process' address space is highly dictated
> by the primary process' mappings, it doesn't make much
> sense to use base-virtaddr for secondary processes.
>
> This patch is intended to fix PCI
On Mon, Jun 18, 2018 at 8:03 PM, Stojaczyk, DariuszX <
dariuszx.stojac...@intel.com> wrote:
>
> > -Original Message-
> > From: Alejandro Lucero [mailto:alejandro.luc...@netronome.com]
> > Sent: Monday, June 18, 2018 7:22 PM
> >
> > Should not be b
config space.
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfp_net.c | 4 +-
drivers/net/nfp/nfpcore/nfp_cpp.h | 6 +-
drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c | 111 ++---
drivers/net/nfp/nfpcore/nfp_cppcore.c | 9 +--
4
On Tue, Jun 19, 2018 at 10:24 AM, Burakov, Anatoly <
anatoly.bura...@intel.com> wrote:
> On 18-Jun-18 9:12 PM, Stojaczyk, DariuszX wrote:
>
>>
>>
>> -Original Message-----
>>> From: Alejandro Lucero [mailto:alejandro.luc...@netronome.com]
>>> Se
On Tue, Jun 19, 2018 at 11:27 AM, Burakov, Anatoly <
anatoly.bura...@intel.com> wrote:
> On 19-Jun-18 11:23 AM, Alejandro Lucero wrote:
>
>>
>>
>> On Tue, Jun 19, 2018 at 10:24 AM, Burakov, Anatoly <
>> anatoly.bura...@intel.com <mailto:anatoly.bura...@i
Getting the bar size is required for NFP CPP interface configuration.
However, this information can be obtained from the VFIO or UIO driver
instead of accessing the sysfs resource file.
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c | 27
this remapping and therefore also avoids to access
the device sysfs resource0 file for doing that remapping.
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c | 46 ++
1 file changed, 3 insertions(+), 43 deletions(-)
diff --git a/drivers
Devices can have addressing limitations and an internal dma mask
will track the more restrictive dma mask set by a device.
Signed-off-by: Alejandro Lucero
---
lib/librte_eal/common/eal_common_options.c | 1 +
lib/librte_eal/common/eal_internal_cfg.h | 1 +
2 files changed, 2 insertions
Hugepages get an iova address which could be out of range
for devices with addressing limitations. This patch checks
hugepages are withint the range if dma mask is set by a device.
Signed-off-by: Alejandro Lucero
---
lib/librte_eal/common/eal_private.h | 3 +++
lib/librte_eal/linuxapp/eal/eal.c
This RFC tries to handle devices with addressing limitations. NFP devices
4000/6000 can just handle addresses with 40 bits implying problems for handling
physical address when machines have more than 1TB of memory. But because how
iovas are configured, which can be equivalent to physical addresses
Devices can have addressing limitations and a driver can set a dma
mask. This patch adds a function for checking hugepages iovas are within
the range supported by the dma mask.
Signed-off-by: Alejandro Lucero
---
lib/librte_eal/linuxapp/eal/eal_memory.c | 36
1
A device with addressing limitations will invoke this function
for setting a dma mask. It has no effect if there is another
dma mask already set and more restrictive than this one.
Signed-off-by: Alejandro Lucero
---
lib/librte_eal/common/eal_common_memory.c | 15 +++
lib
This function calls a generic one for ethernet devices.
Signed-off-by: Alejandro Lucero
---
lib/librte_ether/rte_ethdev.h | 12
1 file changed, 12 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index eba11ca..e3979e4 100644
--- a/lib
NFP 4000/6000 devices can not use iova addresses requiring more
than 40 bits. This patch sets a dma mask for avoiding hugepages
with iova requiring more than those 40 bits.
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfp_net.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a
On Wed, Jun 27, 2018 at 9:17 AM, Burakov, Anatoly wrote:
> On 26-Jun-18 6:37 PM, Alejandro Lucero wrote:
>
>> This RFC tries to handle devices with addressing limitations. NFP devices
>> 4000/6000 can just handle addresses with 40 bits implying problems for
>> handling
On Wed, Jun 27, 2018 at 3:56 PM, Ferruh Yigit
wrote:
> On 6/26/2018 2:25 PM, Alejandro Lucero wrote:
> > Getting the bar size is required for NFP CPP interface configuration.
> > However, this information can be obtained from the VFIO or UIO driver
> > instead of accessi
On Wed, Jun 27, 2018 at 2:24 PM, Burakov, Anatoly wrote:
> On 27-Jun-18 11:13 AM, Alejandro Lucero wrote:
>
>
>>
>> On Wed, Jun 27, 2018 at 9:17 AM, Burakov, Anatoly <
>> anatoly.bura...@intel.com <mailto:anatoly.bura...@intel.com>> wrote:
>>
>&g
On Thu, Jun 28, 2018 at 9:54 AM, Burakov, Anatoly wrote:
> On 27-Jun-18 5:52 PM, Alejandro Lucero wrote:
>
>>
>>
>> On Wed, Jun 27, 2018 at 2:24 PM, Burakov, Anatoly <
>> anatoly.bura...@intel.com <mailto:anatoly.bura...@intel.com>> wrote:
>>
>
On Thu, Jun 28, 2018 at 11:03 AM, Burakov, Anatoly <
anatoly.bura...@intel.com> wrote:
> On 28-Jun-18 10:56 AM, Alejandro Lucero wrote:
>
>>
>>
>> On Thu, Jun 28, 2018 at 9:54 AM, Burakov, Anatoly <
>> anatoly.bura...@intel.com <mailto:anatoly.bura...@i
This patchset adds, mainly, a check for ensuring IOVAs are within a
restricted range due to addressing limitations with some devices. There
are two known cases: NFP and IOMMU VT-d emulation.
With this check IOVAs out of range are detected and PMDs can abort
initialization. For the VT-d case, IOVA
NFP devices can not handle DMA addresses requiring more than
40 bits. This patch uses rte_dev_check_dma_mask with 40 bits
and avoids device initialization if memory out of NFP range.
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfp_net.c | 8
1 file changed, 8 insertions
.
Another potential usage is for emulated IOMMU hardware with addressing
limitations.
Signed-off-by: Alejandro Lucero
---
lib/librte_eal/common/eal_common_memory.c | 37 ++
lib/librte_eal/common/include/rte_memory.h | 3 +++
2 files changed, 40 insertions(+)
diff --git a
A PMD should invoke this function for checking memsegs iovas are within
the supported range by the device.
Signed-off-by: Alejandro Lucero
---
lib/librte_ether/rte_ethdev.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether
default, and therefore memsegs iovas can use 39 bits or less for
most system. And this is likely 100% true for VMs.
Signed-off-by: Alejandro Lucero
---
drivers/bus/pci/linux/pci.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/bus/pci/linux/pci.c b
64 bits there is a lot
of available space.
This patch adds an address hint as starting address for 64 bits
systems.
Signed-off-by: Alejandro Lucero
---
lib/librte_eal/linuxapp/eal/eal_memory.c | 50 ++--
1 file changed, 41 insertions(+), 9 deletions(-)
diff --git a
NFP can handle IOVA as VA. It requires to check those IOVAs
being in the supported range what is done during initialization.
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfp_net.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/nfp/nfp_net.c b
On Tue, Jul 3, 2018 at 10:07 AM, Burakov, Anatoly wrote:
> On 02-Jul-18 6:26 PM, Alejandro Lucero wrote:
>
>> A device can suffer addressing limitations. This functions checks
>> memsegs have iovas within the supported range based on dma mask.
>>
>> PMD should use
On Tue, Jul 3, 2018 at 10:10 AM, Burakov, Anatoly wrote:
> On 02-Jul-18 6:27 PM, Alejandro Lucero wrote:
>
>> Although VT-d emulation currently only supports 39 bits, it could
>> be iovas being within that supported range. This patch allows
>> IOVA mode in such a ca
On Tue, Jul 3, 2018 at 10:17 AM, Burakov, Anatoly wrote:
> On 02-Jul-18 6:27 PM, Alejandro Lucero wrote:
>
>> Linux kernel uses a really high address as starting address for
>> serving mmaps calls. If there exists addressing limitations and
>> IOVA mode is VA, this starti
NFP devices can not handle DMA addresses requiring more than
40 bits. This patch uses rte_dev_check_dma_mask with 40 bits
and avoids device initialization if memory out of NFP range.
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfp_net.c | 8
1 file changed, 8 insertions
64 bits there is a lot
of available space.
This patch adds an address hint as starting address for 64 bits
systems.
Signed-off-by: Alejandro Lucero
---
lib/librte_eal/linuxapp/eal/eal_memory.c | 58 +++-
1 file changed, 49 insertions(+), 9 deletions(-)
diff --git a
A PMD should invoke this function for checking memsegs iovas are within
the supported range by the device.
Signed-off-by: Alejandro Lucero
---
lib/librte_ether/rte_ethdev.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether
This patchset adds, mainly, a check for ensuring IOVAs are within a
restricted range due to addressing limitations with some devices. There
are two known cases: NFP and IOMMU VT-d emulation.
With this check IOVAs out of range are detected and PMDs can abort
initialization. For the VT-d case, IOVA
.
Another potential usage is for emulated IOMMU hardware with addressing
limitations.
Signed-off-by: Alejandro Lucero
---
lib/librte_eal/common/eal_common_memory.c | 33 ++
lib/librte_eal/common/include/rte_memory.h | 3 +++
2 files changed, 36 insertions(+)
diff --git a
default, and therefore memsegs iovas can use 39 bits or less for
most system. And this is likely 100% true for VMs.
Signed-off-by: Alejandro Lucero
---
drivers/bus/pci/linux/pci.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/bus/pci/linux/pci.c b
NFP can handle IOVA as VA. It requires to check those IOVAs
being in the supported range what is done during initialization.
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfp_net.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/nfp/nfp_net.c b
A PMD should invoke this function for checking memsegs iovas are within
the supported range by the device.
Signed-off-by: Alejandro Lucero
---
lib/librte_ether/rte_ethdev.h | 13 +
lib/librte_ether/rte_ethdev_version.map | 1 +
2 files changed, 14 insertions(+)
diff
.
Another potential usage is for emulated IOMMU hardware with addressing
limitations.
Signed-off-by: Alejandro Lucero
Acked-by: Anatoly Burakov
---
lib/librte_eal/common/eal_common_memory.c | 33 ++
lib/librte_eal/common/include/rte_memory.h | 3 +++
lib/librte_eal
This patchset adds, mainly, a check for ensuring IOVAs are within a
restricted range due to addressing limitations with some devices. There
are two known cases: NFP and IOMMU VT-d emulation.
With this check IOVAs out of range are detected and PMDs can abort
initialization. For the VT-d case, IOVA
64 bits there is a lot
of available space.
This patch adds an address hint as starting address for 64 bits
systems.
Signed-off-by: Alejandro Lucero
Acked-by: Anatoly Burakov
---
lib/librte_eal/linuxapp/eal/eal_memory.c | 55 ++--
1 file changed, 46 insertions(+), 9
default, and therefore memsegs iovas can use 39 bits or less for
most system. And this is likely 100% true for VMs.
Signed-off-by: Alejandro Lucero
---
drivers/bus/pci/linux/pci.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/bus/pci/linux/pci.c b
NFP devices can not handle DMA addresses requiring more than
40 bits. This patch uses rte_dev_check_dma_mask with 40 bits
and avoids device initialization if memory out of NFP range.
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfp_net.c | 8
1 file changed, 8 insertions
NFP can handle IOVA as VA. It requires to check those IOVAs
being in the supported range what is done during initialization.
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfp_net.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/nfp/nfp_net.c b
This is a patched to fix a functionality coming with the first public
release: changing/setting MAC address.
The original patch assumes all NICs can safely change or set the MAC
in any case. However, this is not always true. NFP depends on the firmware
capabilities and this is not always supported
;)
Cc: sta...@dpdk.org
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfp_net.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index 3658696..fbe74fc 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -2883
, and if the flag is set, the MAC is changed before the
port starts.
Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org
Signed-off-by: Alejandro Lucero
---
lib/librte_ethdev/rte_ethdev.c | 28 +++-
lib/librte_ethdev/rte_ethdev.h | 2 ++
2 files c
On Thu, Oct 25, 2018 at 12:11 AM Thomas Monjalon
wrote:
> Hi,
>
> 19/10/2018 18:43, Alejandro Lucero:
> > --- a/drivers/bus/pci/linux/pci.c
> > +++ b/drivers/bus/pci/linux/pci.c
> > + char devname[RTE_DEV_NAME_MAX_LEN] = {0};
>
> I think &qu
On Thu, Oct 25, 2018 at 6:30 AM Alejandro Lucero <
alejandro.luc...@netronome.com> wrote:
>
>
> On Thu, Oct 25, 2018 at 12:11 AM Thomas Monjalon
> wrote:
>
>> Hi,
>>
>> 19/10/2018 18:43, Alejandro Lucero:
>> > --- a/drivers/bus/pci/li
On Thu, Oct 25, 2018 at 10:29 AM Burakov, Anatoly
wrote:
> On 25-Oct-18 7:00 AM, Alejandro Lucero wrote:
> > On Thu, Oct 25, 2018 at 6:30 AM Alejandro Lucero <
> > alejandro.luc...@netronome.com> wrote:
> >
> >>
> >>
> >> On Thu
tions to access PCI config")
v2:
- Use #ifdef for VFIO functions
Signed-off-by: Alejandro Lucero
---
drivers/bus/pci/linux/pci.c | 32 ++--
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/p
tions to access PCI config")
v2:
- Use #ifdef for VFIO functions
Signed-off-by: Alejandro Lucero
---
drivers/bus/pci/linux/pci.c | 32 ++--
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/p
t memory policy.
> > > EAL: Setting policy MPOL_PREFERRED for socket 0
> > > EAL: Restoring previous memory policy: 0
> > >
> > > Could you have a check on this? A lot of test cases in our validation
> > > team fail because of this. Thanks a lot!
>
I know what is going on.
In patchset version 3 I forgot to remove an old code. Anatoly spotted that
and I was going to send another version for fixing it. Before sending the
new version I saw that report about a problem with dma_mask and I'm afraid
I did not send another version with the fix ...
Apologies. Forget my previous email. Just using the wrong repo.
Looking at solving this asap.
On Mon, Oct 29, 2018 at 10:11 AM Alejandro Lucero <
alejandro.luc...@netronome.com> wrote:
> I know what is going on.
>
> In patchset version 3 I forgot to remove an old code. Anato
On Mon, Oct 29, 2018 at 10:15 AM Alejandro Lucero <
alejandro.luc...@netronome.com> wrote:
> Apologies. Forget my previous email. Just using the wrong repo.
>
> Looking at solving this asap.
>
> On Mon, Oct 29, 2018 at 10:11 AM Alejandro Lucero <
> alejandro.luc...@netron
On Mon, Oct 29, 2018 at 11:46 AM Thomas Monjalon
wrote:
> 29/10/2018 12:39, Alejandro Lucero:
> > I got a patch that solves a bug when calling rte_eal_dma_mask using the
> > mask instead of the maskbits. However, this does not solves the deadlock.
>
> The deadlock is a b
On Mon, Oct 29, 2018 at 1:18 PM Yao, Lei A wrote:
>
>
>
>
> *From:* Alejandro Lucero [mailto:alejandro.luc...@netronome.com]
> *Sent:* Monday, October 29, 2018 8:56 PM
> *To:* Thomas Monjalon
> *Cc:* Yao, Lei A ; dev ; Xu, Qian Q <
> qian.q...@intel.com>;
On Mon, Oct 29, 2018 at 2:18 PM Thomas Monjalon wrote:
> 29/10/2018 14:40, Alejandro Lucero:
> > On Mon, Oct 29, 2018 at 1:18 PM Yao, Lei A wrote:
> > > *From:* Alejandro Lucero [mailto:alejandro.luc...@netronome.com]
> > > On Mon, Oct 29, 2018 at 11:46 AM T
Hi Dariousz,
On Mon, Oct 29, 2018 at 4:08 PM Dariusz Stojaczyk
wrote:
> On Fri, Oct 5, 2018 at 2:47 PM Alejandro Lucero
> wrote:
> >
> > Linux kernel uses a really high address as starting address for
> > serving mmaps calls. If there exist addressing limitations and
&
On Mon, Oct 29, 2018 at 6:54 PM Yongseok Koh wrote:
>
> > On Oct 29, 2018, at 7:18 AM, Thomas Monjalon
> wrote:
> >
> > 29/10/2018 14:40, Alejandro Lucero:
> >> On Mon, Oct 29, 2018 at 1:18 PM Yao, Lei A wrote:
> >>> *From:* Alejandro Lucero [mailto
pci_get_iommu_class ()
>
> at /root/dpdk/drivers/bus/pci/linux/pci.c:650
>
> #8 0x0058f1ce in rte_bus_get_iommu_class ()
>
> at /root/dpdk/lib/librte_eal/common/eal_common_bus.c:237
>
> #9 0x00577c7a in rte_eal_init (argc=2, argv=0x7fffdf98)
>
On Tue, Oct 30, 2018 at 10:11 AM Burakov, Anatoly
wrote:
> On 29-Oct-18 2:18 PM, Thomas Monjalon wrote:
> > 29/10/2018 14:40, Alejandro Lucero:
> >> On Mon, Oct 29, 2018 at 1:18 PM Yao, Lei A wrote:
> >>> *From:* Alejandro Lucero [mailto:alejandro.luc...@netro
On Tue, Oct 30, 2018 at 10:19 AM Burakov, Anatoly
wrote:
> On 29-Oct-18 11:39 AM, Alejandro Lucero wrote:
> > I got a patch that solves a bug when calling rte_eal_dma_mask using the
> > mask instead of the maskbits. However, this does not solves the deadlock.
> >
> >
get_iommu_class ()
>
> #4 0x0054f743 in rte_bus_get_iommu_class ()
>
> #5 0x0053c123 in rte_eal_init ()
>
> #6 0x0046be2b in main ()
>
>
>
> Best regards,
>
> Xueqin
>
>
>
> *From:* Alejandro Lucero [mailto:alejandro.luc.
On Sun, Oct 28, 2018 at 11:04 PM Thomas Monjalon
wrote:
> 11/10/2018 12:08, Thomas Monjalon:
> > +Cc more maintainers in order to collect more reviews
> >
> > 04/10/2018 11:19, Burakov, Anatoly:
> > > On 03-Oct-18 9:53 PM, eric zhang wrote:
> > > > This patchset introduces an EAL command line opt
U, not call to
rte_eal_check_dma_mask at all.
> Best regards,
>
> Xueqin
>
>
>
> *From:* Alejandro Lucero [mailto:alejandro.luc...@netronome.com]
> *Sent:* Tuesday, October 30, 2018 6:38 PM
> *To:* Lin, Xueqin
> *Cc:* Yao, Lei A ; Thomas Monjalon <
> tho..
On Mon, Sep 17, 2018 at 2:06 PM Stojaczyk, Dariusz <
dariusz.stojac...@intel.com> wrote:
>
>
> > -Original Message-
> > From: Burakov, Anatoly
> > Sent: Monday, September 17, 2018 12:34 PM
> > To: Stojaczyk, Dariusz ; dev@dpdk.org;
> > Santosh Shukla ; Hemant Agrawal
> > ; Jerin Jacob
> >
On Tue, Oct 30, 2018 at 1:48 PM Burakov, Anatoly
wrote:
> On 30-Oct-18 12:02 PM, Alejandro Lucero wrote:
> >
> >
> > On Sun, Oct 28, 2018 at 11:04 PM Thomas Monjalon > <mailto:tho...@monjalon.net>> wrote:
> >
> > 11/10/2018 12:08, Thomas Monjalon
On Tue, Oct 30, 2018 at 12:37 PM Alejandro Lucero <
alejandro.luc...@netronome.com> wrote:
>
>
> On Tue, Oct 30, 2018 at 12:22 PM Lin, Xueqin wrote:
>
>> Some found on some our servers:
>>
>> If not add ”intel_iommu=on iommu=pt” in /boot/grub2/grub.cfg file,
101 - 200 of 569 matches
Mail list logo
