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')
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
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
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
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
> -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
> -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
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
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
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
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 ++
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
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 |
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
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.
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
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
>
>
> -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
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
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
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
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
22 matches
Mail list logo
