On Sun, May 27, 2018 at 02:37:28PM +0200, Thomas Monjalon wrote:
> 27/05/2018 06:06, Yuanhan Liu:
> > On Tue, May 22, 2018 at 07:35:08PM +0100, Ferruh Yigit wrote:
> > > + /*
> > > + * This is a workaround to fix a virtio-user issue that
> > > + * r
Hi Monika,
> For last command I just declared 10 hugepages.
This is not enough.
I would suggest that you will try with 256 pages.
I assume you have 2 sockets on the host (this can be verified by running
"lspcu") and use 2MB hugepages.
So, this can be done by:
echo 256 >
/sys/devices/system/no
Fixes: c49a438fce90 ("doc: update qede guide and features")
Fixes: db86fbe54d90 ("doc: update qede PMD NIC guide")
Cc: sta...@dpdk.org
Signed-off-by: Rasesh Mody
---
doc/guides/nics/qede.rst | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/doc/guides/nics/qede.r
Hi Stephen,
if I don't give the last option for socket memory then also it fails.
Here is the error log :-
*sudo testpmd -l 8 -n 4 -c 0x3 *
EAL: Detected lcore 0 as core 3 on socket 0
EAL: Detected lcore 1 as core 3 on socket 1
EAL: Detected lcore 2 as core 4 on socket 0
EAL: Detected lcore 3 as
Hi Stephen
For last command I just declared 10 hugepages.
Regards,
Monika
On Fri, Jun 1, 2018 at 3:11 PM, Stephen Hemminger <
step...@networkplumber.org> wrote:
> How much huge page memory did you confirm?
> $ cat /proc/meminfo
>
> On Fri, Jun 1, 2018, 3:06 PM Monika Mails wrote:
>
>> Hi All,
How much huge page memory did you confirm?
$ cat /proc/meminfo
On Fri, Jun 1, 2018, 3:06 PM Monika Mails wrote:
> Hi All,
>
> This is Monika.
> I am new to DPDK.
> I just installed DPDK release - 18.05 on my server and trying to run
> "testpmd"
>
> Here is my command and its output :-
>
> sudo
Hi All,
This is Monika.
I am new to DPDK.
I just installed DPDK release - 18.05 on my server and trying to run
"testpmd"
Here is my command and its output :-
sudo testpmd -l 8 -n 4 -c 0x3 --socket-mem=512,512
EAL: Detected lcore 0 as core 3 on socket 0
EAL: Detected lcore 1 as core 3 on socket
Hi Jerin,
On 5/30/2018 12:56 PM, Jerin Jacob wrote:
-Original Message-
Hi Nikhil,
I think, it is reasonable to have Tx adapter.
Some top level comments to starts with,
1) Slow path API looks fine. The only comment is, How about changing
rte_event_eth_tx_adapter_queue_add() instead of
Fix fast path array index which is used for passing L2 handles to RSS
indirection table. Currently, it is using the local copy of indirection
table. When the RX queue configuration changes the local copy becomes
invalid.
Fixes: 69d7ba88f1a1 ("net/qede/base: use L2-handles for RSS configuration")
C
Implement the final piece of the in-memory mode puzzle - enable running
DPDK entirely in memory, without creating any files.
To do it, use mmap with MAP_HUGETLB and size flags to enable DPDK to work
without hugetlbfs mountpoints. In order to enable this, a few things needed
to be changed.
First o
Options --no-shconf and --huge-unlink will be removed, and
replaced with --in-memory option, which will be a superset
of these two, and an offially support method to run DPDK
entirely in memory.
Signed-off-by: Anatoly Burakov
---
Notes:
RFC->v1:
- Add this patch
doc/guides/rel_notes/de
Now that the rest of the EAL is adjusted to not create any shared
files, prevent runtime directory from ever being created.
Signed-off-by: Anatoly Burakov
---
Notes:
RFC->v1:
- Use --no-shconf only
lib/librte_eal/bsdapp/eal/eal.c | 3 ++-
lib/librte_eal/linuxapp/eal/eal.c | 3 ++-
2
This command-line option will cause DPDK to operate entirely in
memory and not create any shared files at runtime, including any
shared configuration or hugetlbfs files. This is useful for debug
purposes, as well as for certain use cases like containers or
automatic memory cleanup.
Currently, this
Unlink hugepages after creating them, to honor the hugepage-unlink mode.
We cannot resize non-existing files, so make single file segments
explicitly unsupported.
Signed-off-by: Anatoly Burakov
---
Notes:
RFC->v1:
- Use --huge-unlink only
lib/librte_eal/linuxapp/eal/eal_memalloc.c | 16
IPC is an inter-process communication mechanism. Since no secondaries
can ever be expected to run in no-shconf mode, IPC will be useless, so
do not enable it in the first place. In the interests of API usage
convenience, we will still allow registering callbacks, but obviously
they won't ever be tr
Do not create a shared hugepage data file if we were asked to
not create any shared files.
Signed-off-by: Anatoly Burakov
---
Notes:
RFC->v1:
- Use --no-shconf only
lib/librte_eal/linuxapp/eal/eal_memory.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git
This patchset adds a new command-line option "--in-memory",
which takes old debug options "--huge-unlink" and
"--no-shconf", and enhances them with additional
functionality. This will allow DPDK to reserve hugepages
anonymously instead of using hugetlbfs mountpoints. Coupled
with the fact that this
Do not create any shared hugepage size info files if we were
asked to not create any shared files.
Signed-off-by: Anatoly Burakov
---
Notes:
RFC->v1:
- Use --no-shconf only
lib/librte_eal/bsdapp/eal/eal_hugepage_info.c | 4
lib/librte_eal/linuxapp/eal/eal_hugepage_info.c | 4 +++
When using --no-shconf option, the expectation is that no multiprocess
will be supported as no shared files are created. However, fbarray still
creates some shared files that prevent multiple processes with the same
prefix from starting.
Fix this by avoiding creating shared files whenever noshconf
https://dpdk.org/tracker/show_bug.cgi?id=59
Bug ID: 59
Summary: Cannot start secondary processes anyhow on Redhat EL7
Product: DPDK
Version: 18.02
Hardware: x86
OS: Linux
Status: CONFIRMED
Severity: major
On 01-Jun-18 1:59 PM, Dariusz Stojaczyk wrote:
This isn't documented in the manuals, but a failed
mmap(..., MAP_FIXED) may still unmap overlapping
regions. In such case, we need to remap these regions
back into our address space to ensure mem contiguity.
We do it unconditionally now on mmap failu
On 01-Jun-18 1:59 PM, Dariusz Stojaczyk wrote:
EAL reserves a huge area in virtual address space
to provide virtual address contiguity for e.g.
future memory extensions (memory hotplug). During
memory hotplug, if the hugepage mmap succeeds but
doesn't suffice EAL's requiriments, the EAL would
unm
Page size shouldn't be zero, should be alloc_sz.
The 0 above is for the `flags` parameter. Page size is set to alloc_sz.
```
void *
eal_get_virtual_area(void *requested_addr, size_t *size,
size_t page_sz, int flags, int mmap_flags);
```
I believe it's okay. Correct me if I'm wr
On 01-Jun-18 2:44 PM, Dariusz Stojaczyk wrote:
When trying to use it with an address that's not
managed by DPDK it would segfault due to a missing
check. The doc says this function returns either
a pointer or NULL, so let it do so.
Changes from v1:
* removed gerrit change id
* added "git fix
When trying to use it with an address that's not
managed by DPDK it would segfault due to a missing
check. The doc says this function returns either
a pointer or NULL, so let it do so.
Changes from v1:
* removed gerrit change id
* added "git fixline" tags
Fixes: 66cc45e293ed ("mem: replace mems
This isn't documented in the manuals, but a failed
mmap(..., MAP_FIXED) may still unmap overlapping
regions. In such case, we need to remap these regions
back into our address space to ensure mem contiguity.
We do it unconditionally now on mmap failure just to
be safe.
Verified on Linux 4.9.0-4-am
EAL reserves a huge area in virtual address space
to provide virtual address contiguity for e.g.
future memory extensions (memory hotplug). During
memory hotplug, if the hugepage mmap succeeds but
doesn't suffice EAL's requiriments, the EAL would
unmap this mapping straight away, leaving a hole in
This series addresses a problem seen when running benchmars,
where we see a big difference in Tx performance depending on
whether Rx mergeable is enabled or not.
With patch 1, Tx simple path is selected even when Rx-mrg is
negotiated.
Digging a bit further, I found that Tx simple path could be
sel
This patch improves the Tx path selection depending on
whether the application request for offloads, and on whether
offload features have been negotiated.
When the application doesn't request for Tx offload features,
the corresponding features bits aren't negotiated.
When Tx offload virtio featur
Instead of checking the multiple Virtio features bits for
every packet, let's do the check once at configure time and
store it in virtio_hw struct.
Signed-off-by: Maxime Coquelin
---
drivers/net/virtio/virtio_ethdev.c | 19 +++
drivers/net/virtio/virtio_pci.h| 2 ++
drivers/
Signed-off-by: Maxime Coquelin
---
drivers/net/virtio/virtio_ethdev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index 5730620ed..d481b282e 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/dri
Having Rx mergeable buffers feature enabled should not be
a reason to not use Tx simple path.
Signed-off-by: Maxime Coquelin
---
drivers/net/virtio/virtio_ethdev.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index 58
> -Original Message-
> From: Burakov, Anatoly
> Sent: Friday, June 1, 2018 1:09 PM
> To: Stojaczyk, DariuszX ; dev@dpdk.org
> Subject: Re: [PATCH 2/2] memalloc: keep in mind a failed MAP_FIXED
> mmap may still perform an unmap
>
> On 01-Jun-18 1:51 PM, Dariusz Stojaczyk wrote:
> > This is
> -Original Message-
> From: Burakov, Anatoly
> Sent: Friday, June 1, 2018 1:00 PM
> On 01-Jun-18 1:51 PM, Dariusz Stojaczyk wrote:
> > EAL reserves a huge area in virtual address space to provide virtual
> > address contiguity for e.g.
> > future memory extensions (memory hotplug). During
On 01-Jun-18 11:24 AM, Stojaczyk, DariuszX wrote:
The Intel SMTP server keeps dying to me. It's really not fun trying to resend
these messages for half an hour without success. I'll resend this series from
my private mail in the evening.
D.
Please fix your NTP server, your timestamps appear
On 01-Jun-18 1:51 PM, Dariusz Stojaczyk wrote:
This isn't documented in the manuals, but a failed
mmap(..., MAP_FIXED) may still unmap overlapping
regions. In such case, we need to remap these regions
back into our address space to ensure mem contiguity.
We do it unconditionally now on mmap failu
Signed-off-by: Thomas Monjalon
---
The new release cycle is open, and it will be a short one!
Please consider reviewing your peers, and contribute to respect
the release schedule.
If you think some patches are already ready for integration in master,
please notify me.
Note that changes with bi
On Fri, 2018-06-01 at 10:56 +0100, Luca Boccassi wrote:
> On Fri, 2018-06-01 at 10:17 +0200, Marco Varlese wrote:
> > Hi Luca,
> >
> > On Thu, 2018-05-31 at 11:26 +0100, Luca Boccassi wrote:
> > > Hello all,
> > >
> > > At this morning's release meeting (minutes coming soon from John),
> > > we
>
On 01-Jun-18 1:51 PM, Dariusz Stojaczyk wrote:
EAL reserves a huge area in virtual address space
to provide virtual address contiguity for e.g.
future memory extensions (memory hotplug). During
memory hotplug, if the hugepage mmap succeeds but
doesn't suffice EAL's requiriments, the EAL would
unm
On 01-Jun-18 2:22 PM, Dariusz Stojaczyk wrote:
When trying to use it with an address that's not
managed by DPDK it would segfault due to a missing
check. The doc says this function returns either
a pointer or NULL, so let it do so.
Change-Id: Ib292f148914e67054f5d7b664077f19cba7000e4
Signed-off-
The optimal values of several transmission & reception related
parameters, such as burst sizes, descriptor ring sizes, and number
of queues, varies between different network interface devices. This
patch adds the values for the ixgbe PMD.
Signed-off-by: Remy Horton
---
doc/guides/rel_notes/relea
The Intel SMTP server keeps dying to me. It's really not fun trying to resend
these messages for half an hour without success. I'll resend this series from
my private mail in the evening.
D.
> -Original Message-
> From: Stojaczyk, DariuszX
> Sent: Friday, June 1, 2018 3:39 PM
> To: dev@
On 5/31/2018 5:32 PM, Ferruh Yigit wrote:
On 5/31/2018 5:13 PM, Radu Nicolau wrote:
On 5/31/2018 4:36 PM, Ferruh Yigit wrote:
On 5/31/2018 4:34 PM, Ferruh Yigit wrote:
On 5/31/2018 3:34 PM, Radu Nicolau wrote:
I can see you just prefix "fix" to the title without updating it :)
What about
Moved the link status validity check from the slave add to the slave
activation step. Otherwise slave add will fail for mode 4 if
the ports are all stopped but only one of them checked.
Fixes: b77d21cc2364 ("ethdev: add link status get/set helper functions")
Bugzilla ID: 52
Signed-off-by: Radu Ni
On 6/1/2018 1:05 AM, Chas Williams wrote:
It's not clear to me that the issue here is the bonding slave add.
You can only add started PMDs. When a PMD dev start is complete,
the PMD should have a valid link state and the link properties should be
valid. A few of the PMDs are very good about
EAL reserves a huge area in virtual address space
to provide virtual address contiguity for e.g.
future memory extensions (memory hotplug). During
memory hotplug, if the hugepage mmap succeeds but
doesn't suffice EAL's requiriments, the EAL would
unmap this mapping straight away, leaving a hole in
On Fri, 2018-06-01 at 06:38 +0200, Christian Ehrhardt wrote:
> On Thu, May 31, 2018 at 12:26 PM, Luca Boccassi
> wrote:
>
> > Hello all,
> >
> > At this morning's release meeting (minutes coming soon from John),
> > we
> > briefly discussed the state of the regression testing for stable
> > rele
On Fri, 2018-06-01 at 10:17 +0200, Marco Varlese wrote:
> Hi Luca,
>
> On Thu, 2018-05-31 at 11:26 +0100, Luca Boccassi wrote:
> > Hello all,
> >
> > At this morning's release meeting (minutes coming soon from John),
> > we
> > briefly discussed the state of the regression testing for stable
> >
EAL reserves a huge area in virtual address space
to provide virtual address contiguity for e.g.
future memory extensions (memory hotplug). During
memory hotplug, if the hugepage mmap succeeds but
doesn't suffice EAL's requiriments, the EAL would
unmap this mapping straight away, leaving a hole in
When trying to use it with an address that's not
managed by DPDK it would segfault due to a missing
check. The doc says this function returns either
a pointer or NULL, so let it do so.
Change-Id: Ib292f148914e67054f5d7b664077f19cba7000e4
Signed-off-by: Dariusz Stojaczyk
---
lib/librte_eal/common
EAL reserves a huge area in virtual address space
to provide virtual address contiguity for e.g.
future memory extensions (memory hotplug). During
memory hotplug, if the hugepage mmap succeeds but
doesn't suffice EAL's requiriments, the EAL would
unmap this mapping straight away, leaving a hole in
This isn't documented in the manuals, but a failed
mmap(..., MAP_FIXED) may still unmap overlapping
regions. In such case, we need to remap these regions
back into our address space to ensure mem contiguity.
We do it unconditionally now on mmap failure just to
be safe.
Verified on Linux 4.9.0-4-am
The value is not used, but some static analyzers may give out a
warning. Fix it by assigning default value of zero.
Bugzilla ID: 58
Fixes: cdc242f260e7 ("eal/linux: support running as unprivileged user")
Cc: benjamin.wal...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Anatoly Burakov
---
lib/li
Some static analyzers complain about it, even though
value is never used if not initialized. To avoid additional
false positives about a potential null-pointer dereferences,
also add a null-check.
Bugzilla ID: 58
Fixes: ea2dc1066870 ("vfio: add multi container support")
Cc: xiao.w.w...@intel.com
C
Parentheses were missing. It worked because macro is enclosed in
parentheses, so syntax was valid after macro expansion.
Bugzilla ID: 58
Fixes: 0a45657a6794 ("pci: rework interrupt handling")
Cc: sta...@dpdk.org
Signed-off-by: Anatoly Burakov
---
lib/librte_eal/linuxapp/eal/eal_interrupts.c | 2
> > Add template release notes for DPDK 18.08 with inline comments and
> > explanations of the various sections.
> >
> > Signed-off-by: Thomas Monjalon
>
> Merci.
De rien :)
> Acked-by: John McNamara
Applied
Hi Luca,
On Thu, 2018-05-31 at 11:26 +0100, Luca Boccassi wrote:
> Hello all,
>
> At this morning's release meeting (minutes coming soon from John), we
> briefly discussed the state of the regression testing for stable
> releases and agreed we need to formalise the process.
>
> At the moment we
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Thursday, May 31, 2018 10:11 PM
> To: dev@dpdk.org
> Cc: Mcnamara, John ; Kovacevic, Marko
>
> Subject: [PATCH] doc: add template release notes for 18.08
>
> Add template release notes for DPDK 18.08 with
58 matches
Mail list logo
