[dpdk-dev] [RFC PATCH 0/4] pktdev

On 17/04/15 17:16, Bruce Richardson wrote: > Hi all, > > to continue this discussion a bit more, here is my, slightly different, slant > on what a pktdev abstraction may look like. > > The primary objective I had in mind when drafting this is to provide the > minimal abstraction that can be *easi

[dpdk-dev] [RFC PATCH 0/4] pktdev

Hi Marc and Bruce, On 4/17/15, 1:49 PM, "Marc Sune" wrote: > > >On 17/04/15 17:16, Bruce Richardson wrote: >> Hi all, >> >> to continue this discussion a bit more, here is my, slightly different, >>slant >> on what a pktdev abstraction may look like. >> >> The primary objective I had in mind whe

[dpdk-dev] [RFC PATCH 4/4] example app showing pktdevs used in a chain

This is a trivial example showing code which is using ethdevs and rings in a neutral manner, with the same piece of pipeline code passing mbufs along a chain without ever having to query its source or destination type. --- examples/pktdev/Makefile | 57 examples/pktdev/basicfwd.c |

[dpdk-dev] [RFC PATCH 3/4] add support for a ring to be a pktdev

Add a new public API function, and two internal wrapper functions so we can use ring as a pktdev. --- lib/librte_ring/rte_ring.c | 41 + lib/librte_ring/rte_ring.h | 3 +++ 2 files changed, 44 insertions(+) diff --git a/lib/librte_ring/Makefile b/lib/librt

[dpdk-dev] [RFC PATCH 2/4] Make ethdev explicitly a subclass of pktdev

This patch allows us to take an ethdev port id and get from it a generic pktdev object that we can call using the pktdev routines, if we like. Change the actual rx/tx calls in the ethdev api to call the pktdev versions - which becuase of inlining will work the same as before, with no impact. --- l

[dpdk-dev] [RFC PATCH 1/4] Add example pktdev implementation

This commit demonstrates what a minimal API for all packet handling types would look like. It simply provides the necessary parts for receiving and transmiting packets, and is based off the ethdev implementation. --- config/common_bsdapp | 5 ++ config/common_linuxapp | 5 ++

[dpdk-dev] [RFC PATCH 0/4] pktdev

Hi all, to continue this discussion a bit more, here is my, slightly different, slant on what a pktdev abstraction may look like. The primary objective I had in mind when drafting this is to provide the minimal abstraction that can be *easily* used as a common device abstraction for existing (an

[dpdk-dev] [PATCH] hash: update jhash function with the latest available

> -Original Message- > From: Richardson, Bruce > Sent: Thursday, April 16, 2015 3:01 PM > To: De Lara Guarch, Pablo > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] hash: update jhash function with the latest > available > > On Thu, Apr 16, 2015 at 02:26:59PM +0100, Pablo de Lara

[dpdk-dev] [RFC PATCH 3/4] add support for a ring to be a pktdev

On Fri, Apr 17, 2015 at 04:16:43PM +0100, Bruce Richardson wrote: > Add a new public API function, and two internal wrapper functions so we > can use ring as a pktdev. > --- > lib/librte_ring/rte_ring.c | 41 + > lib/librte_ring/rte_ring.h | 3 +++ > 2 file

[dpdk-dev] [RFC PATCH 0/4] pktdev

On Fri, Apr 17, 2015 at 04:16:40PM +0100, Bruce Richardson wrote: > Hi all, > > to continue this discussion a bit more, here is my, slightly different, slant > on what a pktdev abstraction may look like. > > The primary objective I had in mind when drafting this is to provide the > minimal abstr

[dpdk-dev] help on exception path for ivshmem guest

Hi, I'm trying to reproduce the exception path example, but in a ivshmem guest machine. To avoid memory corruption, I can't call rte_pktmbuf_alloc and rte_pktmbuf_free from the guest. When I get packets from the host, it is easy to send them to the tap interface. But How to take packets from tap

[dpdk-dev] [PATCH 0/2] functions with useless return

