The macros to check that the function pointers and port ids are valid
for an ethdev are potentially useful to have in a common headers for
use with all PMDs. However, since they would then become externally
visible, we apply the RTE_ & RTE_ETH_ prefix to them as approtiate.
Signed-off-by: Declan D
Adding a new macro for specifying __aligned__ attribute, and updating the
current __rte_cache_aligned macro to use it.
Also adding a new macro to specify the __packed__ attribute
Signed-off-by: Declan Doherty
Acked-by: Sergio Gonzalez Monroy
---
lib/librte_eal/common/include/rte_memory.h | 14
Signed-off-by: Declan Doherty
Acked-by: Sergio Gonzalez Monroy
---
lib/librte_mbuf/rte_mbuf.h | 23 +++
1 file changed, 23 insertions(+)
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 4a93189..ef1ee26 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b
This patch contains the initial proposed APIs and device framework for
integrating crypto packet processing into DPDK.
features include:
- Crypto device configuration / management APIs
- Definitions of supported cipher algorithms and operations.
- Definitions of supported hash/authentication al
This library add support for adding a chain of offload operations to a
mbuf. It contains the definition of the rte_mbuf_offload structure as
well as helper functions for attaching offloads to mbufs and a mempool
management functions.
This initial implementation supports attaching multiple offload
This patch adds a PMD for the Intel Quick Assist Technology DH895xxC
hardware accelerator.
This patch depends on a QAT PF driver for device initialization. See
the file docs/guides/cryptodevs/qat.rst for configuration details
This patch supports a limited subset of QAT device functionality,
curre
This patch provides the initial implementation of the AES-NI multi-buffer
based crypto poll mode driver using DPDK's new cryptodev framework.
This PMD is dependent on Intel's multibuffer library, see the whitepaper
"Fast Multi-buffer IPsec Implementations on Intel? Architecture
Processors", see re
unit tests are run by using cryptodev_qat_autotest or
cryptodev_aesni_autotest from the test apps interactive console.
performance tests are run by using the cryptodev_qat_perftest or
cryptodev_aesni_mb_perftest command from the test apps interactive
console.
If you which to run the tests on a QA
This patch creates a new sample applicaiton based off the l2fwd
application which performs specified crypto operations on IP packet
payloads which are forwarding.
Signed-off-by: Declan Doherty
Acked-by: Sergio Gonzalez Monroy
---
MAINTAINERS|1 +
examples/Makefile
On Fri, Nov 13, 2015 at 11:40:09AM +, Bruce Richardson wrote:
> I don't think this patch is necessary, as all it adds is a single extra line
> to
> a comment.
>
> /Bruce
This one was previously merged. So indeed we can toss it.
This is what happens when you are restricted to 1 AM coding.
M
On Fri, Nov 13, 2015 at 12:49:36PM +0100, Thomas Monjalon wrote:
> I'm sad for you Bruce: you only see an empty line where you could catch
> the beauty of the star ;)
+1
> Matthew, obviously you failed your send.
You might find a more polite way than calling contributions failures. ;)
> As a ge
On Fri, Nov 13, 2015 at 11:48:41AM +, Ananyev, Konstantin wrote:
> Actually another question: are existing 8 levels not enough?
> Konstantin
Depends who you ask. I was modeling it based upon the following:
https://docs.oracle.com/javase/7/docs/api/java/util/logging/Level.html
The reason I ad
On Fri, Nov 13, 2015 at 08:07:41AM -0800, Stephen Hemminger wrote:
> I understand the motivation but the existing levels match syslog
> which are what you want for a production application.
>
> The new levels are only for developer logs. I don't think we want all
> the developer levels beyond debu
On Fri, Nov 13, 2015 at 11:44:03AM +, Bruce Richardson wrote:
> Why 11 log levels - it seems an odd number?
> Also, not sure about the {fine, finer, finest} names. My thinking would be to
> just start numbering them after DEBUG, so RTE_LOG_L9, RTE_LOG_L10 etc., which
> would allow us to add on
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of ibetts
> Sent: Thursday, October 29, 2015 3:09 PM
> To: dev at dpdk.org
> Cc: Betts, Ian
> Subject: [dpdk-dev] [PATCH v2 1/5] doc: add performance-thread sample
> application guide
>
> From: Ian Betts
>
> This
On Fri, Nov 13, 2015 at 08:41:43AM -0800, Stephen Hemminger wrote:
> -1
> This is already done by syslog and friends and adds more cruft to log
> messages.
On the console it is not.
Matthew.
> -Original Message-
> From: Matthew Hall [mailto:mhall at mhcomputing.net]
> Sent: Friday, November 13, 2015 6:49 PM
> To: Mcnamara, John
> Cc: Stephen Hemminger; Thomas Monjalon; dev at dpdk.org
> Subject: Re: [dpdk-dev] Coverity policy for upstream (base) drivers.
>
> On Fri, Nov 13, 20
On Fri, Nov 13, 2015 at 07:21:24PM +, Mcnamara, John wrote:
> Hi Matthew,
>
> I definitely be interested in getting SonarQube working with DPDK. We can
> sync up on this as soon as the 2.2 bush fires die down.
>
> John.
Awesome! Looking forward to it.
On Fri, 13 Nov 2015 19:21:24 +
"Mcnamara, John" wrote:
> > -Original Message-
> > From: Matthew Hall [mailto:mhall at mhcomputing.net]
> > Sent: Friday, November 13, 2015 6:49 PM
> > To: Mcnamara, John
> > Cc: Stephen Hemminger; Thomas Monjalon; dev at dpdk.org
> > Subject: Re: [dpdk-
Hello,
When I try to build dpdk 2.1 on rhel 7.2 rc1 I am getting following errors,
appreciate if somebody could suggest a workaround of this problem. Thank you,
Serguei
CC [M]
/root/dpdk/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/igb_main.o
/root/dpdk/x86_64-native-linuxa
On Fri, Nov 13, 2015 at 11:38:22AM -0800, Stephen Hemminger wrote:
> It looked like SonarQube was both non-free for doing any real scans,
> and the default C rules were oriented towards a completely different
> Windows oriented coding style.
I was using the free version to do SA dashboad for a tea
2015-11-13 13:13, Aws Ismail:
> On Fri, Nov 13, 2015 at 11:40 AM, Thomas Monjalon
> wrote:
> > 2015-11-13 11:32, Aws Ismail:
> >> I have looked at the ixgbe PMD code and I can see 0x15AD being
> >> mentioned in the device list but I am unable to fully use it even with
> >> the testpmd app.
> >
> >
The dpdk nic bind script seems to see them correctly but when running
testpmd with those ports, they always come with link status down.
>From the dpdk_nic_bind script (snip):
Network devices using DPDK-compatible driver
:03:00.0 'Ethernet Connectio
--no-pci is cool. I'm pretty sure that wasn't there when the PCI scan was first
added to
the library init routine. I'm glad to see it, so thanks for pointing it out.
Just for the record: The comment says, "for debug purposes, PCI can be
disabled".
This exhibits one of those classic DPDK blindspo
101 - 124 of 124 matches
Mail list logo
