-Original Message-
From: Kusztal, ArkadiuszX
Sent: Tuesday, August 9, 2016 1:58 PM
To: dev at dpdk.org
Cc: Trahe, Fiona ; Jain, Deepak K ; De Lara Guarch, Pablo ; Griffin,
John ; Kusztal, ArkadiuszX
Subject: [PATCH 0/2] Add HMAC_MD5 to Intel QuickAssist Technology driver
This
There is no need for the page files to be readable (and executable) by
other users. This can be exploited by non-privileged users to access the
working memory of a DPDK app.
Open the files with 0600.
Signed-off-by: Robin Jarry
---
lib/librte_eal/linuxapp/eal/eal_memory.c | 4 ++--
1 file
On Tue, Aug 09, 2016 at 02:47:44PM -0700, John Fastabend wrote:
> On 16-08-04 06:24 AM, Adrien Mazarguil wrote:
> > On Wed, Aug 03, 2016 at 12:11:56PM -0700, John Fastabend wrote:
[...]
> >> The problem is keeping priorities in order and/or possibly breaking
> >> rules apart (e.g. you have an L2
On Mon, Aug 8, 2016 at 11:10 AM, Ferruh Yigit wrote:
> On 8/8/2016 7:36 AM, David Marchand wrote:
>> The only thing that bothers me using this ("unsynchronised") internal
>> pci device list is that, if people were using the ethtool part of kni,
>> there would now be devices that won't be
On Tue, Aug 09, 2016 at 02:24:26PM -0700, John Fastabend wrote:
[...]
> > Just an idea, could some kind of meta pattern items specifying time
> > constraints for a rule address this issue? Say, how long (cycles/ms) the PMD
> > may take to query/apply/delete the rule. If it cannot be guaranteed,
Firstly, sorry about the late reply.
> From my view, crc-strip is not a "MUST" check for the port start. We can
> configure the value after
> the port start.
> Any thoughts?
>From my perspective, a non-supported configuration should return an
error code to the API user.
> Do you know is there
Hi Gopakumar,
On 8/4/2016 5:14 PM, Ferruh Yigit wrote:
> On 8/1/2016 10:19 PM, Gopakumar Choorakkot Edakkunni wrote:
>> Well, for my purpose I just ended up creating a seperate/smaller pool
>> earlier during bootup to try to guarantee its from one memseg.
>>
>> But I am assuming that this KNI
Use mempool buf_addr and buf_physaddr fields for address translation.
Since each mbuf address calculated separately, the restriction of all
mbufs should come from a continuous memory restriction is no more valid.
mbuf related FIFO's content changed, rx_q and alloc_q now carries
physical address
On 8/4/2016 3:51 PM, Vaibhav Sood wrote:
Hi,
> Hi!
>
> I am looking at running DPDK in a VM, I would like to know if there are any
> limitations when doing this in terms of any DPDK features that do not work in
> a VM
>
We do run DPDK in VM, and we have not come across any major limitations.
On 16-08-10 06:37 AM, Adrien Mazarguil wrote:
> On Tue, Aug 09, 2016 at 02:47:44PM -0700, John Fastabend wrote:
>> On 16-08-04 06:24 AM, Adrien Mazarguil wrote:
>>> On Wed, Aug 03, 2016 at 12:11:56PM -0700, John Fastabend wrote:
> [...]
The problem is keeping priorities in order and/or
On 16-08-10 04:02 AM, Adrien Mazarguil wrote:
> On Tue, Aug 09, 2016 at 02:24:26PM -0700, John Fastabend wrote:
> [...]
>>> Just an idea, could some kind of meta pattern items specifying time
>>> constraints for a rule address this issue? Say, how long (cycles/ms) the PMD
>>> may take to
Hi, Jianbo
I have tested you patch , this v3 patch didn't impact the performance on X86
platform.
Non-vector PMD single core performance with patch : ~35 Mpps
Non-vector PMD single core performance without patch: ~35 Mpps
BRs
Lei
-Original Message-
Date: Fri,
On Tue, Aug 09, 2016 at 09:48:46AM +0100, Bruce Richardson wrote:
> On Tue, Aug 09, 2016 at 06:31:41AM +0530, Jerin Jacob wrote:
> > Find below the URL for the complete API specification.
> >
> > https://rawgit.com/jerinjacobk/libeventdev/master/rte_eventdev.h
> >
> > I have created a supportive
13 matches
Mail list logo
