Hi All,
I was going over vhost-user migration capability in DPDK in lieu of a Cisco's
multi-q DPDK vhost-user application. I see that log_base address is implemented
as per virtio_net device. However, desc, addr and used is per vhost_virtqueue.
Additionally, QEMU sends one VHOST_USER_SET_LOG_BA
Is there a way where we can just define the fields that ought to be there in
the mbuf structure, but the position and size is implementation dependent ? The
application can provide "mbuf_impl.h" that contains mbuf_rte fields in the
order that seems appropriate to application.
--
- Thanks
char *
NO_TX_OFFLOAD only changes the layout in terms of relative field location in
cache lines, and does not eliminate the fields themselves
why should the using code be affected?
On Mon, Nov 2, 2015 at 8:30 PM, shesha Sreenivasamurthy (shesha) mailto:shesha at cisco.com>> wrote:
One issue I se
the
structure replacements,
creating your custom version, and placing it instead of the installed copy
of rte_mbuf.h.
Maybe the only facility required from dpdk is just the ability to register
calls to such user scripts at some install stage(s), providing the mean
along with responsibility to
In Cisco, we are using DPDK for a very high speed packet processor application.
We don't use NIC TCP offload / RSS hashing. Putting those fields in the first
cache-line - and the obligatory mb->next datum in the second cache line -
causes significant LSU pressure and performance degradation. If
does not need those backing files can remove them, thus
not changing the current default behavior. The application itself can
clean it up, however the rationale behind DPDK cleaning it up is, DPDK
created it and therefore, it is better it unlinks it.
Signed-off-by: Shesha Sreenivasamurthy
Acked-by
that does not
need those backing files can remove them, thus not changing the current default
behavior. The application itself can clean it up, however the rationale behind
DPDK cleaning it up is, DPDK created it and therefore, it is better it unlinks
it.
Signed-off-by: Shesha Sreenivasamurthy
that does not
need those backing files can remove them, thus not changing the current default
behavior. The application itself can clean it up, however the rationale behind
DPDK cleaning it up is, DPDK created it and therefore, it is better it unlinks
it.
Signed-off-by: Shesha Sreenivasamurthy
does not need those backing files can remove them, thus
not changing the current default behavior. The application itself can
clean it up, however the rationale behind DPDK cleaning it up is, DPDK
created it and therefore, it is better it unlinks it.
Signed-off-by: Shesha Sreenivasamurthy
Acked-by
does not need those backing files can remove them, thus
not changing the current default behavior. The application itself can
clean it up, however the rationale behind DPDK cleaning it up is, DPDK
created it and therefore, it is better it unlinks it.
Signed-off-by: Shesha Sreenivasamurthy
Acked
Employee
Cc: "dev at dpdk.org" , Bruce Richardson
Subject: Re: [dpdk-dev] [PATCH v3] mem: command line option to delete
hugepage backing files
On 22/10/2015 17:03, shesha Sreenivasamurthy (shesha) wrote:
> Sergio,
>Your comment regarding remap_all_functions is correct and c
mmand line option to delete
hugepage backing files
On 21/10/2015 17:34, Bruce Richardson wrote:
> On Wed, Oct 21, 2015 at 04:22:45PM +, shesha Sreenivasamurthy
>(shesha) wrote:
>> When an application using huge-pages crash or exists, the hugetlbfs
>> backing files are not cleaned
does not need those backing files can remove them, thus
not changing the current default behavior. The application itself can
clean it up, however the rationale behind DPDK cleaning it up is, DPDK
created it and therefore, it is better it unlinks it.
Signed-off-by: Shesha Sreenivasamurthy
does not need those backing files can remove them, thus
not changing the current default behavior. The application itself can
clean it up, however the rationale behind DPDK cleaning it up is, DPDK
created it and therefore, it is better it unlinks it.
Signed-off-by: Shesha Sreenivasamurthy
---
lib
does not need those backing files can remove them, thus
not changing the current default behavior. The application itself can
clean it up, however the rationale behind DPDK cleaning it up is, DPDK
created it and therefore, it is better it unlinks it.
Signed-off-by: Shesha Sreenivasamurthy
---
lib
that does not
need those backing files can remove them, thus not changing the current default
behavior. The application itself can clean it up, however the rationale behind
DPDK cleaning it up is, DPDK created it and therefore, it is better it unlinks
it.
Signed-off-by: Shesha Sreenivasamurthy
When an application using huge-pages crash or exists, the hugetlbfs backing
files are not cleaned up. This is a patch to clean those files. There are
multi-process DPDK applications that may be benefited by those backing files.
Therefore, I have made that configurable so that the application tha
---
lib/librte_eal/common/eal_common_options.c | 12 ++
lib/librte_eal/common/eal_internal_cfg.h | 1 +
lib/librte_eal/common/eal_options.h| 2 ++
lib/librte_eal/linuxapp/eal/eal_memory.c | 37 ++
4 files changed, 52 insertions(+)
diff --git a/lib/libr
g hugepage backing file after initialiation
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of shesha Sreenivasamurthy
(shesha)
Sent: Wednesday, September 30, 2015 10:44 PM
To: dev at dpdk.org<mailto:dev at dpdk.org>
Cc: Michael S. Tsirkin
Subject: Re: [dpdk-dev] U
.org<mailto:dev at dpdk.org>" mailto:dev at
dpdk.org>>
Subject: Re: [dpdk-dev] Unlinking hugepage backing file after initialiation
On Tue, Sep 29, 2015 at 05:50:00PM +, shesha Sreenivasamurthy (shesha)
wrote:
Sure. Then, is there any real reason why the backing files should not be
unlinked ?
AFAIK qemu unlinks them already.
--
MST
: Cisco Employee mailto:shesha at cisco.com>>
Cc: "Xie, Huawei" mailto:huawei.xie at intel.com>>,
"dev at dpdk.org<mailto:dev at dpdk.org>" mailto:dev at
dpdk.org>>
Subject: Re: [dpdk-dev] Unlinking hugepage backing file after initialiation
On Tue, Sep 29, 2015 at 0
cking file after initialiation
On 9/29/2015 10:38 AM, Xie, Huawei wrote:
On 9/29/2015 8:04 AM, shesha Sreenivasamurthy (shesha) wrote:
Hello,
As of DPDK2.1, backing files are created in hugetablefs during mapping (in
eal_memory.c::rte_eal_hugepage_init()) and these files are not cleaned up
mailto:dev at dpdk.org>>
Subject: Re: [dpdk-dev] Unlinking hugepage backing file after initialiation
On Tue, Sep 29, 2015 at 09:03:15AM +, Ananyev, Konstantin wrote:
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of shesha
> Sreenivasamurth
Additional info:
Before staring Application:
-
cat /sys/devices/system/node/node*/meminfo | grep HugePages_
Node 0 HugePages_Total: 2048
Node 0 HugePages_Free: 2048
Node 0 HugePages_Surp: 0
Node 1 HugePages_Total: 2048
Node 1 HugePages_Free: 2048
Nod
Hello,
As of DPDK2.1, backing files are created in hugetablefs during mapping (in
eal_memory.c::rte_eal_hugepage_init()) and these files are not cleaned up
(unlinked) after initialization (mmap-ing). This means, when the application
crashes or stopped, the memory is still consumed. Therefore, is
25 matches
Mail list logo
