[dpdk-dev] [PATCH v2] net/ring: remove unnecessary NULL check
Dear Ferruh,
You are right, I messed up the brackets.
I already sent v3.
Thanks,
Mauricio.
On 11/02/2016 08:15 AM, Ferruh Yigit wrote:
> On 11/2/2016 12:49 PM, Fulvio Risso wrote:
>> Dear Ferruh,
>> Maybe I'm wrong, but I cannot see your point.
>> The code is absolutely the same, only the following line
>>
>> if (eth_dev->data) {
>>
>> is actually removed.
> Please double check the condition "rx_queues" freed:
>
> before the patch:
> ==
> if (eth_dev->data) {
>internals = eth_dev->data->dev_private;
>if (internals->action == DEV_CREATE) {
> /*
> * it is only necessary to delete the rings in rx_queues because
> * they are the same used in tx_queues
> */
> for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
>r = eth_dev->data->rx_queues[i];
>rte_ring_free(r->rng);
> }
>}
>
>rte_free(eth_dev->data->rx_queues);
>rte_free(eth_dev->data->tx_queues);
>rte_free(eth_dev->data->dev_private);
> }
> ==
>
>
> After the patch:
> ==
> internals = eth_dev->data->dev_private;
> if (internals->action == DEV_CREATE) {
>/*
> * it is only necessary to delete the rings in rx_queues because
> * they are the same used in tx_queues
> */
>for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
> r = eth_dev->data->rx_queues[i];
> rte_ring_free(r->rng);
>}
>
>rte_free(eth_dev->data->rx_queues);
>rte_free(eth_dev->data->tx_queues);
>rte_free(eth_dev->data->dev_private);
> }
> ==
>
>
> Thanks,
> ferruh
>
[dpdk-dev] [PATCH v3] net/ring: remove unnecessary NULL check
Coverity detected this as an issue because internals->data will never be NULL,
then the check is not necessary.
Fixes: d082c0395bf6 ("ring: fix memory leak when detaching")
Coverity issue: 137873
Signed-off-by: Mauricio Vasquez B
---
drivers/net/ring/rte_eth_ring.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
index 6d2a8c1..c1767c4 100644
--- a/drivers/net/ring/rte_eth_ring.c
+++ b/drivers/net/ring/rte_eth_ring.c
@@ -599,24 +599,22 @@ rte_pmd_ring_remove(const char *name)
eth_dev_stop(eth_dev);
- if (eth_dev->data) {
- internals = eth_dev->data->dev_private;
- if (internals->action == DEV_CREATE) {
- /*
-* it is only necessary to delete the rings in
rx_queues because
-* they are the same used in tx_queues
-*/
- for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
- r = eth_dev->data->rx_queues[i];
- rte_ring_free(r->rng);
- }
+ internals = eth_dev->data->dev_private;
+ if (internals->action == DEV_CREATE) {
+ /*
+* it is only necessary to delete the rings in rx_queues because
+* they are the same used in tx_queues
+*/
+ for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
+ r = eth_dev->data->rx_queues[i];
+ rte_ring_free(r->rng);
}
-
- rte_free(eth_dev->data->rx_queues);
- rte_free(eth_dev->data->tx_queues);
- rte_free(eth_dev->data->dev_private);
}
+ rte_free(eth_dev->data->rx_queues);
+ rte_free(eth_dev->data->tx_queues);
+ rte_free(eth_dev->data->dev_private);
+
rte_free(eth_dev->data);
rte_eth_dev_release_port(eth_dev);
--
1.9.1
[dpdk-dev] [PATCH v2] net/ring: remove unnecessary NULL check
Coverity detected this as an issue because internals->data will never be NULL,
then the check is not necessary.
Fixes: d082c0395bf6 ("ring: fix memory leak when detaching")
Coverity issue: 137873
Signed-off-by: Mauricio Vasquez B
---
drivers/net/ring/rte_eth_ring.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
index 6d2a8c1..5ca00ed 100644
--- a/drivers/net/ring/rte_eth_ring.c
+++ b/drivers/net/ring/rte_eth_ring.c
@@ -599,17 +599,15 @@ rte_pmd_ring_remove(const char *name)
eth_dev_stop(eth_dev);
- if (eth_dev->data) {
- internals = eth_dev->data->dev_private;
- if (internals->action == DEV_CREATE) {
- /*
-* it is only necessary to delete the rings in
rx_queues because
-* they are the same used in tx_queues
-*/
- for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
- r = eth_dev->data->rx_queues[i];
- rte_ring_free(r->rng);
- }
+ internals = eth_dev->data->dev_private;
+ if (internals->action == DEV_CREATE) {
+ /*
+* it is only necessary to delete the rings in rx_queues because
+* they are the same used in tx_queues
+*/
+ for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
+ r = eth_dev->data->rx_queues[i];
+ rte_ring_free(r->rng);
}
rte_free(eth_dev->data->rx_queues);
--
1.9.1
[dpdk-dev] [PATCH] pmd_ring: fix coverity issue
internals->data will never be NULL, so the check is not necessary.
Fixes: d082c0395bf6 ("ring: fix memory leak when detaching")
Coverity issue: 137873
Signed-off-by: Mauricio Vasquez B
---
drivers/net/ring/rte_eth_ring.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
index 6d2a8c1..5ca00ed 100644
--- a/drivers/net/ring/rte_eth_ring.c
+++ b/drivers/net/ring/rte_eth_ring.c
@@ -599,17 +599,15 @@ rte_pmd_ring_remove(const char *name)
eth_dev_stop(eth_dev);
- if (eth_dev->data) {
- internals = eth_dev->data->dev_private;
- if (internals->action == DEV_CREATE) {
- /*
-* it is only necessary to delete the rings in
rx_queues because
-* they are the same used in tx_queues
-*/
- for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
- r = eth_dev->data->rx_queues[i];
- rte_ring_free(r->rng);
- }
+ internals = eth_dev->data->dev_private;
+ if (internals->action == DEV_CREATE) {
+ /*
+* it is only necessary to delete the rings in rx_queues because
+* they are the same used in tx_queues
+*/
+ for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
+ r = eth_dev->data->rx_queues[i];
+ rte_ring_free(r->rng);
}
rte_free(eth_dev->data->rx_queues);
--
1.9.1
[dpdk-dev] Problem Generating Traffic
Hello, While performing a series of throughput testing I found a limitation while generating traffic. I have a server equipped with two 10G NICs that are connected using a Ethernet wire. MoonGen is used to generate traffic on these interfaces, it shows a performance of 22.52 Mpps. Theoretically it should be 29.76 Mpps (14.88x2) while using 64 bytes long packets. I tried to implemente a silly traffic generator by myself [1], It uses 4 cores, 2 for sending and 2 for receiving, however in this case the throughput is still 22.52 Mpps. I tried many different things, change the number of descriptors in the NIC, use separated mempools, run two separated DPDK processes, change the burst size, change the mempool parameters, however the maximum throughput I can get is always 22.52 Mpps. My question is, what could be the bottleneck in this case?, is the PCI-e bus an option? Any other cue? Just in case, the server's characteristics: - Intel Xeon E5-2690 v2 @ 3 GHz (ten physical cores plus hyperthreading) - 64 GB RAM, Ubuntu 15.04, equipped with two 10G Intel 82599ES NICs. - DPDK 16.07 Thanks in Advance, Mauricio V. [1] http://pastebin.com/k565gW6x
[dpdk-dev] [PATCH] fix documentation error on debug functions
Previous patch updated the functions without updating all the comments.
Fixes: 591a9d7985c1 ("add FILE argument to debug functions")
Signed-off-by: Mauricio Vasquez B
---
lib/librte_eal/common/include/rte_malloc.h | 2 +-
lib/librte_eal/common/include/rte_memory.h | 2 +-
lib/librte_eal/common/include/rte_memzone.h | 2 +-
lib/librte_eal/common/include/rte_tailq.h | 2 +-
lib/librte_mbuf/rte_mbuf.h | 2 +-
lib/librte_mempool/rte_mempool.h| 2 +-
lib/librte_ring/rte_ring.h | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/lib/librte_eal/common/include/rte_malloc.h
b/lib/librte_eal/common/include/rte_malloc.h
index 74bb78c..008ce13 100644
--- a/lib/librte_eal/common/include/rte_malloc.h
+++ b/lib/librte_eal/common/include/rte_malloc.h
@@ -294,7 +294,7 @@ rte_malloc_get_socket_stats(int socket,
/**
* Dump statistics.
*
- * Dump for the specified type to the console. If the type argument is
+ * Dump for the specified type to a file. If the type argument is
* NULL, all memory types will be dumped.
*
* @param f
diff --git a/lib/librte_eal/common/include/rte_memory.h
b/lib/librte_eal/common/include/rte_memory.h
index d9e8c21..526cfba 100644
--- a/lib/librte_eal/common/include/rte_memory.h
+++ b/lib/librte_eal/common/include/rte_memory.h
@@ -158,7 +158,7 @@ phys_addr_t rte_mem_virt2phy(const void *virt);
const struct rte_memseg *rte_eal_get_physmem_layout(void);
/**
- * Dump the physical memory layout to the console.
+ * Dump the physical memory layout to a file.
*
* @param f
* A pointer to a file for output
diff --git a/lib/librte_eal/common/include/rte_memzone.h
b/lib/librte_eal/common/include/rte_memzone.h
index dae98f5..ddd48f1 100644
--- a/lib/librte_eal/common/include/rte_memzone.h
+++ b/lib/librte_eal/common/include/rte_memzone.h
@@ -275,7 +275,7 @@ int rte_memzone_free(const struct rte_memzone *mz);
const struct rte_memzone *rte_memzone_lookup(const char *name);
/**
- * Dump all reserved memzones to the console.
+ * Dump all reserved memzones to a file.
*
* @param f
* A pointer to a file for output
diff --git a/lib/librte_eal/common/include/rte_tailq.h
b/lib/librte_eal/common/include/rte_tailq.h
index cc3c0f1..3a623bf 100644
--- a/lib/librte_eal/common/include/rte_tailq.h
+++ b/lib/librte_eal/common/include/rte_tailq.h
@@ -107,7 +107,7 @@ struct rte_tailq_elem {
RTE_TAILQ_CAST(rte_eal_tailq_lookup(name), struct_name)
/**
- * Dump tail queues to the console.
+ * Dump tail queues to a file.
*
* @param f
* A pointer to a file for output
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 7ea66ed..09a5253 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -1989,7 +1989,7 @@ static inline int rte_pktmbuf_chain(struct rte_mbuf
*head, struct rte_mbuf *tail
}
/**
- * Dump an mbuf structure to the console.
+ * Dump an mbuf structure to a file.
*
* Dump all fields for the given packet mbuf and all its associated
* segments (in the case of a chained buffer).
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 059ad9e..4744482 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -946,7 +946,7 @@ uint32_t rte_mempool_mem_iter(struct rte_mempool *mp,
rte_mempool_mem_cb_t *mem_cb, void *mem_cb_arg);
/**
- * Dump the status of the mempool to the console.
+ * Dump the status of the mempool to a file.
*
* @param f
* A pointer to a file for output
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index 0e22e69..d461f17 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -341,7 +341,7 @@ void rte_ring_free(struct rte_ring *r);
int rte_ring_set_water_mark(struct rte_ring *r, unsigned count);
/**
- * Dump the status of the ring to the console.
+ * Dump the status of the ring to a file.
*
* @param f
* A pointer to a file for output
--
1.9.1
[dpdk-dev] [PATCH] doc/versioning: add missing return value type in MAP_STATIC_SYMBOL example
The example only had as return type struct, it is actually struct rte_acl_ctx *
Signed-off-by: Mauricio Vasquez B
---
doc/guides/contributing/versioning.rst | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/doc/guides/contributing/versioning.rst
b/doc/guides/contributing/versioning.rst
index 92b4d7c..3799b76 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -331,11 +331,12 @@ defined, we add this
.. code-block:: c
- struct rte_acl_create_v21(const struct rte_acl_param *param, int debug)
+ struct rte_acl_ctx *
+ rte_acl_create_v21(const struct rte_acl_param *param, int debug)
{
...
}
- MAP_STATIC_SYMBOL(struct rte_acl_create(const struct rte_acl_param *param,
int debug), rte_acl_create_v21);
+ MAP_STATIC_SYMBOL(struct rte_acl_ctx * rte_acl_create(const struct
rte_acl_param *param, int debug), rte_acl_create_v21);
That tells the compiler that, when building a static library, any calls to the
symbol ``rte_acl_create`` should be linked to ``rte_acl_create_v21``
--
1.9.1
[dpdk-dev] Using qemu-system-x86_64 of KVM sourceforge project versus qemu-system-x86_64 of http://www.qemu.org/
On 08/04/2016 10:27 AM, Kevin Wilson wrote: > Hi Mauricio, > Thanks! > >> be sure that kvm is enabled by >> setting "accel=kvm" in the qemu command line. > Isn't "--enable-kvm" intended for that ? Sorry, I meant "-machine accel=kvm". I don't know what is the exact difference but enable-kvm should also work. > > Kevin >
[dpdk-dev] Using qemu-system-x86_64 of KVM sourceforge project versus qemu-system-x86_64 of http://www.qemu.org/
Hi Kevin, On 08/04/2016 08:55 AM, Kevin Wilson wrote: > Hi, > I am trying to use DPDK SRIOV passthrough with DPDK on Intel NICs. > I am following the instructions in "Network Interface Controller Drivers", in > http://fast.dpdk.org/doc/pdf-guides/nics-16.07.pdf > > I saw in "11.2 Setting Up a KVM Virtual Machine Monitor" in this pdf > that it says to > download qemu-kvm-0.14.0 from > http://sourceforge.net/projects/kvm/files/qemu-kvm/ > ,build it and run /usr/local/kvm/bin/qemu-system-x86_64 > > My question is: > there is also qemu-system-x86_64 executable in qemu Fedora rpms. > It is built from the qemu project which is hosted on http://www.qemu.org. > I made a brief comparison between the trees of both these projects > (qemu and KVM qemu-kvm) and > they seem different. > > Should SRIOV passthrough, as described in the aforementioned DPDK > nics-16.07.pdf, work also with this qemu-system-x86_64 from the qemu > project? > or is using the qemu-system-x86_64 of the qemu project is not good > enough, and using > KVM qemu-system-x86_64 from > http://sourceforge.net/projects/kvm/files/qemu-kvm/ is a must ? I have used qemu-system-x86_64, (directly downloaded and compiled from http://www.qemu.org) without any issue, be sure that kvm is enabled by setting "accel=kvm" in the qemu command line. > Regards, > Kevin > Regards, Mauricio V,
[dpdk-dev] doc: announce ivshmem support removal
Hello All, Here in Politecnico di Torino we use the ivshmem technology from a research point of view. Our research efforts focus in optimizing the inter-Virtual Network Function communication, currently we have implemented two versions of our prototype, they are described in [1] and [2]. Unfortunately, we do not have the human resources to implement the improvements that are necessary for ivshmem in DPDK, however we could provide some feedback and testing for possible patches. Best Regards, Mauricio Vasquez. [1] https://www.researchgate.net/publication/305699120_Transparent_Optimization_of_Inter-Virtual_Network_Function_Communication_in_Open_vSwitch [2] https://www.researchgate.net/publication/305699122_A_Transparent_Highway_for_inter-Virtual_Network_Function_Communication_with_Open_vSwitch On 07/28/2016 11:20 AM, Christian Ehrhardt wrote: > Hi Thomas, > just my two cents as Ubuntu DPDK maintainer (and part of the Debian Team > that does the same). > (It seems I can reuse that line for all posts about the deprecation notices > :-) ) > > While IVSHMEM was enabled (as it was the default) I never heard of any > users of what we provided so far. > But that is expected considering that not all qemu bits are landed either. > Since it will follow the process of "deprecation notice -> grace period -> > ABI bump" on removal, I think packaging and consuming applications should > be fine. > > I'd agree to Hiroshi that, if really needed a clean re-implementation more > properly separated from EAL likely is the best way to go. > > I think it is a good change to drop rather complex code in favor of > stabilizing the main paths: > Acked-by: Christian Ehrhardt > > > Christian Ehrhardt > Software Engineer, Ubuntu Server > Canonical Ltd > > On Wed, Jul 27, 2016 at 9:08 PM, Jan Viktorin > wrote: > >> On Wed, 20 Jul 2016 18:35:46 +0200 >> Thomas Monjalon wrote: >> >>> There was a prior call with an explanation of what needs to be done: >>>http://dpdk.org/ml/archives/dev/2016-June/040844.html >>> - Qemu patch upstreamed >>> - IVSHMEM PCI device managed by a PCI driver >>> - No DPDK objects (ring/mempool) allocated by EAL >>> >>> As nobody seems interested, it is time to remove this code which >>> makes EAL improvements harder. >>> >>> Signed-off-by: Thomas Monjalon >>> Acked-by: David Marchand >>> Acked-by: Maxime Coquelin >> Acked-by: Jan Viktorin >
[dpdk-dev] [PATCH] doc/tespmd: fix flow director examples
A previous patch modified the CLIs witout updating the examples.
Fixes: 53b2bb9b7ea7 ("app/testpmd: new flow director commands")
Signed-off-by: Mauricio Vasquez B
---
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index aed5e47..a676c6c 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1782,13 +1782,13 @@ Different NICs may have different capabilities, command
show port fdir (port_id)
For example, to add an ipv4-udp flow type filter::
- testpmd> flow_director_filter 0 add flow ipv4-udp src 2.2.2.3 32 \
+ testpmd> flow_director_filter 0 mode IP add flow ipv4-udp src 2.2.2.3 32 \
dst 2.2.2.5 33 tos 2 ttl 40 vlan 0x1 flexbytes (0x88,0x48) \
fwd pf queue 1 fd_id 1
For example, add an ipv4-other flow type filter::
- testpmd> flow_director_filter 0 add flow ipv4-other src 2.2.2.3 \
+ testpmd> flow_director_filter 0 mode IP add flow ipv4-other src 2.2.2.3 \
dst 2.2.2.5 tos 2 proto 20 ttl 40 vlan 0x1 \
flexbytes (0x88,0x48) fwd pf queue 1 fd_id 1
@@ -1821,7 +1821,7 @@ Set flow director's input masks::
Example, to set flow director mask on port 0::
- testpmd> flow_director_mask 0 vlan 0xefff \
+ testpmd> flow_director_mask 0 mode IP vlan 0xefff \
src_mask 255.255.255.255 \
::::::: 0x \
dst_mask 255.255.255.255 \
--
1.9.1
[dpdk-dev] [PATCH v3] librte_ether: use RTE_ETH_VALID_PORTID_OR_ERR_RET to check port_id
The RTE_ETH_VALID_PORTID_OR_ERR_RET macro is used in some places
to check if a port id is valid or not. This commit makes use of it in
some new parts of the code.
Signed-off-by: Mauricio Vasquez B
---
v3:
- use it also in rte_eth_add_rx_callback and rte_eth_add_tx_callback
v2:
- add missed case
- change also cases in examples/ethtool/lib/rte_ethtool.c
examples/ethtool/lib/rte_ethtool.c | 15 ++-
lib/librte_ether/rte_ethdev.c | 51 +-
2 files changed, 24 insertions(+), 42 deletions(-)
diff --git a/examples/ethtool/lib/rte_ethtool.c
b/examples/ethtool/lib/rte_ethtool.c
index 42e05f1..9b18e46 100644
--- a/examples/ethtool/lib/rte_ethtool.c
+++ b/examples/ethtool/lib/rte_ethtool.c
@@ -51,8 +51,7 @@ rte_ethtool_get_drvinfo(uint8_t port_id, struct
ethtool_drvinfo *drvinfo)
if (drvinfo == NULL)
return -EINVAL;
- if (!rte_eth_dev_is_valid_port(port_id))
- return -ENODEV;
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
memset(_info, 0, sizeof(dev_info));
rte_eth_dev_info_get(port_id, _info);
@@ -120,8 +119,8 @@ rte_ethtool_get_link(uint8_t port_id)
{
struct rte_eth_link link;
- if (!rte_eth_dev_is_valid_port(port_id))
- return -ENODEV;
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
rte_eth_link_get(port_id, );
return link.link_status;
}
@@ -267,8 +266,8 @@ rte_ethtool_net_open(uint8_t port_id)
int
rte_ethtool_net_stop(uint8_t port_id)
{
- if (!rte_eth_dev_is_valid_port(port_id))
- return -ENODEV;
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
rte_eth_dev_stop(port_id);
return 0;
@@ -277,8 +276,8 @@ rte_ethtool_net_stop(uint8_t port_id)
int
rte_ethtool_net_get_mac_addr(uint8_t port_id, struct ether_addr *addr)
{
- if (!rte_eth_dev_is_valid_port(port_id))
- return -ENODEV;
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
if (addr == NULL)
return -EINVAL;
rte_eth_macaddr_get(port_id, addr);
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index a31018e..80adbd3 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -369,8 +369,8 @@ rte_eth_dev_is_valid_port(uint8_t port_id)
int
rte_eth_dev_socket_id(uint8_t port_id)
{
- if (!rte_eth_dev_is_valid_port(port_id))
- return -1;
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -1);
+
return rte_eth_devices[port_id].data->numa_node;
}
@@ -383,8 +383,8 @@ rte_eth_dev_count(void)
static enum rte_eth_dev_type
rte_eth_dev_get_device_type(uint8_t port_id)
{
- if (!rte_eth_dev_is_valid_port(port_id))
- return RTE_ETH_DEV_UNKNOWN;
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, RTE_ETH_DEV_UNKNOWN);
+
return rte_eth_devices[port_id].dev_type;
}
@@ -479,10 +479,7 @@ rte_eth_dev_is_detachable(uint8_t port_id)
{
uint32_t dev_flags;
- if (!rte_eth_dev_is_valid_port(port_id)) {
- RTE_PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
- return -EINVAL;
- }
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
switch (rte_eth_devices[port_id].data->kdrv) {
case RTE_KDRV_IGB_UIO:
@@ -1994,10 +1991,7 @@ rte_eth_dev_rss_reta_query(uint8_t port_id,
struct rte_eth_dev *dev;
int ret;
- if (port_id >= nb_ports) {
- RTE_PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
- return -ENODEV;
- }
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
/* Check mask bits */
ret = rte_eth_check_reta_mask(reta_conf, reta_size);
@@ -2641,10 +2635,7 @@ rte_eth_dev_rx_intr_ctl(uint8_t port_id, int epfd, int
op, void *data)
uint16_t qid;
int rc;
- if (!rte_eth_dev_is_valid_port(port_id)) {
- RTE_PMD_DEBUG_TRACE("Invalid port_id=%u\n", port_id);
- return -ENODEV;
- }
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
dev = _eth_devices[port_id];
intr_handle = >pci_dev->intr_handle;
@@ -2699,10 +2690,7 @@ rte_eth_dev_rx_intr_ctl_q(uint8_t port_id, uint16_t
queue_id,
struct rte_intr_handle *intr_handle;
int rc;
- if (!rte_eth_dev_is_valid_port(port_id)) {
- RTE_PMD_DEBUG_TRACE("Invalid port_id=%u\n", port_id);
- return -ENODEV;
- }
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
dev = _eth_devices[port_id];
if (queue_id >= dev->data->nb_rx_queues) {
@@ -2734,10 +2722,7 @@ rte_eth_dev_rx_intr_enable(uint8_t port_id,
{
struct rte_eth_dev *dev;
- if (!rte_eth_dev_is_valid_port(port_id)) {
- RTE_PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
- return -
[dpdk-dev] [PATCH v2] librte_ether: use RTE_ETH_VALID_PORTID_OR_ERR_RET to check port_id
The RTE_ETH_VALID_PORTID_OR_ERR_RET macro is used in some places
to check if a port id is valid or not. This commit makes use of it in
some new parts of the code.
Signed-off-by: Mauricio Vasquez B
---
v2:
- add missed case
- change also cases in examples/ethtool/lib/rte_ethtool.c
examples/ethtool/lib/rte_ethtool.c | 15 +++--
lib/librte_ether/rte_ethdev.c | 43 ++
2 files changed, 18 insertions(+), 40 deletions(-)
diff --git a/examples/ethtool/lib/rte_ethtool.c
b/examples/ethtool/lib/rte_ethtool.c
index 42e05f1..9b18e46 100644
--- a/examples/ethtool/lib/rte_ethtool.c
+++ b/examples/ethtool/lib/rte_ethtool.c
@@ -51,8 +51,7 @@ rte_ethtool_get_drvinfo(uint8_t port_id, struct
ethtool_drvinfo *drvinfo)
if (drvinfo == NULL)
return -EINVAL;
- if (!rte_eth_dev_is_valid_port(port_id))
- return -ENODEV;
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
memset(_info, 0, sizeof(dev_info));
rte_eth_dev_info_get(port_id, _info);
@@ -120,8 +119,8 @@ rte_ethtool_get_link(uint8_t port_id)
{
struct rte_eth_link link;
- if (!rte_eth_dev_is_valid_port(port_id))
- return -ENODEV;
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
rte_eth_link_get(port_id, );
return link.link_status;
}
@@ -267,8 +266,8 @@ rte_ethtool_net_open(uint8_t port_id)
int
rte_ethtool_net_stop(uint8_t port_id)
{
- if (!rte_eth_dev_is_valid_port(port_id))
- return -ENODEV;
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
rte_eth_dev_stop(port_id);
return 0;
@@ -277,8 +276,8 @@ rte_ethtool_net_stop(uint8_t port_id)
int
rte_ethtool_net_get_mac_addr(uint8_t port_id, struct ether_addr *addr)
{
- if (!rte_eth_dev_is_valid_port(port_id))
- return -ENODEV;
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
if (addr == NULL)
return -EINVAL;
rte_eth_macaddr_get(port_id, addr);
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index a31018e..4c06fb4 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -369,8 +369,8 @@ rte_eth_dev_is_valid_port(uint8_t port_id)
int
rte_eth_dev_socket_id(uint8_t port_id)
{
- if (!rte_eth_dev_is_valid_port(port_id))
- return -1;
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -1);
+
return rte_eth_devices[port_id].data->numa_node;
}
@@ -383,8 +383,8 @@ rte_eth_dev_count(void)
static enum rte_eth_dev_type
rte_eth_dev_get_device_type(uint8_t port_id)
{
- if (!rte_eth_dev_is_valid_port(port_id))
- return RTE_ETH_DEV_UNKNOWN;
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, RTE_ETH_DEV_UNKNOWN);
+
return rte_eth_devices[port_id].dev_type;
}
@@ -479,10 +479,7 @@ rte_eth_dev_is_detachable(uint8_t port_id)
{
uint32_t dev_flags;
- if (!rte_eth_dev_is_valid_port(port_id)) {
- RTE_PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
- return -EINVAL;
- }
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
switch (rte_eth_devices[port_id].data->kdrv) {
case RTE_KDRV_IGB_UIO:
@@ -1994,10 +1991,7 @@ rte_eth_dev_rss_reta_query(uint8_t port_id,
struct rte_eth_dev *dev;
int ret;
- if (port_id >= nb_ports) {
- RTE_PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
- return -ENODEV;
- }
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
/* Check mask bits */
ret = rte_eth_check_reta_mask(reta_conf, reta_size);
@@ -2641,10 +2635,7 @@ rte_eth_dev_rx_intr_ctl(uint8_t port_id, int epfd, int
op, void *data)
uint16_t qid;
int rc;
- if (!rte_eth_dev_is_valid_port(port_id)) {
- RTE_PMD_DEBUG_TRACE("Invalid port_id=%u\n", port_id);
- return -ENODEV;
- }
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
dev = _eth_devices[port_id];
intr_handle = >pci_dev->intr_handle;
@@ -2699,10 +2690,7 @@ rte_eth_dev_rx_intr_ctl_q(uint8_t port_id, uint16_t
queue_id,
struct rte_intr_handle *intr_handle;
int rc;
- if (!rte_eth_dev_is_valid_port(port_id)) {
- RTE_PMD_DEBUG_TRACE("Invalid port_id=%u\n", port_id);
- return -ENODEV;
- }
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
dev = _eth_devices[port_id];
if (queue_id >= dev->data->nb_rx_queues) {
@@ -2734,10 +2722,7 @@ rte_eth_dev_rx_intr_enable(uint8_t port_id,
{
struct rte_eth_dev *dev;
- if (!rte_eth_dev_is_valid_port(port_id)) {
- RTE_PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
- return -ENODEV;
- }
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(por
[dpdk-dev] [PATCH v2] examples: remove useless checking
The rte_eth_dev_count() function will never return a value greater than RTE_MAX_ETHPORTS, so that checking is useless. Signed-off-by: Mauricio Vasquez B --- v2: Add missed case in examples/kni/main.c app/proc_info/main.c | 4 app/test/test_pmd_perf.c | 3 --- doc/guides/sample_app_ug/l2_forward_job_stats.rst| 3 --- doc/guides/sample_app_ug/l2_forward_real_virtual.rst | 3 --- doc/guides/sample_app_ug/link_status_intr.rst| 3 --- examples/dpdk_qat/main.c | 2 -- examples/ip_fragmentation/main.c | 4 +--- examples/ip_reassembly/main.c| 4 +--- examples/ipsec-secgw/ipsec-secgw.c | 4 examples/kni/main.c | 2 -- examples/l2fwd-crypto/main.c | 3 --- examples/l2fwd-ivshmem/host/host.c | 3 --- examples/l2fwd-jobstats/main.c | 3 --- examples/l2fwd-keepalive/main.c | 3 --- examples/l2fwd/main.c| 3 --- examples/l3fwd-acl/main.c| 2 -- examples/l3fwd-power/main.c | 3 --- examples/l3fwd-vf/main.c | 2 -- examples/l3fwd/main.c| 2 -- examples/link_status_interrupt/main.c| 3 --- examples/multi_process/l2fwd_fork/main.c | 3 --- examples/performance-thread/l3fwd-thread/main.c | 2 -- examples/tep_termination/main.c | 2 -- examples/vhost/main.c| 2 -- examples/vhost_xen/main.c| 2 -- examples/vmdq/main.c | 2 -- examples/vmdq_dcb/main.c | 2 -- 27 files changed, 2 insertions(+), 72 deletions(-) diff --git a/app/proc_info/main.c b/app/proc_info/main.c index 341176d..5f83092 100644 --- a/app/proc_info/main.c +++ b/app/proc_info/main.c @@ -327,10 +327,6 @@ main(int argc, char **argv) if (nb_ports == 0) rte_exit(EXIT_FAILURE, "No Ethernet ports - bye\n"); - - if (nb_ports > RTE_MAX_ETHPORTS) - nb_ports = RTE_MAX_ETHPORTS; - /* If no port mask was specified*/ if (enabled_port_mask == 0) enabled_port_mask = 0x; diff --git a/app/test/test_pmd_perf.c b/app/test/test_pmd_perf.c index 59803f7..3d56cd2 100644 --- a/app/test/test_pmd_perf.c +++ b/app/test/test_pmd_perf.c @@ -709,9 +709,6 @@ test_pmd_perf(void) return -1; } - if (nb_ports > RTE_MAX_ETHPORTS) - nb_ports = RTE_MAX_ETHPORTS; - nb_lcores = rte_lcore_count(); memset(lcore_conf, 0, sizeof(lcore_conf)); diff --git a/doc/guides/sample_app_ug/l2_forward_job_stats.rst b/doc/guides/sample_app_ug/l2_forward_job_stats.rst index 03d9977..2444e36 100644 --- a/doc/guides/sample_app_ug/l2_forward_job_stats.rst +++ b/doc/guides/sample_app_ug/l2_forward_job_stats.rst @@ -238,9 +238,6 @@ in the *DPDK Programmer's Guide* and the *DPDK API Reference*. if (nb_ports == 0) rte_exit(EXIT_FAILURE, "No Ethernet ports - bye\n"); -if (nb_ports > RTE_MAX_ETHPORTS) -nb_ports = RTE_MAX_ETHPORTS; - /* reset l2fwd_dst_ports */ for (portid = 0; portid < RTE_MAX_ETHPORTS; portid++) diff --git a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst index e77d67c..b51b2dc 100644 --- a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst +++ b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst @@ -242,9 +242,6 @@ in the *DPDK Programmer's Guide* - Rel 1.4 EAR and the *DPDK API Reference*. if (nb_ports == 0) rte_exit(EXIT_FAILURE, "No Ethernet ports - bye\n"); -if (nb_ports > RTE_MAX_ETHPORTS) -nb_ports = RTE_MAX_ETHPORTS; - /* reset l2fwd_dst_ports */ for (portid = 0; portid < RTE_MAX_ETHPORTS; portid++) diff --git a/doc/guides/sample_app_ug/link_status_intr.rst b/doc/guides/sample_app_ug/link_status_intr.rst index a4dbb54..779df97 100644 --- a/doc/guides/sample_app_ug/link_status_intr.rst +++ b/doc/guides/sample_app_ug/link_status_intr.rst @@ -145,9 +145,6 @@ To fully understand this code, it is recommended to study the chapters that rela if (nb_ports == 0) rte_exit(EXIT_FAILURE, "No Ethernet ports - bye\n"); -if (nb_ports > RTE_MAX_ETHPORTS) -nb_ports = RTE_MAX_ETHPORTS; - /* * Each logical core is assigned a dedicated TX queue on each port. */ diff --git a/examples/dpdk_qat/main.c b/examples/dpdk_qat/main.c index dc68989..3c6112d 100644 --- a/examples/dpdk_qat/main.c +++ b/examples/dpdk_qat/main.c @@ -661,8 +661,6 @@ main(int argc, char **argv) return -1; nb_ports =
[dpdk-dev] [PATCH] examples: remove useless checking
The rte_eth_dev_count() function will never return a value greater than RTE_MAX_ETHPORTS, so that checking is useless. Signed-off-by: Mauricio Vasquez B --- app/proc_info/main.c | 4 app/test/test_pmd_perf.c | 3 --- doc/guides/sample_app_ug/l2_forward_job_stats.rst| 3 --- doc/guides/sample_app_ug/l2_forward_real_virtual.rst | 3 --- doc/guides/sample_app_ug/link_status_intr.rst| 3 --- examples/dpdk_qat/main.c | 2 -- examples/ip_fragmentation/main.c | 4 +--- examples/ip_reassembly/main.c| 4 +--- examples/ipsec-secgw/ipsec-secgw.c | 4 examples/l2fwd-crypto/main.c | 3 --- examples/l2fwd-ivshmem/host/host.c | 3 --- examples/l2fwd-jobstats/main.c | 3 --- examples/l2fwd-keepalive/main.c | 3 --- examples/l2fwd/main.c| 3 --- examples/l3fwd-acl/main.c| 2 -- examples/l3fwd-power/main.c | 3 --- examples/l3fwd-vf/main.c | 2 -- examples/l3fwd/main.c| 2 -- examples/link_status_interrupt/main.c| 3 --- examples/multi_process/l2fwd_fork/main.c | 3 --- examples/performance-thread/l3fwd-thread/main.c | 2 -- examples/tep_termination/main.c | 2 -- examples/vhost/main.c| 2 -- examples/vhost_xen/main.c| 2 -- examples/vmdq/main.c | 2 -- examples/vmdq_dcb/main.c | 2 -- 26 files changed, 2 insertions(+), 70 deletions(-) diff --git a/app/proc_info/main.c b/app/proc_info/main.c index 341176d..5f83092 100644 --- a/app/proc_info/main.c +++ b/app/proc_info/main.c @@ -327,10 +327,6 @@ main(int argc, char **argv) if (nb_ports == 0) rte_exit(EXIT_FAILURE, "No Ethernet ports - bye\n"); - - if (nb_ports > RTE_MAX_ETHPORTS) - nb_ports = RTE_MAX_ETHPORTS; - /* If no port mask was specified*/ if (enabled_port_mask == 0) enabled_port_mask = 0x; diff --git a/app/test/test_pmd_perf.c b/app/test/test_pmd_perf.c index 59803f7..3d56cd2 100644 --- a/app/test/test_pmd_perf.c +++ b/app/test/test_pmd_perf.c @@ -709,9 +709,6 @@ test_pmd_perf(void) return -1; } - if (nb_ports > RTE_MAX_ETHPORTS) - nb_ports = RTE_MAX_ETHPORTS; - nb_lcores = rte_lcore_count(); memset(lcore_conf, 0, sizeof(lcore_conf)); diff --git a/doc/guides/sample_app_ug/l2_forward_job_stats.rst b/doc/guides/sample_app_ug/l2_forward_job_stats.rst index 03d9977..2444e36 100644 --- a/doc/guides/sample_app_ug/l2_forward_job_stats.rst +++ b/doc/guides/sample_app_ug/l2_forward_job_stats.rst @@ -238,9 +238,6 @@ in the *DPDK Programmer's Guide* and the *DPDK API Reference*. if (nb_ports == 0) rte_exit(EXIT_FAILURE, "No Ethernet ports - bye\n"); -if (nb_ports > RTE_MAX_ETHPORTS) -nb_ports = RTE_MAX_ETHPORTS; - /* reset l2fwd_dst_ports */ for (portid = 0; portid < RTE_MAX_ETHPORTS; portid++) diff --git a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst index e77d67c..b51b2dc 100644 --- a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst +++ b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst @@ -242,9 +242,6 @@ in the *DPDK Programmer's Guide* - Rel 1.4 EAR and the *DPDK API Reference*. if (nb_ports == 0) rte_exit(EXIT_FAILURE, "No Ethernet ports - bye\n"); -if (nb_ports > RTE_MAX_ETHPORTS) -nb_ports = RTE_MAX_ETHPORTS; - /* reset l2fwd_dst_ports */ for (portid = 0; portid < RTE_MAX_ETHPORTS; portid++) diff --git a/doc/guides/sample_app_ug/link_status_intr.rst b/doc/guides/sample_app_ug/link_status_intr.rst index a4dbb54..779df97 100644 --- a/doc/guides/sample_app_ug/link_status_intr.rst +++ b/doc/guides/sample_app_ug/link_status_intr.rst @@ -145,9 +145,6 @@ To fully understand this code, it is recommended to study the chapters that rela if (nb_ports == 0) rte_exit(EXIT_FAILURE, "No Ethernet ports - bye\n"); -if (nb_ports > RTE_MAX_ETHPORTS) -nb_ports = RTE_MAX_ETHPORTS; - /* * Each logical core is assigned a dedicated TX queue on each port. */ diff --git a/examples/dpdk_qat/main.c b/examples/dpdk_qat/main.c index dc68989..3c6112d 100644 --- a/examples/dpdk_qat/main.c +++ b/examples/dpdk_qat/main.c @@ -661,8 +661,6 @@ main(int argc, char **argv) return -1; nb_ports = rte_eth_dev_count(); - if (nb_ports > RTE_MAX_ETHPORTS) - nb_ports = RTE_MAX_ETHPORTS;
[dpdk-dev] [PATCH v2] mem: fix freeing of memzone used by ivshmem
although previous implementation returned an error when trying to release a
memzone assigned to an ivshmem device, it stills freed it.
Fixes: cd10c42eb5bc ("mem: fix ivshmem freeing")
Signed-off-by: Mauricio Vasquez B
---
v2:
solved compilation problem when ivshmem is disabled
lib/librte_eal/common/eal_common_memzone.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_memzone.c
b/lib/librte_eal/common/eal_common_memzone.c
index 711c845..a8f804c 100644
--- a/lib/librte_eal/common/eal_common_memzone.c
+++ b/lib/librte_eal/common/eal_common_memzone.c
@@ -321,15 +321,19 @@ rte_memzone_free(const struct rte_memzone *mz)
idx = ((uintptr_t)mz - (uintptr_t)mcfg->memzone);
idx = idx / sizeof(struct rte_memzone);
- addr = mcfg->memzone[idx].addr;
#ifdef RTE_LIBRTE_IVSHMEM
/*
* If ioremap_addr is set, it's an IVSHMEM memzone and we cannot
* free it.
*/
- if (mcfg->memzone[idx].ioremap_addr != 0)
- ret = -EINVAL;
+ if (mcfg->memzone[idx].ioremap_addr != 0) {
+ rte_rwlock_write_unlock(>mlock);
+ return -EINVAL;
+ }
#endif
+
+ addr = mcfg->memzone[idx].addr;
+
if (addr == NULL)
ret = -EINVAL;
else if (mcfg->memzone_cnt == 0) {
--
1.9.1
[dpdk-dev] [PATCH] mem: fix freeing of memzone used by ivshmem
although previous implementation returned an error when trying to release a
memzone assigned to an ivshmem device, it stills freed it.
Fixes: cd10c42eb5bc ("mem: fix ivshmem freeing")
Signed-off-by: Mauricio Vasquez B
---
lib/librte_eal/common/eal_common_memzone.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_memzone.c
b/lib/librte_eal/common/eal_common_memzone.c
index 711c845..1fce906 100644
--- a/lib/librte_eal/common/eal_common_memzone.c
+++ b/lib/librte_eal/common/eal_common_memzone.c
@@ -321,15 +321,19 @@ rte_memzone_free(const struct rte_memzone *mz)
idx = ((uintptr_t)mz - (uintptr_t)mcfg->memzone);
idx = idx / sizeof(struct rte_memzone);
- addr = mcfg->memzone[idx].addr;
#ifdef RTE_LIBRTE_IVSHMEM
/*
* If ioremap_addr is set, it's an IVSHMEM memzone and we cannot
* free it.
*/
- if (mcfg->memzone[idx].ioremap_addr != 0)
+ if (mcfg->memzone[idx].ioremap_addr != 0) {
ret = -EINVAL;
+ goto error;
+ }
#endif
+
+ addr = mcfg->memzone[idx].addr;
+
if (addr == NULL)
ret = -EINVAL;
else if (mcfg->memzone_cnt == 0) {
@@ -345,6 +349,10 @@ rte_memzone_free(const struct rte_memzone *mz)
rte_free(addr);
return ret;
+
+error:
+ rte_rwlock_write_unlock(>mlock);
+ return ret;
}
/*
--
1.9.1
[dpdk-dev] [PATCH v2] ivshmem: fix race condition
The memory zone could be freed just after adding it to the metadata
file and just before marking it as not freeable.
This patch changes the locking logic in order to prevent it.
Fixes: cd10c42eb5bc ("mem: fix ivshmem freeing")
Signed-off-by: Mauricio Vasquez B
---
lib/librte_ivshmem/rte_ivshmem.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/lib/librte_ivshmem/rte_ivshmem.c b/lib/librte_ivshmem/rte_ivshmem.c
index 8fc4b57..013c3eb 100644
--- a/lib/librte_ivshmem/rte_ivshmem.c
+++ b/lib/librte_ivshmem/rte_ivshmem.c
@@ -471,10 +471,21 @@ add_memzone_to_metadata(const struct rte_memzone * mz,
struct ivshmem_config * config)
{
struct rte_ivshmem_metadata_entry * entry;
- unsigned i;
+ unsigned i, idx;
+ struct rte_mem_config *mcfg;
+
+ if(mz->len == 0) {
+ RTE_LOG(ERR, EAL, "Trying to add an empty memzone\n");
+ return -1;
+ }
rte_spinlock_lock(>sl);
+ mcfg = rte_eal_get_configuration()->mem_config;
+
+ /* it prevents the memzone being freed while we add it to the metadata
*/
+ rte_rwlock_write_lock(>mlock);
+
/* find free slot in this config */
for (i = 0; i < RTE_DIM(config->metadata->entry); i++) {
entry = >metadata->entry[i];
@@ -504,13 +515,6 @@ add_memzone_to_metadata(const struct rte_memzone * mz,
config->metadata->name);
goto fail;
}
-#ifdef RTE_LIBRTE_IVSHMEM
- struct rte_mem_config *mcfg;
- unsigned int idx;
-
- mcfg = rte_eal_get_configuration()->mem_config;
-
- rte_rwlock_write_lock(>mlock);
idx = ((uintptr_t)mz - (uintptr_t)mcfg->memzone);
idx = idx / sizeof(struct rte_memzone);
@@ -519,10 +523,10 @@ add_memzone_to_metadata(const struct rte_memzone * mz,
mcfg->memzone[idx].ioremap_addr = mz->phys_addr;
rte_rwlock_write_unlock(>mlock);
-#endif
rte_spinlock_unlock(>sl);
return 0;
fail:
+ rte_rwlock_write_unlock(>mlock);
rte_spinlock_unlock(>sl);
return -1;
}
--
1.9.1
[dpdk-dev] [PATCH] ivshmem: fix race condition
The memory zone could be freed just after adding it to the metadata
file and just before marking it as not freeable.
This patch changes the locking logic in order to prevent it.
Fixes: cd10c42eb5bc ("mem: fix ivshmem freeing")
Signed-off-by: Mauricio Vasquez B
---
lib/librte_ivshmem/rte_ivshmem.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/lib/librte_ivshmem/rte_ivshmem.c b/lib/librte_ivshmem/rte_ivshmem.c
index 8fc4b57..ed2c276 100644
--- a/lib/librte_ivshmem/rte_ivshmem.c
+++ b/lib/librte_ivshmem/rte_ivshmem.c
@@ -471,10 +471,16 @@ add_memzone_to_metadata(const struct rte_memzone * mz,
struct ivshmem_config * config)
{
struct rte_ivshmem_metadata_entry * entry;
- unsigned i;
+ unsigned i, idx;
+ struct rte_mem_config *mcfg;
rte_spinlock_lock(>sl);
+ mcfg = rte_eal_get_configuration()->mem_config;
+
+ /* it prevents the memzone being freed while we add it to the metadata
*/
+ rte_rwlock_write_lock(>mlock);
+
/* find free slot in this config */
for (i = 0; i < RTE_DIM(config->metadata->entry); i++) {
entry = >metadata->entry[i];
@@ -504,13 +510,6 @@ add_memzone_to_metadata(const struct rte_memzone * mz,
config->metadata->name);
goto fail;
}
-#ifdef RTE_LIBRTE_IVSHMEM
- struct rte_mem_config *mcfg;
- unsigned int idx;
-
- mcfg = rte_eal_get_configuration()->mem_config;
-
- rte_rwlock_write_lock(>mlock);
idx = ((uintptr_t)mz - (uintptr_t)mcfg->memzone);
idx = idx / sizeof(struct rte_memzone);
@@ -519,10 +518,10 @@ add_memzone_to_metadata(const struct rte_memzone * mz,
mcfg->memzone[idx].ioremap_addr = mz->phys_addr;
rte_rwlock_write_unlock(>mlock);
-#endif
rte_spinlock_unlock(>sl);
return 0;
fail:
+ rte_rwlock_write_unlock(>mlock);
rte_spinlock_unlock(>sl);
return -1;
}
--
1.9.1
[dpdk-dev] [PATCH] pmd_ring: free rings when detaching
When a device is created with "CREATE" as action, new rings are
allocated for it, then it is a good practice to free them when the
rte_ethdev_dettach method is invoked by the application.
Rings are not freeded when "ATTACH" is used or when the device is
created by means of the rte_eth_from_rings function.
Signed-off-by: Mauricio Vasquez B
---
drivers/net/ring/rte_eth_ring.c | 82 -
1 file changed, 56 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
index d92b088..fd23a91 100644
--- a/drivers/net/ring/rte_eth_ring.c
+++ b/drivers/net/ring/rte_eth_ring.c
@@ -51,6 +51,11 @@ static const char *valid_arguments[] = {
NULL
};
+enum dev_action{
+ DEV_CREATE,
+ DEV_ATTACH
+};
+
struct ring_queue {
struct rte_ring *rng;
rte_atomic64_t rx_pkts;
@@ -66,6 +71,7 @@ struct pmd_internals {
struct ring_queue tx_ring_queues[RTE_PMD_RING_MAX_TX_RINGS];
struct ether_addr address;
+ enum dev_action action;
};
@@ -252,12 +258,11 @@ static const struct eth_dev_ops ops = {
.mac_addr_add = eth_mac_addr_add,
};
-int
-rte_eth_from_rings(const char *name, struct rte_ring *const rx_queues[],
- const unsigned nb_rx_queues,
- struct rte_ring *const tx_queues[],
- const unsigned nb_tx_queues,
- const unsigned numa_node)
+static int
+do_eth_dev_ring_create(const char *name,
+ struct rte_ring * const rx_queues[], const unsigned
nb_rx_queues,
+ struct rte_ring *const tx_queues[], const unsigned nb_tx_queues,
+ const unsigned numa_node, enum dev_action action)
{
struct rte_eth_dev_data *data = NULL;
struct pmd_internals *internals = NULL;
@@ -265,20 +270,6 @@ rte_eth_from_rings(const char *name, struct rte_ring
*const rx_queues[],
unsigned i;
- /* do some parameter checking */
- if (rx_queues == NULL && nb_rx_queues > 0) {
- rte_errno = EINVAL;
- goto error;
- }
- if (tx_queues == NULL && nb_tx_queues > 0) {
- rte_errno = EINVAL;
- goto error;
- }
- if (nb_rx_queues > RTE_PMD_RING_MAX_RX_RINGS) {
- rte_errno = EINVAL;
- goto error;
- }
-
RTE_LOG(INFO, PMD, "Creating rings-backed ethdev on numa socket %u\n",
numa_node);
@@ -327,6 +318,8 @@ rte_eth_from_rings(const char *name, struct rte_ring *const
rx_queues[],
/* NOTE: we'll replace the data element, of originally allocated eth_dev
* so the rings are local per-process */
+ internals->action = action;
+
internals->nb_rx_queues = nb_rx_queues;
internals->nb_tx_queues = nb_tx_queues;
for (i = 0; i < nb_rx_queues; i++) {
@@ -374,17 +367,37 @@ error:
}
int
+rte_eth_from_rings(const char *name, struct rte_ring *const rx_queues[],
+ const unsigned nb_rx_queues,
+ struct rte_ring *const tx_queues[],
+ const unsigned nb_tx_queues,
+ const unsigned numa_node)
+{
+ /* do some parameter checking */
+ if (rx_queues == NULL && nb_rx_queues > 0) {
+ rte_errno = EINVAL;
+ return -1;
+ }
+ if (tx_queues == NULL && nb_tx_queues > 0) {
+ rte_errno = EINVAL;
+ return -1;
+ }
+ if (nb_rx_queues > RTE_PMD_RING_MAX_RX_RINGS) {
+ rte_errno = EINVAL;
+ return -1;
+ }
+
+ return do_eth_dev_ring_create(name, rx_queues, nb_rx_queues,
+ tx_queues, nb_tx_queues, numa_node, DEV_ATTACH);
+}
+
+int
rte_eth_from_ring(struct rte_ring *r)
{
return rte_eth_from_rings(r->name, , 1, , 1,
r->memzone ? r->memzone->socket_id : SOCKET_ID_ANY);
}
-enum dev_action{
- DEV_CREATE,
- DEV_ATTACH
-};
-
static int
eth_dev_ring_create(const char *name, const unsigned numa_node,
enum dev_action action)
@@ -408,7 +421,8 @@ eth_dev_ring_create(const char *name, const unsigned
numa_node,
return -1;
}
- if (rte_eth_from_rings(name, rxtx, num_rings, rxtx, num_rings,
numa_node) < 0)
+ if(do_eth_dev_ring_create(name, rxtx, num_rings, rxtx, num_rings,
+ numa_node, action) < 0)
return -1;
return 0;
@@ -570,6 +584,9 @@ static int
rte_pmd_ring_devuninit(const char *name)
{
struct rte_eth_dev *eth_dev = NULL;
+ struct pmd_internals *internals = NULL;
+ struct ring_queue *r = NULL;
+ uint16_t i;
RTE_LOG(INFO, PMD, "Un-Initializing pmd_ring for %s\n", name);
@@ -584,10 +601,23 @@ rte_pmd_ring_devuninit(const char *n
[dpdk-dev] [PATCH 19/19] doc: fix vm power man sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/vm_power_management.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/guides/sample_app_ug/vm_power_management.rst b/doc/guides/sample_app_ug/vm_power_management.rst index da8be12..7f299e0 100644 --- a/doc/guides/sample_app_ug/vm_power_management.rst +++ b/doc/guides/sample_app_ug/vm_power_management.rst @@ -72,7 +72,7 @@ The solution is comprised of two high-level components: the APCI cpufreq sysfs interface used on the host. The l3fwd-power application will use this implementation when deployed on a VM - (see Chapter 11 "L3 Forwarding with Power Management Application"). + (see :doc:`l3_forward_power_man`). .. _figure_vm_power_mgr_highlevel: @@ -314,7 +314,7 @@ Manual control and inspection can also be carried in relation CPU frequency scal Compiling and Running the Guest Applications -For compiling and running l3fwd-power, see Chapter 11 "L3 Forwarding with Power Management Application". +For compiling and running l3fwd-power, see :doc:`l3_forward_power_man`. A guest CLI is also provided for validating the setup. -- 1.9.1
[dpdk-dev] [PATCH 18/19] doc: fix vmdq and dcb fwd sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst b/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst index 9140a22..e9ced9f 100644 --- a/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst +++ b/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst @@ -77,7 +77,7 @@ To have the application display the statistics, send a SIGHUP signal to the runn where, is the process id of the application process. The VMDQ and DCB Forwarding sample application is in many ways simpler than the L2 Forwarding application -(see Chapter 9 , "L2 Forwarding Sample Application (in Real and Virtualized Environments)") +(see :doc:`l2_forward_real_virtual`) as it performs unidirectional L2 forwarding of packets from one port to a second port. No command-line options are taken by this application apart from the standard EAL command-line options. @@ -132,7 +132,7 @@ Initialization The EAL, driver and PCI configuration is performed largely as in the L2 Forwarding sample application, as is the creation of the mbuf pool. -See Chapter 9, "L2 Forwarding Sample Application (in Real and Virtualized Environments)". +See :doc:`l2_forward_real_virtual`. Where this example application differs is in the configuration of the NIC port for RX. The VMDQ and DCB hardware feature is configured at port initialization time by setting the appropriate values in the @@ -228,7 +228,7 @@ so the pools parameter in the rte_eth_vmdq_dcb_conf structure is specified as a Once the network port has been initialized using the correct VMDQ and DCB values, the initialization of the port's RX and TX hardware rings is performed similarly to that in the L2 Forwarding sample application. -See Chapter 9, "L2 Forwarding Sample Application (in Real and Virtualized Environments)" for more information. +See :doc:`l2_forward_real_virtual` for more information. Statistics Display ~~ -- 1.9.1
[dpdk-dev] [PATCH 17/19] doc: fix tep termination sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/tep_termination.rst | 8 doc/guides/sample_app_ug/vhost.rst | 7 +++ 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/doc/guides/sample_app_ug/tep_termination.rst b/doc/guides/sample_app_ug/tep_termination.rst index 71a4acd..2d86a03 100644 --- a/doc/guides/sample_app_ug/tep_termination.rst +++ b/doc/guides/sample_app_ug/tep_termination.rst @@ -121,7 +121,7 @@ The example in this section have been validated with the following distributions Prerequisites - -Refer to the guide in section 27.4 in the vhost sample. +Refer to :ref:`vhost_app_prerequisites`. Compiling the Sample Code - @@ -225,7 +225,7 @@ Parameters **The same parameters with the vhost sample.** -Refer to the guide in section 27.6.1 in the vhost sample for the meanings of 'Basename', +Refer to :ref:`vhost_app_parameters` for the meanings of 'Basename', 'Stats', 'RX Retry', 'RX Retry Number' and 'RX Retry Delay Time'. **Number of Devices.** @@ -303,12 +303,12 @@ The default value is 1. Running the Virtual Machine (QEMU) -- -Refer to the guide in section 27.7 in the vhost sample. +Refer to :ref:`vhost_app_running`. Running DPDK in the Virtual Machine --- -Refer to the guide in section 27.8 in the vHost sample. +Refer to :ref:`vhost_app_running_dpdk`. Passing Traffic to the Virtual Machine Device - diff --git a/doc/guides/sample_app_ug/vhost.rst b/doc/guides/sample_app_ug/vhost.rst index 751656c..47ce36c 100644 --- a/doc/guides/sample_app_ug/vhost.rst +++ b/doc/guides/sample_app_ug/vhost.rst @@ -144,6 +144,8 @@ The example in this section have been validated with the following distributions * Fedora* 20 +.. _vhost_app_prerequisites: + Prerequisites - @@ -405,6 +407,8 @@ Running the Sample Code The number used with the --socket-mem parameter may need to be more than 1024. The number required depends on the number of mbufs allocated by vhost-switch. +.. _vhost_app_parameters: + Parameters ~~ @@ -530,6 +534,8 @@ It is enabled by default. ./vhost-switch -c f -n 4 --socket-mem 1024 --huge-dir /mnt/huge \ -- --vlan-strip [0, 1] +.. _vhost_app_running: + Running the Virtual Machine (QEMU) -- @@ -760,6 +766,7 @@ Common Issues Linux module but which is necessary for the user space VHOST current implementation (CUSE-based) to communicate with the guest. +.. _vhost_app_running_dpdk: Running DPDK in the Virtual Machine --- -- 1.9.1
[dpdk-dev] [PATCH 15/19] doc: fix link status int sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/link_status_intr.rst | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/guides/sample_app_ug/link_status_intr.rst b/doc/guides/sample_app_ug/link_status_intr.rst index de0dff8..a4dbb54 100644 --- a/doc/guides/sample_app_ug/link_status_intr.rst +++ b/doc/guides/sample_app_ug/link_status_intr.rst @@ -118,16 +118,16 @@ Command Line Arguments ~~ The Link Status Interrupt sample application takes specific parameters, -in addition to Environment Abstraction Layer (EAL) arguments (see Section 13.3). +in addition to Environment Abstraction Layer (EAL) arguments (see Section `Running the Application`_). Command line parsing is done in the same way as it is done in the L2 Forwarding Sample Application. -See Section 9.4.1, "Command Line Arguments" for more information. +See :ref:`l2_fwd_app_cmd_arguments` for more information. Mbuf Pool Initialization Mbuf pool initialization is done in the same way as it is done in the L2 Forwarding Sample Application. -See Section 9.4.2, "Mbuf Pool Initialization" for more information. +See :ref:`l2_fwd_app_mbuf_init` for more information. Driver Initialization ~ @@ -287,7 +287,7 @@ The list of queues that must be polled for a given lcore is stored in a private struct lcore_queue_conf lcore_queue_conf[RTE_MAX_LCORE]; The n_rx_port and rx_port_list[] fields are used in the main packet processing loop -(see Section 13.4.7, "Receive, Process and Transmit Packets" later in this chapter). +(see `Receive, Process and Transmit Packets`_). The global configuration for the RX queues is stored in a static structure: -- 1.9.1
[dpdk-dev] [PATCH 14/19] doc: fix l3fwd virtual sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/l2_forward_real_virtual.rst | 1 + doc/guides/sample_app_ug/l3_forward.rst | 2 ++ doc/guides/sample_app_ug/l3_forward_virtual.rst | 7 +++ 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst index 2a576f3..e77d67c 100644 --- a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst +++ b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst @@ -75,6 +75,7 @@ The L2 Forwarding application can also be used as a starting point for developin Performance Benchmark Setup (Virtualized Environment) +.. _l2_fwd_vf_setup: Virtual Function Setup Instructions ~~~ diff --git a/doc/guides/sample_app_ug/l3_forward.rst b/doc/guides/sample_app_ug/l3_forward.rst index 1aac7dd..1522650 100644 --- a/doc/guides/sample_app_ug/l3_forward.rst +++ b/doc/guides/sample_app_ug/l3_forward.rst @@ -156,6 +156,8 @@ In this command: Refer to the *DPDK Getting Started Guide* for general information on running applications and the Environment Abstraction Layer (EAL) options. +.. _l3_fwd_explanation: + Explanation --- diff --git a/doc/guides/sample_app_ug/l3_forward_virtual.rst b/doc/guides/sample_app_ug/l3_forward_virtual.rst index f40643a..fa04722 100644 --- a/doc/guides/sample_app_ug/l3_forward_virtual.rst +++ b/doc/guides/sample_app_ug/l3_forward_virtual.rst @@ -39,8 +39,7 @@ Overview The application demonstrates the use of the hash and LPM libraries in the DPDK to implement packet forwarding. -The initialization and run-time paths are very similar to those of the L3 forwarding application -(see Chapter 10 "L3 Forwarding Sample Application" for more information). +The initialization and run-time paths are very similar to those of the :doc:`l3_forward`. The forwarding decision is taken based on information read from the input packet. The lookup method is either hash-based or LPM-based and is selected at compile time. @@ -60,7 +59,7 @@ The set of LPM rules used by the application is statically configured and loaded .. note:: -Please refer to Section 9.1.1 "Virtual Function Setup Instructions" for virtualized test case setup. +Please refer to :ref:`l2_fwd_vf_setup` for virtualized test case setup. Compiling the Application - @@ -155,4 +154,4 @@ Explanation --- The operation of this application is similar to that of the basic L3 Forwarding Sample Application. -See Section 10.4 "Explanation" for more information. +See :ref:`l3_fwd_explanation` for more information. -- 1.9.1
[dpdk-dev] [PATCH 13/19] doc: fix l3fwd power man sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/l3_forward_power_man.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/doc/guides/sample_app_ug/l3_forward_power_man.rst b/doc/guides/sample_app_ug/l3_forward_power_man.rst index ac688f8..ea9c404 100644 --- a/doc/guides/sample_app_ug/l3_forward_power_man.rst +++ b/doc/guides/sample_app_ug/l3_forward_power_man.rst @@ -43,8 +43,7 @@ Overview The application demonstrates the use of the Power libraries in the DPDK to implement packet forwarding. -The initialization and run-time paths are very similar to those of the L3 forwarding sample application -(see Chapter 10 "L3 Forwarding Sample Application" for more information). +The initialization and run-time paths are very similar to those of the :doc:`l3_forward`. The main difference from the L3 Forwarding sample application is that this application introduces power-aware optimization algorithms by leveraging the Power library to control P-state and C-state of processor based on packet load. @@ -152,7 +151,7 @@ where, * --no-numa: optional, disables numa awareness -See Chapter 10 "L3 Forwarding Sample Application" for details. +See :doc:`l3_forward` for details. The L3fwd-power example reuses the L3fwd command line options. Explanation -- 1.9.1
[dpdk-dev] [PATCH 12/19] doc: fix l3fwd access control sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/l3_forward_access_ctrl.rst | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst index dbf47c7..4049e01 100644 --- a/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst +++ b/doc/guides/sample_app_ug/l3_forward_access_ctrl.rst @@ -51,8 +51,7 @@ When packets are received from a port, the application extracts the necessary information from the TCP/IP header of the received packet and performs a lookup in the rule database to figure out whether the packets should be dropped (in the ACL range) or forwarded to desired ports. -The initialization and run-time paths are similar to those of the L3 forwarding application -(see Chapter 10, "L3 Forwarding Sample Application" for more information). +The initialization and run-time paths are similar to those of the :doc:`l3_forward`. However, there are significant differences in the two applications. For example, the original L3 forwarding application uses either LPM or an exact match algorithm to perform forwarding port lookup, @@ -360,8 +359,7 @@ Explanation --- The following sections provide some explanation of the sample application code. -The aspects of port, device and CPU configuration are similar to those of the L3 forwarding application -(see Chapter 10, "L3 Forwarding Sample Application" for more information). +The aspects of port, device and CPU configuration are similar to those of the :doc:`l3_forward`. The following sections describe aspects that are specific to L3 forwarding with access control. Parse Rules from File -- 1.9.1
[dpdk-dev] [PATCH 11/19] doc: fix l3 fwd sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/l3_forward.rst | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/doc/guides/sample_app_ug/l3_forward.rst b/doc/guides/sample_app_ug/l3_forward.rst index 4ce734b..1aac7dd 100644 --- a/doc/guides/sample_app_ug/l3_forward.rst +++ b/doc/guides/sample_app_ug/l3_forward.rst @@ -38,8 +38,7 @@ Overview The application demonstrates the use of the hash and LPM libraries in the DPDK to implement packet forwarding. -The initialization and run-time paths are very similar to those of the L2 forwarding application -(see Chapter 9 "L2 Forwarding Sample Application (in Real and Virtualized Environments)" for more information). +The initialization and run-time paths are very similar to those of the :doc:`l2_forward_real_virtual`. The main difference from the L2 Forwarding sample application is that the forwarding decision is made based on information read from the input packet. @@ -161,8 +160,7 @@ Explanation --- The following sections provide some explanation of the sample application code. As mentioned in the overview section, -the initialization and run-time paths are very similar to those of the L2 forwarding application -(see Chapter 9 "L2 Forwarding Sample Application (in Real and Virtualized Environments)" for more information). +the initialization and run-time paths are very similar to those of the :doc:`l2_forward_real_virtual`. The following sections describe aspects that are specific to the L3 Forwarding sample application. Hash Initialization -- 1.9.1
[dpdk-dev] [PATCH 10/19] doc: fix l2 fwd sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/l2_forward_real_virtual.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst index 12f0d27..2a576f3 100644 --- a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst +++ b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst @@ -155,7 +155,7 @@ Command Line Arguments ~~ The L2 Forwarding sample application takes specific parameters, -in addition to Environment Abstraction Layer (EAL) arguments (see Section 9.3). +in addition to Environment Abstraction Layer (EAL) arguments. The preferred way to parse parameters is to use the getopt() function, since it is part of a well-defined and portable library. @@ -345,7 +345,7 @@ The list of queues that must be polled for a given lcore is stored in a private struct lcore_queue_conf lcore_queue_conf[RTE_MAX_LCORE]; The values n_rx_port and rx_port_list[] are used in the main packet processing loop -(see Section 9.4.6 "Receive, Process and Transmit Packets" later in this chapter). +(see :ref:`l2_fwd_app_rx_tx_packets`). The global configuration for the RX queues is stored in a static structure: -- 1.9.1
[dpdk-dev] [PATCH 09/19] doc: fix kni sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/kernel_nic_interface.rst | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/doc/guides/sample_app_ug/kernel_nic_interface.rst b/doc/guides/sample_app_ug/kernel_nic_interface.rst index 985c664..2ae9b70 100644 --- a/doc/guides/sample_app_ug/kernel_nic_interface.rst +++ b/doc/guides/sample_app_ug/kernel_nic_interface.rst @@ -237,8 +237,7 @@ The following sections provide some explanation of code. Initialization ~~ -Setup of mbuf pool, driver and queues is similar to the setup done in the L2 Forwarding sample application -(see Chapter 9 "L2 Forwarding Sample Application (in Real and Virtualized Environments" for details). +Setup of mbuf pool, driver and queues is similar to the setup done in the :doc:`l2_forward_real_virtual`.. In addition, one or more kernel NIC interfaces are allocated for each of the configured ports according to the command line parameters. @@ -425,7 +424,7 @@ to see if this lcore is reading from or writing to kernel NIC interfaces. For the case that reads from a NIC port and writes to the kernel NIC interfaces, the packet reception is the same as in L2 Forwarding sample application -(see Section 9.4.6 "Receive, Process and Transmit Packets"). +(see :ref:`l2_fwd_app_rx_tx_packets`). The packet transmission is done by sending mbufs into the kernel NIC interfaces by rte_kni_tx_burst(). The KNI library automatically frees the mbufs after the kernel successfully copied the mbufs. @@ -472,7 +471,7 @@ The KNI library automatically frees the mbufs after the kernel successfully copi For the other case that reads from kernel NIC interfaces and writes to a physical NIC port, packets are retrieved by reading mbufs from kernel NIC interfaces by `rte_kni_rx_burst()`. The packet transmission is the same as in the L2 Forwarding sample application -(see Section 9.4.6 "Receive, Process and Transmit Packet's"). +(see :ref:`l2_fwd_app_rx_tx_packets`). .. code-block:: c -- 1.9.1
[dpdk-dev] [PATCH 08/19] doc: fix kepp alive sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/keep_alive.rst | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/doc/guides/sample_app_ug/keep_alive.rst b/doc/guides/sample_app_ug/keep_alive.rst index 080811b..b00f43b 100644 --- a/doc/guides/sample_app_ug/keep_alive.rst +++ b/doc/guides/sample_app_ug/keep_alive.rst @@ -59,7 +59,7 @@ Note: Only the worker cores are monitored. A local (on the host) mechanism or agent to supervise the Keep Alive Monitor Agent Core DPDK core is required to detect its failure. -Note: This application is based on the L2 forwarding application. As +Note: This application is based on the :doc:`l2_forward_real_virtual`. As such, the initialization and run-time paths are very similar to those of the L2 forwarding application. @@ -127,9 +127,7 @@ Explanation The following sections provide some explanation of the The Keep-Alive/'Liveliness' conceptual scheme. As mentioned in the overview section, the initialization and run-time paths are very -similar to those of the L2 forwarding application (see Chapter 9 -"L2 Forwarding Sample Application (in Real and Virtualized -Environments)" for more information). +similar to those of the :doc:`l2_forward_real_virtual`. The Keep-Alive/'Liveliness' conceptual scheme: -- 1.9.1
[dpdk-dev] [PATCH 07/19] doc: fix multicast sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/ipv4_multicast.rst | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/doc/guides/sample_app_ug/ipv4_multicast.rst b/doc/guides/sample_app_ug/ipv4_multicast.rst index ec76087..67ea944 100644 --- a/doc/guides/sample_app_ug/ipv4_multicast.rst +++ b/doc/guides/sample_app_ug/ipv4_multicast.rst @@ -39,8 +39,7 @@ Overview The application demonstrates the use of zero-copy buffers for packet forwarding. -The initialization and run-time paths are very similar to those of the L2 forwarding application -(see Chapter 9 "L2 Forwarding Sample Application (in Real and Virtualized Environments)" for details more information). +The initialization and run-time paths are very similar to those of the :doc:`l2_forward_real_virtual`. This guide highlights the differences between the two applications. There are two key differences from the L2 Forwarding sample application: @@ -134,8 +133,7 @@ Explanation The following sections provide some explanation of the code. As mentioned in the overview section, -the initialization and run-time paths are very similar to those of the L2 Forwarding sample application -(see Chapter 9 "L2 Forwarding Sample Application in Real and Virtualized Environments" for more information). +the initialization and run-time paths are very similar to those of the :doc:`l2_forward_real_virtual`. The following sections describe aspects that are specific to the IPv4 Multicast sample application. Memory Pool Initialization -- 1.9.1
[dpdk-dev] [PATCH 06/19] doc: fix ip reassembly sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/ip_reassembly.rst | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/doc/guides/sample_app_ug/ip_reassembly.rst b/doc/guides/sample_app_ug/ip_reassembly.rst index 6bf5938..3c5cc70 100644 --- a/doc/guides/sample_app_ug/ip_reassembly.rst +++ b/doc/guides/sample_app_ug/ip_reassembly.rst @@ -39,8 +39,7 @@ Overview The application demonstrates the use of the DPDK libraries to implement packet forwarding with reassembly for IPv4 and IPv6 fragmented packets. -The initialization and run- time paths are very similar to those of the L2 forwarding application -(see Chapter 9 "L2 Forwarding Sample Application" for more information). +The initialization and run- time paths are very similar to those of the :doc:`l2_forward_real_virtual`. The main difference from the L2 Forwarding sample application is that it reassembles fragmented IPv4 and IPv6 packets before forwarding. The maximum allowed size of reassembled packet is 9.5 KB. @@ -182,8 +181,7 @@ Explanation --- The following sections provide some explanation of the sample application code. -As mentioned in the overview section, the initialization and run-time paths are very similar to those of the L2 forwarding application -(see Chapter 9 "L2 Forwarding Sample Application" for more information). +As mentioned in the overview section, the initialization and run-time paths are very similar to those of the :doc:`l2_forward_real_virtual`. The following sections describe aspects that are specific to the IP reassemble sample application. IPv4 Fragment Table Initialization -- 1.9.1
[dpdk-dev] [PATCH 05/19] doc: fix ip fragmentation sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/ip_frag.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/doc/guides/sample_app_ug/ip_frag.rst b/doc/guides/sample_app_ug/ip_frag.rst index 0c18fff..0c8da19 100644 --- a/doc/guides/sample_app_ug/ip_frag.rst +++ b/doc/guides/sample_app_ug/ip_frag.rst @@ -39,8 +39,7 @@ Overview The application demonstrates the use of zero-copy buffers for packet fragmentation. -The initialization and run-time paths are very similar to those of the L2 forwarding application -(see Chapter 9 "L2 Forwarding Simple Application (in Real and Virtualized Environments)" for more information). +The initialization and run-time paths are very similar to those of the :doc:`l2_forward_real_virtual`. This guide highlights the differences between the two applications. There are three key differences from the L2 Forwarding sample application: -- 1.9.1
[dpdk-dev] [PATCH 04/19] doc: fix intel quickAssist technology sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/intel_quickassist.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/guides/sample_app_ug/intel_quickassist.rst b/doc/guides/sample_app_ug/intel_quickassist.rst index a80d4ca..04d1593 100644 --- a/doc/guides/sample_app_ug/intel_quickassist.rst +++ b/doc/guides/sample_app_ug/intel_quickassist.rst @@ -203,7 +203,7 @@ where, * --config'(port,queue,lcore)[,(port,queue,lcore)]': determines which queues from which ports are mapped to which cores. -Refer to Chapter 10 , "L3 Forwarding Sample Application" for more detailed descriptions of the --config command line option. +Refer to the :doc:`l3_forward` for more detailed descriptions of the --config command line option. As an example, to run the application with two ports and two cores, which are using different Intel?? QuickAssist Technology execution engines, -- 1.9.1
[dpdk-dev] [PATCH 03/19] doc: fix exception path sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/exception_path.rst | 5 ++--- doc/guides/sample_app_ug/l2_forward_real_virtual.rst | 4 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/doc/guides/sample_app_ug/exception_path.rst b/doc/guides/sample_app_ug/exception_path.rst index c3f8f88..161b6e0 100644 --- a/doc/guides/sample_app_ug/exception_path.rst +++ b/doc/guides/sample_app_ug/exception_path.rst @@ -134,8 +134,7 @@ The following sections provide some explanation of the code. Initialization ~~ -Setup of the mbuf pool, driver and queues is similar to the setup done in the L2 Forwarding sample application -(see Chapter 9 "L2 forwarding Sample Application (in Real and Virtualized Environments" for details). +Setup of the mbuf pool, driver and queues is similar to the setup done in the :ref:`l2_fwd_app_real_and_virtual`. In addition, the TAP interfaces must also be created. A TAP interface is created for each lcore that is being used. The code for creating the TAP interface is as follows: @@ -221,7 +220,7 @@ This function first checks the lcore_id against the user provided input_cores_ma if this core is reading from or writing to a TAP interface. For the case that reads from a NIC port, the packet reception is the same as in the L2 Forwarding sample application -(see Section 9.4.6, "Receive, Process and Transmit Packets"). +(see :ref:`l2_fwd_app_rx_tx_packets`). The packet transmission is done by calling write() with the file descriptor of the appropriate TAP interface and then explicitly freeing the mbuf back to the pool. diff --git a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst index 6e61b4b..12f0d27 100644 --- a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst +++ b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst @@ -28,6 +28,8 @@ (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +.. _l2_fwd_app_real_and_virtual: + L2 Forwarding Sample Application (in Real and Virtualized Environments) === @@ -387,6 +389,8 @@ The global configuration for TX queues is stored in a static structure: .tx_free_thresh = RTE_TEST_TX_DESC_DEFAULT + 1, /* disable feature */ }; +.. _l2_fwd_app_rx_tx_packets: + Receive, Process and Transmit Packets ~ -- 1.9.1
[dpdk-dev] [PATCH 01/19] doc: fix vhost sample app hard-coded references
Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/vhost.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/guides/sample_app_ug/vhost.rst b/doc/guides/sample_app_ug/vhost.rst index e5d1326..751656c 100644 --- a/doc/guides/sample_app_ug/vhost.rst +++ b/doc/guides/sample_app_ug/vhost.rst @@ -260,7 +260,7 @@ Setting up the Guest Execution Environment ~~ It is recommended for testing purposes that the DPDK testpmd sample application is used in the guest to forward packets, -the reasons for this are discussed in Section 22.7, "Running the Virtual Machine (QEMU)". +the reasons for this are discussed in `Running the Virtual Machine (QEMU)`_. The testpmd application forwards packets between pairs of Ethernet devices, it requires an even number of Ethernet devices (virtio or otherwise) to execute. @@ -583,7 +583,7 @@ an open file descriptor must be passed to QEMU running as a child process. .. note:: -This process is automated in the QEMU wrapper script discussed in Section 24.7.3. +This process is automated in the `QEMU Wrapper Script`_. Mapping the Virtual Machine's Memory @@ -600,7 +600,7 @@ In this case, the path passed to the guest should be that of the 1 GB page huget .. note:: -This process is automated in the QEMU wrapper script discussed in Section 24.7.3. +This process is automated in the `QEMU Wrapper Script`_. The following two sections only applies to vhost cuse. For vhost-user, please make corresponding changes to qemu-wrapper script and guest XML file. -- 1.9.1
[dpdk-dev] [PATCH] doc: fix vhost bad section number references
Section numbers were "hard-coded". This patch adds them as hyperlinks. Signed-off-by: Mauricio Vasquez B --- doc/guides/sample_app_ug/vhost.rst | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/doc/guides/sample_app_ug/vhost.rst b/doc/guides/sample_app_ug/vhost.rst index e5d1326..2ad2243 100644 --- a/doc/guides/sample_app_ug/vhost.rst +++ b/doc/guides/sample_app_ug/vhost.rst @@ -260,7 +260,7 @@ Setting up the Guest Execution Environment ~~ It is recommended for testing purposes that the DPDK testpmd sample application is used in the guest to forward packets, -the reasons for this are discussed in Section 22.7, "Running the Virtual Machine (QEMU)". +the reasons for this are discussed in :ref:`running_the_vm`. The testpmd application forwards packets between pairs of Ethernet devices, it requires an even number of Ethernet devices (virtio or otherwise) to execute. @@ -530,6 +530,8 @@ It is enabled by default. ./vhost-switch -c f -n 4 --socket-mem 1024 --huge-dir /mnt/huge \ -- --vlan-strip [0, 1] +.. _running_the_vm: + Running the Virtual Machine (QEMU) -- @@ -583,7 +585,7 @@ an open file descriptor must be passed to QEMU running as a child process. .. note:: -This process is automated in the QEMU wrapper script discussed in Section 24.7.3. +This process is automated in the :ref:`qemu_wrapper`. Mapping the Virtual Machine's Memory @@ -600,10 +602,12 @@ In this case, the path passed to the guest should be that of the 1 GB page huget .. note:: -This process is automated in the QEMU wrapper script discussed in Section 24.7.3. +This process is automated in the :ref:`qemu_wrapper`. The following two sections only applies to vhost cuse. For vhost-user, please make corresponding changes to qemu-wrapper script and guest XML file. +.. _qemu_wrapper: + QEMU Wrapper Script ~~~ -- 1.9.1
[dpdk-dev] [PATCH v2] tools/dpdk_nic_bind: fix flake8 warnings
flake8 checks were run for both python 2.7 and 3.4
There were some style issues as:
- Line width > 79
- No double blank line before function definition
- No double blank space before inline comment
- Some other minor issues
Signed-off-by: Mauricio Vasquez B
---
v2:
fix still existing warning
tools/dpdk_nic_bind.py | 167 -
1 file changed, 97 insertions(+), 70 deletions(-)
diff --git a/tools/dpdk_nic_bind.py b/tools/dpdk_nic_bind.py
index 14c5311..28eace3 100755
--- a/tools/dpdk_nic_bind.py
+++ b/tools/dpdk_nic_bind.py
@@ -32,10 +32,12 @@
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
-import sys, os, getopt, subprocess
+import sys
+import os
+import getopt
+import subprocess
from os.path import exists, abspath, dirname, basename
-
# The PCI device class for ETHERNET devices
ETHERNET_CLASS = "0200"
@@ -43,7 +45,7 @@ ETHERNET_CLASS = "0200"
# Each device within this is itself a dictionary of device properties
devices = {}
# list of supported DPDK drivers
-dpdk_drivers = [ "igb_uio", "vfio-pci", "uio_pci_generic" ]
+dpdk_drivers = ["igb_uio", "vfio-pci", "uio_pci_generic"]
# command-line arg flags
b_flag = None
@@ -51,10 +53,11 @@ status_flag = False
force_flag = False
args = []
+
def usage():
'''Print usage information for the program'''
argv0 = basename(sys.argv[0])
-print ("""
+print("""
Usage:
--
@@ -78,8 +81,9 @@ Options:
* the driver being used e.g. drv=igb_uio
* any suitable drivers not currently using that device
e.g. unused=igb_uio
-NOTE: if this flag is passed along with a bind/unbind option, the
status
-display will always occur after the other operations have taken place.
+NOTE: if this flag is passed along with a bind/unbind option, the
+status display will always occur after the other operations have taken
+place.
-b driver, --bind=driver:
Select the driver to use or \"none\" to unbind the device
@@ -110,7 +114,8 @@ To unbind :01:00.0 from using any driver
To bind :02:00.0 and :02:00.1 to the ixgbe kernel driver
%(argv0)s -b ixgbe 02:00.0 02:00.1
-""" % locals()) # replace items from local variables
+""" % locals()) # replace items from local variables
+
# This is roughly compatible with check_output function in subprocess module
# which is only available in python 2.7.
@@ -119,6 +124,7 @@ def check_output(args, stderr=None):
return subprocess.Popen(args, stdout=subprocess.PIPE,
stderr=stderr).communicate()[0]
+
def find_module(mod):
'''find the .ko file for kernel module named mod.
Searches the $RTE_SDK/$RTE_TARGET directory, the kernel
@@ -126,20 +132,20 @@ def find_module(mod):
the script '''
# check $RTE_SDK/$RTE_TARGET directory
if 'RTE_SDK' in os.environ and 'RTE_TARGET' in os.environ:
-path = "%s/%s/kmod/%s.ko" % (os.environ['RTE_SDK'],\
+path = "%s/%s/kmod/%s.ko" % (os.environ['RTE_SDK'],
os.environ['RTE_TARGET'], mod)
if exists(path):
return path
# check using depmod
try:
-depmod_out = check_output(["modinfo", "-n", mod], \
+depmod_out = check_output(["modinfo", "-n", mod],
stderr=subprocess.STDOUT).lower()
if "error" not in depmod_out:
path = depmod_out.strip()
if exists(path):
return path
-except: # if modinfo can't find module, it fails, so continue
+except: # if modinfo can't find module, it fails, so continue
pass
# check for a copy based off current path
@@ -147,17 +153,18 @@ def find_module(mod):
if (tools_dir.endswith("tools")):
base_dir = dirname(tools_dir)
find_out = check_output(["find", base_dir, "-name", mod + ".ko"])
-if len(find_out) > 0: #something matched
+if len(find_out) > 0: # something matched
path = find_out.splitlines()[0]
if exists(path):
return path
+
def check_modules():
'''Checks that igb_uio is loaded'''
global dpdk_drivers
# list of supported modules
-mods = [{"Name" : driver, "Found" : False} for driver in dpdk_drivers]
+mods = [{"Name": driver, "Found": False} for driver in dpdk_drivers]
# first check if module is loaded
try:
@@ -186,18 +193,20 @@ def check_modules():
# check if we have at least one loaded module
if True not in [mod["Found"] for mod in mods] and b_flag is not None:
if b
[dpdk-dev] [PATCH] tools/dpdk_nic_bind: fix flake8 warnings
flake8 checks were run for both python 2.7 and 3.4
There were some style issues as:
- Line width > 79
- No double blank line before function definition
- No double blank space before inline comment
- Some other minor issues
Signed-off-by: Mauricio Vasquez B
---
tools/dpdk_nic_bind.py | 165 -
1 file changed, 96 insertions(+), 69 deletions(-)
diff --git a/tools/dpdk_nic_bind.py b/tools/dpdk_nic_bind.py
index 14c5311..19ac438 100755
--- a/tools/dpdk_nic_bind.py
+++ b/tools/dpdk_nic_bind.py
@@ -32,10 +32,12 @@
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
-import sys, os, getopt, subprocess
+import sys
+import os
+import getopt
+import subprocess
from os.path import exists, abspath, dirname, basename
-
# The PCI device class for ETHERNET devices
ETHERNET_CLASS = "0200"
@@ -43,7 +45,7 @@ ETHERNET_CLASS = "0200"
# Each device within this is itself a dictionary of device properties
devices = {}
# list of supported DPDK drivers
-dpdk_drivers = [ "igb_uio", "vfio-pci", "uio_pci_generic" ]
+dpdk_drivers = ["igb_uio", "vfio-pci", "uio_pci_generic"]
# command-line arg flags
b_flag = None
@@ -51,10 +53,11 @@ status_flag = False
force_flag = False
args = []
+
def usage():
'''Print usage information for the program'''
argv0 = basename(sys.argv[0])
-print ("""
+print("""
Usage:
--
@@ -78,8 +81,9 @@ Options:
* the driver being used e.g. drv=igb_uio
* any suitable drivers not currently using that device
e.g. unused=igb_uio
-NOTE: if this flag is passed along with a bind/unbind option, the
status
-display will always occur after the other operations have taken place.
+NOTE: if this flag is passed along with a bind/unbind option, the
+status display will always occur after the other operations have taken
+place.
-b driver, --bind=driver:
Select the driver to use or \"none\" to unbind the device
@@ -110,7 +114,8 @@ To unbind :01:00.0 from using any driver
To bind :02:00.0 and :02:00.1 to the ixgbe kernel driver
%(argv0)s -b ixgbe 02:00.0 02:00.1
-""" % locals()) # replace items from local variables
+""" % locals()) # replace items from local variables
+
# This is roughly compatible with check_output function in subprocess module
# which is only available in python 2.7.
@@ -119,6 +124,7 @@ def check_output(args, stderr=None):
return subprocess.Popen(args, stdout=subprocess.PIPE,
stderr=stderr).communicate()[0]
+
def find_module(mod):
'''find the .ko file for kernel module named mod.
Searches the $RTE_SDK/$RTE_TARGET directory, the kernel
@@ -126,20 +132,20 @@ def find_module(mod):
the script '''
# check $RTE_SDK/$RTE_TARGET directory
if 'RTE_SDK' in os.environ and 'RTE_TARGET' in os.environ:
-path = "%s/%s/kmod/%s.ko" % (os.environ['RTE_SDK'],\
+path = "%s/%s/kmod/%s.ko" % (os.environ['RTE_SDK'],
os.environ['RTE_TARGET'], mod)
if exists(path):
return path
# check using depmod
try:
-depmod_out = check_output(["modinfo", "-n", mod], \
+depmod_out = check_output(["modinfo", "-n", mod],
stderr=subprocess.STDOUT).lower()
if "error" not in depmod_out:
path = depmod_out.strip()
if exists(path):
return path
-except: # if modinfo can't find module, it fails, so continue
+except: # if modinfo can't find module, it fails, so continue
pass
# check for a copy based off current path
@@ -147,17 +153,18 @@ def find_module(mod):
if (tools_dir.endswith("tools")):
base_dir = dirname(tools_dir)
find_out = check_output(["find", base_dir, "-name", mod + ".ko"])
-if len(find_out) > 0: #something matched
+if len(find_out) > 0: # something matched
path = find_out.splitlines()[0]
if exists(path):
return path
+
def check_modules():
'''Checks that igb_uio is loaded'''
global dpdk_drivers
# list of supported modules
-mods = [{"Name" : driver, "Found" : False} for driver in dpdk_drivers]
+mods = [{"Name": driver, "Found": False} for driver in dpdk_drivers]
# first check if module is loaded
try:
@@ -186,18 +193,20 @@ def check_modules():
# check if we have at least one loaded module
if True not in [mod["Found"] for mod in mods] and b_flag is not None:
if b_flag in dpdk_drivers:
-
[dpdk-dev] [PATCH] ring: Fix memory leakage in rte_pmd_ring_devuninit
When freeing the device it is also neccesary to free
rx_queues and tx_queues
Signed-off-by: Mauricio Vasquez B
---
v2:
Added extra control before freeing members of eth_dev->data
drivers/net/ring/rte_eth_ring.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
index 9a31bce..4ce0256 100644
--- a/drivers/net/ring/rte_eth_ring.c
+++ b/drivers/net/ring/rte_eth_ring.c
@@ -582,7 +582,12 @@ rte_pmd_ring_devuninit(const char *name)
return -ENODEV;
eth_dev_stop(eth_dev);
- rte_free(eth_dev->data->dev_private);
+
+ if(eth_dev->data) {
+ rte_free(eth_dev->data->rx_queues);
+ rte_free(eth_dev->data->tx_queues);
+ rte_free(eth_dev->data->dev_private);
+ }
rte_free(eth_dev->data);
rte_eth_dev_release_port(eth_dev);
--
1.9.1
[dpdk-dev] [PATCH] ring: Fix memory leakage in rte_pmd_ring_devuninit()
When freeing the device, it is also necessary to free rx_queues and tx_queues Signed-off-by: Mauricio Vasquez B --- drivers/net/ring/rte_eth_ring.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c index 9a31bce..e091e4f 100644 --- a/drivers/net/ring/rte_eth_ring.c +++ b/drivers/net/ring/rte_eth_ring.c @@ -582,6 +582,9 @@ rte_pmd_ring_devuninit(const char *name) return -ENODEV; eth_dev_stop(eth_dev); + + rte_free(eth_dev->data->rx_queues); + rte_free(eth_dev->data->tx_queues); rte_free(eth_dev->data->dev_private); rte_free(eth_dev->data); -- 1.9.1