On Fri, Apr 17, 2015 at 08:35:32AM -0700, Stephen Hemminger wrote: > Fix a couple of cases (there are more) where functions > always return 0, by changing them to be void. > > Stephen Hemminger (2): > log: rte_openlog_stream should be void > eal: pci probe and adjust_config should be void > >

[dpdk-dev] mempool deleting and cache_size

Hi, On 15/04/15 20:15, Zoltan Kiss wrote: > Hi, > > I have two questions regarding mempools: > > - the first is trivial: how do you delete them? Can you? I can't see a > function to do that, and none of the examples are doing such thing. When > exactly it get deleted? > - during creation, cache_si

[dpdk-dev] [PATCH v3 2/2] use simple zero initializers

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Thursday, April 16, 2015 11:11 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v3 2/2] use simple zero initializers Acked-by: John McNamara

[dpdk-dev] [PATCH v3 1/2] mk: fix build with gcc 4.4 and clang

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Thursday, April 16, 2015 11:11 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v3 1/2] mk: fix build with gcc 4.4 and clang Acked-by: John McNamara

[dpdk-dev] mempool deleting and cache_size

On 16/04/15 11:26, Gonzalez Monroy, Sergio wrote: > On 16/04/2015 10:22, Marc Sune wrote: >> >> >> On 16/04/15 11:03, Gonzalez Monroy, Sergio wrote: >>> On 15/04/2015 20:24, Stephen Hemminger wrote: On Wed, 15 Apr 2015 20:15:18 +0100 Zoltan Kiss wrote: > Hi, > > I have

[dpdk-dev] [PATCH 2/2] eal: pci probe and adjust_config should be void

This functions always returned 0 and therefore should be void. Signed-off-by: Stephen Hemminger --- lib/librte_eal/common/eal_common_options.c | 3 +-- lib/librte_eal/common/eal_common_pci.c | 7 ++- lib/librte_eal/common/eal_options.h| 2 +- lib/librte_eal/common/include/rte_pci

[dpdk-dev] [PATCH 1/2] log: rte_openlog_stream should be void

Function always returned 0 and no one was checking anyway. Signed-off-by: Stephen Hemminger --- lib/librte_eal/common/eal_common_log.c | 3 +-- lib/librte_eal/common/include/rte_log.h | 5 + 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/lib/librte_eal/common/eal_common_log.

[dpdk-dev] [PATCH 0/2] functions with useless return

Fix a couple of cases (there are more) where functions always return 0, by changing them to be void. Stephen Hemminger (2): log: rte_openlog_stream should be void eal: pci probe and adjust_config should be void lib/librte_eal/common/eal_common_log.c | 3 +-- lib/librte_eal/common/eal_com

[dpdk-dev] [PATCH 0/2] PCI cleanups

On Thu, Apr 16, 2015 at 04:23:38PM -0700, Stephen Hemminger wrote: > More places where PCI code should be using const but wasn't > > Stephen Hemminger (2): > pci: make device_id tables const > pci: allow const for rte_pci_addr > > app/test/virtual_pmd.c | 3 +-- > lib/librt

[dpdk-dev] [PATCH v3 2/2] use simple zero initializers

To initialize a structure with zeros, one field was explicitly set to avoid "missing initializer" bug with old GCC (e.g. 4.4). This warning is now disabled (commit ) for old versions of GCC, so the workarounds may be removed. These initializers should not be needed for static variables but they ar

[dpdk-dev] [PATCH v3 1/2] mk: fix build with gcc 4.4 and clang

With GCC 4.4.7 from CentOS 6.5, the following errors arise: lib/librte_pmd_ixgbe/ixgbe_rxtx.c: In function 'ixgbe_dev_rx_queue_setup': lib/librte_pmd_ixgbe/ixgbe_rxtx.c:2509: error: missing initializer lib/librte_pmd_ixgbe/ixgbe_rxtx.c:2509: error: (near initialization for 'dev_info.driver_name')