On Wed, Nov 13, 2019 at 12:55 PM Ferruh Yigit
wrote:
> On 11/13/2019 12:47 PM, Alejandro Lucero wrote:
> > I'm leaving Netronome and will not work with the NFP anymore.
>
> Thanks Alejandro for all your contributions, and new best of luck in your
> new
> journey.
>
I'm leaving Netronome and will not work with the NFP anymore.
Signed-off-by: Alejandro Lucero
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index f2fdb9387..9e805387d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -771,7 +771,7
On Fri, Sep 27, 2019 at 10:06 AM Hemant Agrawal
wrote:
> Cc: Alejandro Lucero
>
> Signed-off-by: Hemant Agrawal
> ---
> doc/guides/nics/nfp.rst | 28 +---
> 1 file changed, 1 insertion(+), 27 deletions(-)
>
> diff --git a/doc/guides/nics/n
Not closing the socket implies a resource leak.
Coverity issue: 336865
Fixes: 29a62d1476b6 ("net/nfp: add CPP bridge as service")
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/n
Coverity issue: 32806
Fixes: ef28aa96e53b ("net/nfp: support multiprocess")
Cc: sta...@dpdk.org
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c
b/drive
If the call fails just returns 0.
Coverity issue: 277225
Fixes: c7e9729da6b5 ("net/nfp: support CPP")
Cc: sta...@dpdk.org
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfpcore/nfp_cppcore.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/n
If errors, release the allocated structure.
Coverity issue: 277222
Fixes: c7e9729da6b5 ("net/nfp: support CPP")
Cc: sta...@dpdk.org
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletion
If the call to _nfp6000_cppat_mu_locality fails, the function needs
to return with an error.
Coverity issue: 277215
Fixes: c7e9729da6b5 ("net/nfp: support CPP")
Cc: sta...@dpdk.org
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfpcore/nfp-common/nfp_cppat.h | 3 +++
1 file
Call to CPP read can fail.
Coverity issue: 277209
Fixes: c7e9729da6b5 ("net/nfp: support CPP")
Cc: sta...@dpdk.org
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfpcore/nfp_cppcore.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/n
Coverity issue: 277204
Fixes: defb9a5dd156 ("nfp: introduce driver initialization")
Cc: sta...@dpdk.org
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfp_net.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp
Although it is rather unlikely getting 0 as the descriptor handle, better
to contemplate that possibility.
Coverity issue: 195018
Fixes: 896c265ef954 ("net/nfp: use new CPP interface")
Cc: sta...@dpdk.org
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfp_net.c | 4 ++--
1 file
On Wed, Apr 3, 2019 at 8:19 AM Tiwei Bie wrote:
> Hi everyone,
>
> This is a draft implementation of the mdev (Mediated device [1])
> bus support in DPDK. Mdev is a way to virtualize devices in Linux
> kernel. Based on the device-api (mdev_type/device_api), there could
> be different types of mde
---
>
> LGTM
>
> Tested-by: Anatoly Burakov
>
> We can always increase the number of tries later :)
>
>
This is also fine for me.
If the map address is not within the supported range by a device with
addressing limitations, the device will not be used.
Not sure how this is likely to happen, but I guess if it is become a
problem, another solution should be implemented.
Acked-by: Alejandro Lucero
> --
> Thanks,
> Anatoly
>
On Tue, Mar 19, 2019 at 5:43 PM Ferruh Yigit wrote:
> On 3/12/2019 9:56 AM, Alejandro Lucero wrote:
> > On Fri, Mar 8, 2019 at 10:28 AM Pallantla Poornima <
> > pallantlax.poorn...@intel.com> wrote:
> >
> >> sprintf function is not secure as it doesn
ed-off-by: Natanael Copa
>
Acked-by: Alejandro Lucero
> ---
> drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c
> b/drivers/net/nfp/nfpcore/nfp_cpp_pcie_ops.c
> index 39b
Current code is not properly giving the RSS information
regarding the redirection table.
Fixes: 934e4c60fbff ("nfp: add RSS")
Cc: sta...@dpdk.org
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfp_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drive
On Fri, Mar 8, 2019 at 10:28 AM Pallantla Poornima <
pallantlax.poorn...@intel.com> wrote:
> sprintf function is not secure as it doesn't check the length of string.
> More secure function snprintf is used.
>
> Fixes: 896c265ef9 ("net/nfp: use new CPP interface")
> Fixes: c4171b520b ("net/nfp: sup
TRL_LIVE_ADDR;
> if (nfp_net_reconfig(hw, ctrl, update) < 0) {
> PMD_INIT_LOG(INFO, "MAC address update failed");
> return -EIO;
> --
> 2.7.4
>
>
Acked-by: Alejandro Lucero
repo:
>
> https://dpdk.org/browse/dpdk-stable/
>
>
> Thanks,
> Yongseok
>
> ---
> Ajit Khaparde (1):
> net/bnxt: set MAC filtering as outer for non tunnel frames
>
> Alejandro Lucero (4):
> mem: fix memory initialization time
> net/nfp: fi
On Thu, Feb 14, 2019 at 12:22 PM Alejandro Lucero <
alejandro.luc...@netronome.com> wrote:
>
>
> On Wed, Feb 13, 2019 at 7:24 PM Shahaf Shuler
> wrote:
>
>> Wednesday, February 13, 2019 1:43 PM, Alejandro Lucero:
>> > Subject: Re: [dpdk-dev] [PATCH 0
On Wed, Feb 13, 2019 at 7:24 PM Shahaf Shuler wrote:
> Wednesday, February 13, 2019 1:43 PM, Alejandro Lucero:
> > Subject: Re: [dpdk-dev] [PATCH 0/6] introduce DMA memory mapping for
> > external memory
> >
> > On Wed, Feb 13, 2019 at 9:11 AM Shahaf Shuler
> >
On Wed, Feb 13, 2019 at 9:11 AM Shahaf Shuler wrote:
> This series is in continue to RFC[1].
>
> The DPDK APIs expose 3 different modes to work with memory used for DMA:
>
> 1. Use the DPDK owned memory (backed by the DPDK provided hugepages).
> This memory is allocated by the DPDK libraries, inc
On Mon, Feb 4, 2019 at 12:19 PM Rami Rosen wrote:
> Hi, Alejandro,
>
> Thanks for you quick response.
>
> >When SRIOV is used by VMs, the slow path will always be faster (and
> >with lower latency) with DPDK.
>
> Yes, I am referring primarily to the SRIOV case in my question, when
> assigning PCI
On Mon, Feb 4, 2019 at 10:44 AM Rami Rosen wrote:
> Hi Alejandro,
>
> >Your concern is related to this thread
>
> Thanks for your reply, I was aware of this thread.
>
OK
> Still, I am not sure, in current kernels and currently available Ethernet
> DPDK PMDs about the answer to my queries (I don
Hi Rami,
Your concern is related to this thread:
http://mails.dpdk.org/archives/dev/2019-January/123466.html
I'm working on solving the problem when PF needs to be bound to VFIO. My
proposal is to use mediated devices.
Although it is not strictly necessary to rely on current kernel WiP about
VFI
The message refers to uio driver.
Signed-off-by: Alejandro Lucero
---
drivers/bus/pci/linux/pci_vfio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/pci/linux/pci_vfio.c b/drivers/bus/pci/linux/pci_vfio.c
index fa8cfbb0b..ebf6ccd3c 100644
--- a/drivers/bus/pci
me, and likely having a
more complete implementation, I will not try to duplicate work here, and I
hope I can contribute to the final implementation once I see your design.
Thanks!
>
>
>
> Thanks,
>
> Steve
>
>
>
>
>
> *From:* techboard [mailto:techboard-boun..
On Mon, Jan 14, 2019 at 6:54 PM Thomas Monjalon wrote:
> 14/01/2019 19:29, Alejandro Lucero:
> > On Mon, Jan 14, 2019 at 6:22 PM Ferruh Yigit
> wrote:
> >
> > > On 1/14/2019 6:00 PM, Alejandro Lucero wrote:
> > > >
> > > >
> > > &
On Mon, Jan 14, 2019 at 6:22 PM Ferruh Yigit wrote:
> On 1/14/2019 6:00 PM, Alejandro Lucero wrote:
> >
> >
> > On Mon, Jan 14, 2019 at 10:40 AM Ferruh Yigit > <mailto:ferruh.yi...@intel.com>> wrote:
> >
> > On 1/13/2019 9:41 PM, Thomas Monja
Signed-off-by: Alejandro Lucero
---
config/defconfig_i686-native-linuxapp-gcc| 5 +
config/defconfig_i686-native-linuxapp-icc| 5 +
config/defconfig_x86_x32-native-linuxapp-gcc | 5 +
3 files changed, 15 insertions(+)
diff --git a/config/defconfig_i686-native-linuxapp-gcc
b
On Mon, Jan 14, 2019 at 10:40 AM Ferruh Yigit
wrote:
> On 1/13/2019 9:41 PM, Thomas Monjalon wrote:
> > 11/01/2019 17:42, Ferruh Yigit:
> >> On 1/11/2019 1:25 PM, Alejandro Lucero wrote:
> >>> The Netronome's Network Flow Processor chip is highly programmabl
ith a
secondary process specifically enabling this CPP bridge service and
therefore giving access to the NFP to those host tools.
v2:
- Avoid printfs for debugging
- fix compilation problems for powerpc
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfp_net.c
On Fri, Jan 11, 2019 at 11:48 AM Ferruh Yigit
wrote:
> On 1/10/2019 11:55 AM, Alejandro Lucero wrote:
> >
> >
> > On Wed, Jan 9, 2019 at 4:15 PM Ferruh Yigit > <mailto:ferruh.yi...@intel.com>> wrote:
> >
> > On 1/9/2019 2:20 PM, Alejandro Lucer
On Wed, Jan 9, 2019 at 4:15 PM Ferruh Yigit wrote:
> On 1/9/2019 2:20 PM, Alejandro Lucero wrote:
> >
> >
> > On Wed, Jan 9, 2019 at 10:54 AM Ferruh Yigit > <mailto:ferruh.yi...@intel.com>> wrote:
> >
> > On 1/3/2019 8:56 AM, Alejandro Lucero
On Wed, Jan 9, 2019 at 10:54 AM Ferruh Yigit wrote:
> On 1/3/2019 8:56 AM, Alejandro Lucero wrote:
> > The Netronome's Network Flow Processor chip is highly programmable
> > with the goal of processing packets at high speed. Processing units
> > and other chip compone
ith a
secondary process specifically enabling this CPP bridge service and
therefore giving access to the NFP to those host tools.
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfp_net.c | 393 +-
drivers/net/nfp/nfp_net_pmd.h | 1 +
2 files changed
Previous commit adding multiprocess support broke VF support.
When VFs, the PMD does not set the link up or down.
Fixes: ef28aa96e53b ("net/nfp: support multiprocess")
Signed-off-by: Alejandro Lucero
---
drivers/net/nfp/nfp_net.c | 28
1 file changed, 16
On Wed, Nov 28, 2018 at 9:56 AM Xiao Wang wrote:
> This patch series enables a new method for live migration, i.e. software
> assisted live migration. This patch provides a device argument for user
> to choose the methold.
>
> When "swlm=1", driver/device will do live migration with a relay threa
Signed-off-by: Alejandro Lucero
---
doc/guides/nics/features/nfp.ini | 1 +
doc/guides/nics/features/nfp_vf.ini| 1 +
doc/guides/nics/nfp.rst| 12 ++
drivers/net/nfp/nfp_net.c | 133 +
drivers/net/nfp/nfpcore
On Wed, Nov 28, 2018 at 5:28 PM Ferruh Yigit wrote:
> On 11/28/2018 11:32 AM, Alejandro Lucero wrote:
> > This patch introduces changes for supporting multiprocess support.
> > This is trivial for VFs but comes with some limitations for the PF.
> >
> > Due to rest
This patch introduces changes for supporting multiprocess support.
This is trivial for VFs but comes with some limitations for the PF.
Due to restrictions when using NFP CPP interface, just one secondary
process is supported by now for the PF.
Signed-off-by: Alejandro Lucero
---
doc/guides
On Fri, Nov 16, 2018 at 1:35 PM Burakov, Anatoly
wrote:
> On 16-Nov-18 12:49 PM, Alejandro Lucero wrote:
> >
> >
> > On Thu, Nov 15, 2018 at 1:16 PM Burakov, Anatoly
> > mailto:anatoly.bura...@intel.com>> wrote:
> >
> > On 12-Nov-18 11:18 AM,
On Thu, Nov 15, 2018 at 1:16 PM Burakov, Anatoly
wrote:
> On 12-Nov-18 11:18 AM, Alejandro Lucero wrote:
> > When using large amount of hugepage based memory, doing all the
> > hugepages mapping can take quite significant time.
> >
> > The problem is hugepages being
: 293c0c4b957f ("mem: use address hint for mapping hugepages")
Signed-off-by: Alejandro Lucero
---
lib/librte_eal/linuxapp/eal/eal_memory.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
b/lib/librte_eal/linuxapp/eal/eal_memory.c
index
higher than
64 bits is likely wrong.
Signed-off-by: Alejandro Lucero
---
lib/librte_eal/common/eal_common_memory.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_memory.c
b/lib/librte_eal/common/eal_common_memory.c
index 87fd9921f
On Tue, Nov 6, 2018 at 10:48 AM Burakov, Anatoly
wrote:
> On 06-Nov-18 10:37 AM, Alejandro Lucero wrote:
> >
> >
> > On Tue, Nov 6, 2018 at 10:31 AM Burakov, Anatoly
> > mailto:anatoly.bura...@intel.com>> wrote:
> >
> >
On Tue, Nov 6, 2018 at 10:31 AM Burakov, Anatoly
wrote:
> On 06-Nov-18 9:32 AM, Alejandro Lucero wrote:
> >
> >
> > On Mon, Nov 5, 2018 at 4:35 PM Burakov, Anatoly
> > mailto:anatoly.bura...@intel.com>> wrote:
> >
> >
On Mon, Nov 5, 2018 at 4:35 PM Burakov, Anatoly
wrote:
> On 05-Nov-18 3:33 PM, Alejandro Lucero wrote:
> >
> >
> > On Mon, Nov 5, 2018 at 3:12 PM Burakov, Anatoly
> > mailto:anatoly.bura...@intel.com>> wrote:
> >
> > On 05-Nov-18 10:13 AM, Ale
On Mon, Nov 5, 2018 at 3:12 PM Burakov, Anatoly
wrote:
> On 05-Nov-18 10:13 AM, Alejandro Lucero wrote:
> > On Mon, Nov 5, 2018 at 10:01 AM Li, WenjieX A
> > wrote:
> >
> >> 1. With GCC32, testpmd could not startup without '--iova-mode pa'.
> >>
there is no
IOMMU hardware, no dma mask should be there at all.
>
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Alejandro Lucero
> Sent: Friday, November 2, 2018 3:53 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v2 5/7] mem: modify er
being just for internal EAL memory code.
Fixes: 223b7f1d5ef6 ("mem: add function for checking memseg IOVA")
Signed-off-by: Alejandro Lucero
---
lib/librte_eal/common/eal_common_memory.c | 24 +--
lib/librte_eal/common/include/rte_memory.h | 35 +++---
lib/
option need to be also considered.
This patch adds the DMA check for those cases.
Signed-off-by: Alejandro Lucero
---
lib/librte_eal/linuxapp/eal/eal_memory.c | 20
1 file changed, 20 insertions(+)
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
b/lib/librte_eal
user to force IOVA as PA if currently
IOVA being VA and user being root.
Signed-off-by: Alejandro Lucero
---
lib/librte_eal/common/malloc_heap.c | 41 +
1 file changed, 36 insertions(+), 5 deletions(-)
diff --git a/lib/librte_eal/common/malloc_heap.c
b/lib
Current name rte_eal_check_dma_mask does not follow the naming
used in the rest of the file.
Signed-off-by: Alejandro Lucero
---
doc/guides/rel_notes/release_18_11.rst | 2 +-
drivers/bus/pci/linux/pci.c| 2 +-
drivers/net/nfp/nfp_net.c | 2 +-
lib
A DMA mask check when setting IOVA mode")
Signed-off-by: Alejandro Lucero
---
drivers/bus/pci/linux/pci.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
index 0a81e063b..d87384c72 100644
--- a/drivers/bus
because the memory has not been initialized yet.
Signed-off-by: Alejandro Lucero
---
lib/librte_eal/common/eal_common_memory.c | 16
lib/librte_eal/common/include/rte_memory.h | 10 ++
lib/librte_eal/rte_eal_version.map | 1 +
3 files changed, 27 insertions
The param needs to be the maskbits and not the mask.
Fixes: 223b7f1d5ef6 ("mem: add function for checking memseg IOVA")
Signed-off-by: Alejandro Lucero
---
lib/librte_eal/common/malloc_heap.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/lib/librte_
lus a
thread_unsafe version.
- use rte_eal_using_phys_addr instead of getuid
- fix comments
- reorder patches
Alejandro Lucero (7):
mem: fix call to DMA mask check
mem: use proper prefix
mem: add function for setting DMA mask
bus/pci: avoid call to DMA mask check
mem: modify error messag
On Thu, Nov 1, 2018 at 3:03 PM Burakov, Anatoly
wrote:
> On 01-Nov-18 2:50 PM, Thomas Monjalon wrote:
> > 01/11/2018 11:08, Burakov, Anatoly:
> >> On 31-Oct-18 5:29 PM, Alejandro Lucero wrote:
> >>> Current name rte_eal_check_dma_mask does not follow the naming
>
On Thu, Nov 1, 2018 at 2:28 PM Burakov, Anatoly
wrote:
> On 01-Nov-18 1:39 PM, Alejandro Lucero wrote:
> >
> >
> > On Thu, Nov 1, 2018 at 10:40 AM Burakov, Anatoly
> > mailto:anatoly.bura...@intel.com>> wrote:
> >
> > On 31-Oct-18 5:29 PM, A
On Thu, Nov 1, 2018 at 11:30 AM Alejandro Lucero <
alejandro.luc...@netronome.com> wrote:
>
>
> On Thu, Nov 1, 2018 at 10:57 AM Burakov, Anatoly <
> anatoly.bura...@intel.com> wrote:
>
>> On 01-Nov-18 10:48 AM, Alejandro Lucero wrote:
>> >
>>
On Thu, Nov 1, 2018 at 10:40 AM Burakov, Anatoly
wrote:
> On 31-Oct-18 5:29 PM, Alejandro Lucero wrote:
> > If a device reports addressing limitations through a dma mask,
> > the IOVAs for mapped memory needs to be checked out for ensuring
> > correct functionality.
>
On Thu, Nov 1, 2018 at 10:38 AM Burakov, Anatoly
wrote:
> On 31-Oct-18 5:29 PM, Alejandro Lucero wrote:
> > During memory initialization calling rte_mem_check_dma_mask
> > leads to a deadlock because memory_hotplug_lock is locked by a
> > writer, the current c
On Thu, Nov 1, 2018 at 11:12 AM Burakov, Anatoly
wrote:
> On 01-Nov-18 11:03 AM, Alejandro Lucero wrote:
> >
> >
> > On Thu, Nov 1, 2018 at 10:29 AM Burakov, Anatoly
> > mailto:anatoly.bura...@intel.com>> wrote:
> >
> > On 31-Oct-18 5:29 PM, A
On Thu, Nov 1, 2018 at 10:57 AM Burakov, Anatoly
wrote:
> On 01-Nov-18 10:48 AM, Alejandro Lucero wrote:
> >
> >
> > On Thu, Nov 1, 2018 at 10:11 AM Burakov, Anatoly
> > mailto:anatoly.bura...@intel.com>> wrote:
> >
> > On 31-Oct-18 5:29 PM, Aleja
On Thu, Nov 1, 2018 at 10:29 AM Burakov, Anatoly
wrote:
> On 31-Oct-18 5:29 PM, Alejandro Lucero wrote:
> > If DMA mask checks shows mapped memory out of the supported range
> > specified by the DMA mask, nothing can be done but return an error
> > an report the error. This
On Thu, Nov 1, 2018 at 10:11 AM Burakov, Anatoly
wrote:
> On 31-Oct-18 5:29 PM, Alejandro Lucero wrote:
> > This patch adds the possibility of setting a dma mask to be used
> > once the memory initialization is done.
> >
> > This is currently needed when IOVA mode is
On Thu, Nov 1, 2018 at 10:08 AM Burakov, Anatoly
wrote:
> On 31-Oct-18 5:29 PM, Alejandro Lucero wrote:
> > Current name rte_eal_check_dma_mask does not follow the naming
> > used in the rest of the file.
> >
> > Signed-off-by: Alejandro Lucero
> > ---
>
On Wed, Oct 31, 2018 at 5:29 PM Alejandro Lucero <
alejandro.luc...@netronome.com> wrote:
> A patchset sent introducing DMA mask checks has several critical
> issues precluding apps to execute. The patchset was reviewed and
> finally accepted after three versions. Obviousl
user to force IOVA as PA if currently
IOVA being VA and user being root.
Signed-off-by: Alejandro Lucero
---
lib/librte_eal/common/malloc_heap.c | 35 +
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/lib/librte_eal/common/malloc_heap.c
b/lib
the memory_hotplug_lock needs to be
acquired, this is for the safe version, or not, the unsafe one.
PMDs should use the safe version and just internal EAL memory
code should use the unsafe one.
Fixes: 223b7f1d5ef6 ("mem: add function for checking memseg IOVA")
Signed-off-by: Alejan
need to be also considered.
This patch adds the DMA check for those cases.
Signed-off-by: Alejandro Lucero
---
lib/librte_eal/linuxapp/eal/eal_memory.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
b/lib/librte_eal/linuxapp/eal
because the memory has not been initialized yet.
Signed-off-by: Alejandro Lucero
---
lib/librte_eal/common/eal_common_memory.c | 10 ++
lib/librte_eal/common/include/rte_memory.h | 10 ++
lib/librte_eal/rte_eal_version.map | 1 +
3 files changed, 21 insertions(+)
diff
A DMA mask check when setting IOVA mode")
Signed-off-by: Alejandro Lucero
---
drivers/bus/pci/linux/pci.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
index 0a81e063b..d87384c72 100644
--- a/drivers/bus
Current name rte_eal_check_dma_mask does not follow the naming
used in the rest of the file.
Signed-off-by: Alejandro Lucero
---
doc/guides/rel_notes/release_18_11.rst | 2 +-
drivers/bus/pci/linux/pci.c| 2 +-
drivers/net/nfp/nfp_net.c | 2 +-
lib
The param needs to be the maskbits and not the mask.
Fixes: 223b7f1d5ef6 ("mem: add function for checking memseg IOVA")
Signed-off-by: Alejandro Lucero
---
lib/librte_eal/common/malloc_heap.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lib/librte_
olves all the problems reported. This
final patchset has the same functionality with minor changes. I have
successfully tested the patchset with my limited testbench.
Alejandro Lucero (7):
mem: fix call to DMA mask check
mem: use proper prefix
mem: add function for setting DMA mask
bus/pci:
>
>
Great.
I need to format the patchset properly and clean things up but I hope I can
send a patchset this week.
Thanks for testing!
By the way, is this testing something you are doing by yourself or it is
part of Intel DPDK work?
> Best regards,
>
> Xueqin
>
>
>
> *Fr
On Tue, Oct 30, 2018 at 2:14 PM Burakov, Anatoly
wrote:
> On 30-Oct-18 2:04 PM, Alejandro Lucero wrote:
> >
> >
> > On Tue, Oct 30, 2018 at 12:37 PM Alejandro Lucero
> > mailto:alejandro.luc...@netronome.com>>
>
> > wrote:
> >
> >
&g
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,
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 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
> >
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 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
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 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.
> >
> >
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
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 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
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 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
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 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 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
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
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 ...
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!
>
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
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
1 - 100 of 569 matches
Mail list logo
