[dpdk-dev] About "Multi-process" sample application
hi,all I tried to run multi-process sample application step by step according to the document of "sample_application_user_guide.pdf", but encount a problem: only the first rx_queue can receive packages, the other three rx_queue have no package at all. How could this happen? Did I need to do some other configuration? Any help will be appreciate. Best regards. Maria
[dpdk-dev] Looks like rte_mempool_free_count() and rte_mempool_count() are swapped
Greetings.
I had a suspect I run into a mbuf depletion issue and decided to check
using rte_mempool_free_count(). To my surprise, it returned a value
equal to mempool size. I tried calling rte_mempool_count() and it
returned zero.
I inspected the code in dpdk-1.3.1-7 and dpdk.1.4.1-4:
rte_mempool_count(const struct rte_mempool *mp)
{
unsigned count;
count = rte_ring_count(mp->ring);
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
{
unsigned lcore_id;
if (mp->cache_size == 0)
return count;
for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++)
count += mp->local_cache[lcore_id].len;
}
#endif
/*
* due to race condition (access to len is not locked), the
* total can be greater than size... so fix the result
*/
if (count > mp->size)
return mp->size;
return count;
}
If I understand it correctly, the ring contains free buffers and
rte_ring_count() returns a number of entries inside a ring. So this
function actually calculates the number of free entries, not busy.
Moreover, rte_mempool_count() is used in many places. For example it's
called in rte_mempool_free_count() and rte_mempool_full().
Can anyone confirm or refute my findings?
Regards,
Dmitry
[dpdk-dev] QinQ and MPLS
Double VLAN is supported by Intel DPDK on most (if not all) Intel NIC. -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen Hemminger Sent: Thursday, September 05, 2013 11:08 PM To: ?? ??? Cc: dev at dpdk.org Subject: Re: [dpdk-dev] QinQ and MPLS On Thu, 05 Sep 2013 10:24:53 +0400 ?? ??? wrote: > Hi to everyone! > > A couple of questions about DPDK: > > 1. Can Intel DPDK work with double tagged ethernet frames? To read frame with > 2 tags and to write frame to the wire with two tags (QinQ technology) > > 2. Can Intel DPDK read and write MPLS tags? > ? > -- > ??? It reads/writes raw packets, what protocol you want to use is up to you.
[dpdk-dev] [PATCH] pci: fix closing an unopened file descriptor
04/09/2013 09:34, Tetsuya Mukawa :
> If CONFIG_RTE_EAL_UNBIND_PORTS is set and virtio-net is used, an unopened
> file descriptor will be illegally closed in the finalized phase of EAL.
> The fix adds a correct initial value to the file descriptor, and check it
> before closing it.
>
> Signed-off-by: Tetsuya Mukawa
Thanks for the patch.
I have reproduced the issue only once.
It seems that fd 0 is open most of the time.
But the patch seems OK so I applied it with light modifications:
---
pci: fix closing an unopened file descriptor
If CONFIG_RTE_EAL_UNBIND_PORTS is set and a non Intel PMD is used, an unopened
file descriptor will be illegally closed in the finalized phase of EAL.
The fix adds a correct initial value to the file descriptor, and check it
before closing it.
Signed-off-by: Tetsuya Mukawa
Acked-by: Thomas Monjalon
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -514,6 +514,7 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t
bus,
}
memset(dev, 0, sizeof(*dev));
+ dev->intr_handle.fd = -1;
dev->addr.domain = domain;
dev->addr.bus = bus;
dev->addr.devid = devid;
@@ -718,7 +719,7 @@ pci_exit_process(struct rte_pci_device *dev)
RTE_LOG(ERR, EAL, "Error with munmap\n");
return -1;
}
- if (close(dev->intr_handle.fd) == -1){
+ if ((dev->intr_handle.fd != -1) && (close(dev->intr_handle.fd) == -1)) {
RTE_LOG(ERR, EAL, "Error closing interrupt handle\n");
return -1;
}
[dpdk-dev] [PATCH 1/4] kni: fix build with kernel 3.8
Le 29/07/2013 14:44, Thomas Monjalon a ?crit : > - timecompare has been removed. > (see Linux commit 65f8f9a1c1db831e5159e3e3e50912d1f214cd0c) All this code is between 'ifdef HAVE_HW_TIME_STAMP'. Maybe just deactivating it will help to port patches on this driver in the future. > > - annotations __devinit and __devexit have been removed. Done in 54b956b90360 Remove __dev* markings from init.h
[dpdk-dev] [PATCH 2/4] kni: fix build with kernel 3.9
Le 29/07/2013 14:44, Thomas Monjalon a ?crit : > hlist API has changes. > See Linux commit b67bfe0d42cac56c512dd5da4b1b347a23f4b70a. > > Signed-off-by: Thomas Monjalon Acked-by: Nicolas Dichtel
[dpdk-dev] [PATCH 4/4] app: fix build with gcc 4.8
Le 29/07/2013 14:44, Thomas Monjalon a ?crit :
> GCC 4.8 was producing this error:
> argument to ?sizeof? in ?strncmp? call is the same expression as the
> second source; did you mean to provide an explicit length?
> [-Werror=sizeof-pointer-memaccess]
>
> Signed-off-by: Thomas Monjalon
> ---
> app/test/test_cmdline_string.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/app/test/test_cmdline_string.c b/app/test/test_cmdline_string.c
> index 7b358cf..84a82ce 100644
> --- a/app/test/test_cmdline_string.c
> +++ b/app/test/test_cmdline_string.c
> @@ -383,7 +383,7 @@ test_parse_string_valid(void)
> return -1;
> }
> if (strncmp(buf, string_elt_strs[i].result,
> - sizeof(string_elt_strs[i].result)) != 0) {
> + sizeof(buf)) != 0) {
In fact, it seems you can use strcmp() instead of strncmp(). Or, if the
intention was really to check the length, use strlen(), but this one will not
include the last '\0'.
[dpdk-dev] [PATCH 3/4] kni: fix build with kernel 3.10
Le 29/07/2013 14:44, Thomas Monjalon a ?crit : > - The flags NETIF_F_HW_VLAN_* have been renamed to NETIF_F_HW_VLAN_CTAG_*. > See Linux commit f646968f8f7c624587de729115d802372b9063dd. > > - The VLAN protocol must be specified. > See Linux commits 86a9bad3ab6b6f858fd4443b48738cabbb6d094c > and 80d5c3689b886308247da295a228a54df49a44f6. > > Signed-off-by: Thomas Monjalon Acked-by: Nicolas Dichtel
