[dpdk-dev] [PATCH v1] doc: add template release notes for 17.02
On 14/11/2016 20:31, John McNamara wrote: > Add template release notes for DPDK 17.02 with inline > comments and explanations of the various sections. > > Signed-off-by: John McNamara Acked-by: Remy Horton
[dpdk-dev] [PATCH v1 2/2] net/i40e: fix spelling errors
On 11/14/2016 06:14 AM, Remy Horton wrote:
> Fixes: da61cd084976 ("i40evf: add extended stats")
> Fixes: 0eedec25ea36 ("i40e: clean log messages")
>
Acked-by: Kevin Traynor
> Signed-off-by: Remy Horton
> ---
> drivers/net/i40e/i40e_ethdev.c| 2 +-
> drivers/net/i40e/i40e_ethdev_vf.c | 6 +++---
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 67778ba..f102328 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -4107,7 +4107,7 @@ i40e_veb_setup(struct i40e_pf *pf, struct i40e_vsi *vsi)
> ret = i40e_aq_get_veb_parameters(hw, veb->seid, NULL, NULL,
> &veb->stats_idx, NULL, NULL, NULL);
> if (ret != I40E_SUCCESS) {
> - PMD_DRV_LOG(ERR, "Get veb statics index failed, aq_err: %d",
> + PMD_DRV_LOG(ERR, "Get veb statistics index failed, aq_err: %d",
> hw->aq.asq_last_status);
> goto fail;
> }
> diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
> b/drivers/net/i40e/i40e_ethdev_vf.c
> index afae2ec..1431b6e 100644
> --- a/drivers/net/i40e/i40e_ethdev_vf.c
> +++ b/drivers/net/i40e/i40e_ethdev_vf.c
> @@ -952,7 +952,7 @@ i40evf_update_stats(struct rte_eth_dev *dev, struct
> i40e_eth_stats **pstats)
> }
>
> static int
> -i40evf_get_statics(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
> +i40evf_get_statistics(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
> {
> int ret;
> struct i40e_eth_stats *pstats = NULL;
> @@ -2277,8 +2277,8 @@ i40evf_dev_info_get(struct rte_eth_dev *dev, struct
> rte_eth_dev_info *dev_info)
> static void
> i40evf_dev_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
> {
> - if (i40evf_get_statics(dev, stats))
> - PMD_DRV_LOG(ERR, "Get statics failed");
> + if (i40evf_get_statistics(dev, stats))
> + PMD_DRV_LOG(ERR, "Get statistics failed");
> }
>
> static void
>
[dpdk-dev] [PATCH v1 1/2] net/i40e: fix incorrect xstats value mapping
On 11/14/2016 06:14 AM, Remy Horton wrote:
> The offsets used in rte_i40evf_stats_strings for transmission
> statistics were wrong, returning the total byte count rather than
> the respective (unicast, multicast, broadcast, drop, & error)
> packet counts.
>
> Fixes: da61cd084976 ("i40evf: add extended stats")
This should go to the LTS branch also.
Acked-by: Kevin Traynor
>
> Signed-off-by: Remy Horton
> ---
> drivers/net/i40e/i40e_ethdev_vf.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
> b/drivers/net/i40e/i40e_ethdev_vf.c
> index aa306d6..afae2ec 100644
> --- a/drivers/net/i40e/i40e_ethdev_vf.c
> +++ b/drivers/net/i40e/i40e_ethdev_vf.c
> @@ -176,11 +176,11 @@ static const struct rte_i40evf_xstats_name_off
> rte_i40evf_stats_strings[] = {
> {"rx_unknown_protocol_packets", offsetof(struct i40e_eth_stats,
> rx_unknown_protocol)},
> {"tx_bytes", offsetof(struct i40e_eth_stats, tx_bytes)},
> - {"tx_unicast_packets", offsetof(struct i40e_eth_stats, tx_bytes)},
> - {"tx_multicast_packets", offsetof(struct i40e_eth_stats, tx_bytes)},
> - {"tx_broadcast_packets", offsetof(struct i40e_eth_stats, tx_bytes)},
> - {"tx_dropped_packets", offsetof(struct i40e_eth_stats, tx_bytes)},
> - {"tx_error_packets", offsetof(struct i40e_eth_stats, tx_bytes)},
> + {"tx_unicast_packets", offsetof(struct i40e_eth_stats, tx_unicast)},
> + {"tx_multicast_packets", offsetof(struct i40e_eth_stats, tx_multicast)},
> + {"tx_broadcast_packets", offsetof(struct i40e_eth_stats, tx_broadcast)},
> + {"tx_dropped_packets", offsetof(struct i40e_eth_stats, tx_discards)},
> + {"tx_error_packets", offsetof(struct i40e_eth_stats, tx_errors)},
> };
>
> #define I40EVF_NB_XSTATS (sizeof(rte_i40evf_stats_strings) / \
>
[dpdk-dev] Clarification for eth_driver changes
On 11/12/2016 5:44 PM, Shreyansh Jain wrote:
> Hello Ferruh,
>
> (Please ignore if line wrappings are not correct. Using a possibly
> unconfigured mail client).
>
>> -Original Message-
>> From: Ferruh Yigit [mailto:ferruh.yigit at intel.com]
>> Sent: Saturday, November 12, 2016 12:46 AM
>> To: Shreyansh Jain ; David Marchand
>>
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] Clarification for eth_driver changes
>>
>> On 11/10/2016 11:05 AM, Shreyansh Jain wrote:
>>> Hello David,
>>>
>>> On Thursday 10 November 2016 01:46 PM, David Marchand wrote:
Hello Shreyansh,
On Thu, Nov 10, 2016 at 8:26 AM, Shreyansh Jain
>> wrote:
> I need some help and clarification regarding some changes I am doing to
> cleanup the EAL code.
>
> There are some changes which should be done for eth_driver/rte_eth_device
> structures:
>
> 1. most obvious, eth_driver should be renamed to rte_eth_driver.
> 2. eth_driver currently has rte_pci_driver embedded in it
> - there can be ethernet devices which are _not_ PCI
> - in which case, this structure should be removed.
Do we really need to keep a eth_driver ?
>>>
>>> No. As you have rightly mentioned below (as well as in your Jan'16
>>> post), it is a mere convenience.
>>
>> Isn't it good to separate the logic related which bus device connected
>> and what functionality it provides. Because these two can be flexible:
>
> Indeed. The very idea of a Bus model is to make a hierarchy which allows
> for pluggability/flexibility in terms of devices being used. But, until now I
> have only considered placement hierarchy and not functional hierarchy. (more
> below)
>
>>
>> device -> virtual_bus -> ethernet_functionality
>> device -> pci_bus -> crypto_functionality
>> device -> x_bus -> y_function
>>
>
> Ok.
>
>>
>> what about:
>>
>> create generic bus driver/device and all eal level deal with generic
>> bus. different buses inherit from generic bus logic
>
> From what I had in mind: (and very much similar to what you have already
> mentioned in this email)
> - a generic bus (not a driver, not a device). I don't know how to categorize
>a bus. It is certainly not a device, and then handler for a bus (physical)
>can be considered a 'bus driver'. So, just 'rte_bus'.
> - there is a bus for each physical implementation (or virtual). So, a rte_bus
>Object for PCI, VDEV, ABC, DEF and so on.
> - Buses are registered just like a PMD - RTE_PMD_BUS_REGISTER()
> -- There is a problem of making sure the constructor for bus registration is
> executed before drivers. Probably by putting the bus code within lib*
> - Each registered bus is part of a doubly list.
> - Each device inherits rte_bus
> - Each driver inherits rte_bus
> - Existing Device and Drivers lists would be moved into rte_bus
>
> (more below)
>
>>
>> create generic functionality device/driver and pmd level deal with
>> these. different functionalities inherit from generic functionality logic
>>
>> and use rte_device/rte_driver as glue logic for all these.
>>
>> This makes easy to add new bus or functionality device/drivers without
>> breaking existing logic.
>>
>>
>> Something like this:
>>
>> struct rte_device {
>> char *name;
>> struct rte_driver *drv;
>> struct rte_bus_device *bus_dev;
>> struct rte_funcional_device *func_dev;
>> *devargs
>> }
>>
>> struct rte_bus_device {
>> struct rte_device *dev;
>> /* generic bus device */
>> }
>
> This is where you lost me. From what I understood from your text:
> (CMIIW)
>
> - Most abstract class is 'rte_device'.
> - A bus is a device. So, it points to a rte_device
> - But, a rte_device belongs to a bus, so it points to a rte_bus_device.
>
> Isn't that contradictory?
What I was thinking is:
rte_device/driver are not abstract classes.
rte_bus device/driver is an abstract class and any bus inherited from
this class.
rte_func device/driver is and abstract class and eth/crypto inherited
from this class.
eal layer only deal with rte_bus
pmd's only deal with functional device/driver
but still, it is required to know device <-> driver, and functional <->
bus, relations. rte_dev/rte_driver are to provide this links.
But yes this add extra layer and with second thought I am not sure if it
is really possible to separate bus and functionality, this was just an
idea ..
>
> This is how I view the physical layout of devices on which DPDK works:
>
> +-+ +--+
> |Driver 1A| |Driver 2B |
> |servicing| |servicing | (*)
> |Bus A| |Bus B |
> +-+ +--+
> \ /
> +-+ +---+
> | bus A |---| bus B |--- ...
> +-+ +---+
> / \ \ \
> / \_\
[dpdk-dev] XL710 with DELOCK 86256 qsfp+
I just upgraded the XL710 cards with "FW 5.0 API 1.5 NVM 05.00.04 eetrack 80002505" firmware which, I believe, is the latest. Thanks, -nagp On Mon, Nov 14, 2016 at 3:49 PM, Nagaprabhanjan Bellaru < nagp.lists at gmail.com> wrote: > Though the ports of XL710 are getting detected by DPDK, when I insert the > above QSFP twinax cable and try to bring up the port, I get a "Operation > not supported" error. When I looked further, I see that trying to bring up > the port is resulting in I40E_AQ_RC_EIO and returning I40E_ERR_UNKNOWN_PHY. > > Can somebody help me in understanding whether this is a genuine error? > > Thanks, > -nagp >
[dpdk-dev] XL710 with DELOCK 86256 qsfp+
Though the ports of XL710 are getting detected by DPDK, when I insert the above QSFP twinax cable and try to bring up the port, I get a "Operation not supported" error. When I looked further, I see that trying to bring up the port is resulting in I40E_AQ_RC_EIO and returning I40E_ERR_UNKNOWN_PHY. Can somebody help me in understanding whether this is a genuine error? Thanks, -nagp
[dpdk-dev] Running 2 process on the same machine
On Tue, Nov 08, 2016 at 02:02:32PM +0200, Keren Hochman wrote: > Also, I can't understand how to define socket-mem. I did not see anything > related to hugepages in /etc/sysctl.conf. Can i mount hugepages to 2 > different dirs instead and use --huge-dir ? > Thank you. > Doing so would be a replacement for using the --file-prefix option, because even with two different hugepage mount points all pages can be used via each one, meaning the first process can still use all hugepage memory. The only exception to this that I know of is if the two mountpoints are for two different sizes of hugepages. With regards to the process failing if you use the --no-huge option: did you try running with --no-huge and a -m or --socket-mem option? By default, I think the --no-huge option only allocates a relatively small amount of memory for DPDK use. Try "--no-huge -m 2048" and see if that helps. Regards, /Bruce
[dpdk-dev] [PATCH v1] doc: add template release notes for 17.02
> > Add template release notes for DPDK 17.02 with inline > > comments and explanations of the various sections. > > > > Signed-off-by: John McNamara > > Acked-by: Remy Horton Applied, thanks We are ready to start a new release cycle. The version in the master branch is now 17.02-rc0.
[dpdk-dev] two different threads polls the same port, different queues, why the throughput is the same
On Mon, Nov 14, 2016 at 2:28 PM, ?? wrote: > Hi all, > > > I have two threads process the packets with different ways. thread A (core 0) > is very heavy, thread B (core 1) is very light. If I just run each of them, > their throughput is huge different with small packet. Thread A polls queue 0 > of port 0, thread B polls queue 1 of port 0. If I run them at the same time, > why thread A and thread B get same throughput. This makes me very confused. > Does anyone have the same experience or know some possible reasons? > Can you give some examples with numbers? My first thought is that maybe the two threads are contending for the same physical core. You don't have any locking/critical sections, do you? > > Thanks, > wei
[dpdk-dev] [PATCH v2] doc: add sub-repositories information
2016-11-11 13:34, Ferruh Yigit: > DPDK switched to main and sub-repositories approach, this patch > documents new approach and updates development process according. > > Signed-off-by: Ferruh Yigit > Acked-by: John McNamara Applied, thanks
[dpdk-dev] [PATCH] maintainers: add staging tree for network drivers
> > Networking Drivers > > -- > > +M: Ferruh Yigit > > +T: git://dpdk.org/next/dpdk-next-net > > Acked-by: Thomas Monjalon > > It will be applied at the beginning of 17.02 cycle to reflect the change. Applied, thanks. So from now, Ferruh will be responsible of the next-net tree. Thank you for your commitment.
[dpdk-dev] two different threads polls the same port, different queues, why the throughput is the same
I do not have any lock/critical sections in my code. I have logs to print out the core id, src port, dst port and queue id. worker 0 runs on core 1, run macswap very light, the throughput is 4.5Mpps. worker 1 runs on core2, is a load balancer heavy, the throughput is also 4.5Mpps. This does not make sense at all. ***thread core_id=1, src_port=0, dst_port=0, rx_queue_id=0, tx_queue_id=0 ***thread core_id=2, src_port=0, dst_port=0, rx_queue_id=1, tx_queue_id=1 Core 0: Running stat thread worker_id=0, core_id=1, pkt_rate=4418972 worker_id=1, core_id=2, pkt_rate=4419808 worker_id=0, core_id=1, pkt_rate=4631684 worker_id=1, core_id=2, pkt_rate=4632928 At 2016-11-14 14:13:25, "Kyle Larose" wrote: >On Mon, Nov 14, 2016 at 2:28 PM, ?? wrote: >> Hi all, >> >> >> I have two threads process the packets with different ways. thread A (core >> 0) is very heavy, thread B (core 1) is very light. If I just run each of >> them, their throughput is huge different with small packet. Thread A polls >> queue 0 of port 0, thread B polls queue 1 of port 0. If I run them at the >> same time, why thread A and thread B get same throughput. This makes me very >> confused. Does anyone have the same experience or know some possible reasons? >> > >Can you give some examples with numbers? My first thought is that >maybe the two threads are contending for the same physical core. You >don't have any locking/critical sections, do you? >> >> Thanks, >> wei
[dpdk-dev] [PATCH v1 2/2] net/i40e: fix spelling errors
Fixes: da61cd084976 ("i40evf: add extended stats")
Fixes: 0eedec25ea36 ("i40e: clean log messages")
Signed-off-by: Remy Horton
---
drivers/net/i40e/i40e_ethdev.c| 2 +-
drivers/net/i40e/i40e_ethdev_vf.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 67778ba..f102328 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -4107,7 +4107,7 @@ i40e_veb_setup(struct i40e_pf *pf, struct i40e_vsi *vsi)
ret = i40e_aq_get_veb_parameters(hw, veb->seid, NULL, NULL,
&veb->stats_idx, NULL, NULL, NULL);
if (ret != I40E_SUCCESS) {
- PMD_DRV_LOG(ERR, "Get veb statics index failed, aq_err: %d",
+ PMD_DRV_LOG(ERR, "Get veb statistics index failed, aq_err: %d",
hw->aq.asq_last_status);
goto fail;
}
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
b/drivers/net/i40e/i40e_ethdev_vf.c
index afae2ec..1431b6e 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -952,7 +952,7 @@ i40evf_update_stats(struct rte_eth_dev *dev, struct
i40e_eth_stats **pstats)
}
static int
-i40evf_get_statics(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
+i40evf_get_statistics(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
{
int ret;
struct i40e_eth_stats *pstats = NULL;
@@ -2277,8 +2277,8 @@ i40evf_dev_info_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
static void
i40evf_dev_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
{
- if (i40evf_get_statics(dev, stats))
- PMD_DRV_LOG(ERR, "Get statics failed");
+ if (i40evf_get_statistics(dev, stats))
+ PMD_DRV_LOG(ERR, "Get statistics failed");
}
static void
--
2.5.5
[dpdk-dev] [PATCH v1 1/2] net/i40e: fix incorrect xstats value mapping
The offsets used in rte_i40evf_stats_strings for transmission
statistics were wrong, returning the total byte count rather than
the respective (unicast, multicast, broadcast, drop, & error)
packet counts.
Fixes: da61cd084976 ("i40evf: add extended stats")
Signed-off-by: Remy Horton
---
drivers/net/i40e/i40e_ethdev_vf.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
b/drivers/net/i40e/i40e_ethdev_vf.c
index aa306d6..afae2ec 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -176,11 +176,11 @@ static const struct rte_i40evf_xstats_name_off
rte_i40evf_stats_strings[] = {
{"rx_unknown_protocol_packets", offsetof(struct i40e_eth_stats,
rx_unknown_protocol)},
{"tx_bytes", offsetof(struct i40e_eth_stats, tx_bytes)},
- {"tx_unicast_packets", offsetof(struct i40e_eth_stats, tx_bytes)},
- {"tx_multicast_packets", offsetof(struct i40e_eth_stats, tx_bytes)},
- {"tx_broadcast_packets", offsetof(struct i40e_eth_stats, tx_bytes)},
- {"tx_dropped_packets", offsetof(struct i40e_eth_stats, tx_bytes)},
- {"tx_error_packets", offsetof(struct i40e_eth_stats, tx_bytes)},
+ {"tx_unicast_packets", offsetof(struct i40e_eth_stats, tx_unicast)},
+ {"tx_multicast_packets", offsetof(struct i40e_eth_stats, tx_multicast)},
+ {"tx_broadcast_packets", offsetof(struct i40e_eth_stats, tx_broadcast)},
+ {"tx_dropped_packets", offsetof(struct i40e_eth_stats, tx_discards)},
+ {"tx_error_packets", offsetof(struct i40e_eth_stats, tx_errors)},
};
#define I40EVF_NB_XSTATS (sizeof(rte_i40evf_stats_strings) / \
--
2.5.5
[dpdk-dev] [PATCH v1 0/2] XStats fixes
The offsets used in rte_i40evf_stats_strings for transmission
statistics were wrong, returning the total byte count rather than
the respective (unicast, multicast, broadcast, drop, & error)
packet counts.
This patchset also fixes some spelling errors.
Fixes: da61cd084976 ("i40evf: add extended stats")
Fixes: 0eedec25ea36 ("i40e: clean log messages")
Remy Horton (2):
net/i40e: fix incorrect xstats value mapping
net/i40e: fix spelling errors
drivers/net/i40e/i40e_ethdev.c| 2 +-
drivers/net/i40e/i40e_ethdev_vf.c | 16
2 files changed, 9 insertions(+), 9 deletions(-)
--
2.5.5
[dpdk-dev] two different threads polls the same port, different queues, why the throughput is the same
Hi all, I have two threads process the packets with different ways. thread A (core 0) is very heavy, thread B (core 1) is very light. If I just run each of them, their throughput is huge different with small packet. Thread A polls queue 0 of port 0, thread B polls queue 1 of port 0. If I run them at the same time, why thread A and thread B get same throughput. This makes me very confused. Does anyone have the same experience or know some possible reasons? Thanks, wei
[dpdk-dev] [PATCH] vmxnet3: fix Rx deadlock
Our use case is that we have an app that needs to keep mbufs around
for a while. We've seen cases when calling vmxnet3_post_rx_bufs() from
vmxet3_recv_pkts(), it might not succeed to add any mbufs to any RX
descriptors (where it returns -err). Since there are no mbufs that the
virtual hardware can use, and since nobody calls
vmxnet3_post_rx_bufs() after that, no packets will be received after
this. I call this a deadlock for lack of a better term - the virtual
HW waits for free mbufs, while the app waits for the hardware to
notify it for data. Note that after this, the app can't recover.
This fix is a rework of this patch by Marco Lee:
http://dpdk.org/dev/patchwork/patch/6575/. I had to forward port it,
address review comments and also reverted the allocation failure
handing to the first version of the patch
(http://dpdk.org/ml/archives/dev/2015-July/022079.html), since that's
the only approach that seems to work, and seems to be what other
drivers are doing (I checked ixgbe and em). Reusing the mbuf that's
getting passed to the application doesn't seem to make sense, and it
was causing weird issues in our app. Also, reusing rxm without
checking if it's NULL could cause the code to crash.
Signed-off-by: Stefan Puiu
---
drivers/net/vmxnet3/vmxnet3_rxtx.c | 38 --
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c
b/drivers/net/vmxnet3/vmxnet3_rxtx.c
index b109168..c9d2488 100644
--- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
+++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
@@ -518,6 +518,32 @@
return nb_tx;
}
+static inline void
+vmxnet3_renew_desc(vmxnet3_rx_queue_t *rxq, uint8_t ring_id,
+ struct rte_mbuf *mbuf)
+{
+ uint32_t val = 0;
+ struct vmxnet3_cmd_ring *ring = &rxq->cmd_ring[ring_id];
+ struct Vmxnet3_RxDesc *rxd =
+ (struct Vmxnet3_RxDesc *)(ring->base + ring->next2fill);
+ vmxnet3_buf_info_t *buf_info = &ring->buf_info[ring->next2fill];
+
+ if (ring_id == 0)
+ val = VMXNET3_RXD_BTYPE_HEAD;
+ else
+ val = VMXNET3_RXD_BTYPE_BODY;
+
+ buf_info->m = mbuf;
+ buf_info->len = (uint16_t)(mbuf->buf_len - RTE_PKTMBUF_HEADROOM);
+ buf_info->bufPA = rte_mbuf_data_dma_addr_default(mbuf);
+
+ rxd->addr = buf_info->bufPA;
+ rxd->btype = val;
+ rxd->len = buf_info->len;
+ rxd->gen = ring->gen;
+
+ vmxnet3_cmd_ring_adv_next2fill(ring);
+}
/*
* Allocates mbufs and clusters. Post rx descriptors with buffer details
* so that device can receive packets in those buffers.
@@ -657,9 +683,17 @@
}
while (rcd->gen == rxq->comp_ring.gen) {
+ struct rte_mbuf *newm;
if (nb_rx >= nb_pkts)
break;
+ newm = rte_mbuf_raw_alloc(rxq->mp);
+ if (unlikely(newm == NULL)) {
+ PMD_RX_LOG(ERR, "Error allocating mbuf");
+ rxq->stats.rx_buf_alloc_failure++;
+ break;
+ }
+
idx = rcd->rxdIdx;
ring_idx = (uint8_t)((rcd->rqID == rxq->qid1) ? 0 : 1);
rxd = (Vmxnet3_RxDesc *)rxq->cmd_ring[ring_idx].base + idx;
@@ -759,8 +793,8 @@
VMXNET3_INC_RING_IDX_ONLY(rxq->cmd_ring[ring_idx].next2comp,
rxq->cmd_ring[ring_idx].size);
- /* It's time to allocate some new buf and renew descriptors */
- vmxnet3_post_rx_bufs(rxq, ring_idx);
+ /* It's time to renew descriptors */
+ vmxnet3_renew_desc(rxq, ring_idx, newm);
if (unlikely(rxq->shared->ctrl.updateRxProd)) {
VMXNET3_WRITE_BAR0_REG(hw, rxprod_reg[ring_idx] +
(rxq->queue_id * VMXNET3_REG_ALIGN),
rxq->cmd_ring[ring_idx].next2fill);
--
1.9.1
[dpdk-dev] [PATCH] vmxnet3: fix Rx deadlock
Our use case is that we have an app that needs to keep mbufs around
for a while. We've seen cases when calling vmxnet3_post_rx_bufs() from
vmxet3_recv_pkts(), it might not succeed to add any mbufs to any RX
descriptors (where it returns -err). Since there are no mbufs that the
virtual hardware can use, and since nobody calls
vmxnet3_post_rx_bufs() after that, no packets will be received after
this. I call this a deadlock for lack of a better term - the virtual
HW waits for free mbufs, while the app waits for the hardware to
notify it for data. Note that after this, the app can't recover.
This fix is a rework of this patch by Marco Lee:
http://dpdk.org/dev/patchwork/patch/6575/. I had to forward port it,
address review comments and also reverted the allocation failure
handing to the first version of the patch
(http://dpdk.org/ml/archives/dev/2015-July/022079.html), since that's
the only approach that seems to work, and seems to be what other
drivers are doing (I checked ixgbe and em). Reusing the mbuf that's
getting passed to the application doesn't seem to make sense, and it
was causing weird issues in our app. Also, reusing rxm without
checking if it's NULL could cause the code to crash.
---
drivers/net/vmxnet3/vmxnet3_rxtx.c | 38 --
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c
b/drivers/net/vmxnet3/vmxnet3_rxtx.c
index b109168..c9d2488 100644
--- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
+++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
@@ -518,6 +518,32 @@ vmxnet3_xmit_pkts(void *tx_queue, struct rte_mbuf
**tx_pkts,
return nb_tx;
}
+static inline void
+vmxnet3_renew_desc(vmxnet3_rx_queue_t *rxq, uint8_t ring_id,
+ struct rte_mbuf *mbuf)
+{
+ uint32_t val = 0;
+ struct vmxnet3_cmd_ring *ring = &rxq->cmd_ring[ring_id];
+ struct Vmxnet3_RxDesc *rxd =
+ (struct Vmxnet3_RxDesc *)(ring->base + ring->next2fill);
+ vmxnet3_buf_info_t *buf_info = &ring->buf_info[ring->next2fill];
+
+ if (ring_id == 0)
+ val = VMXNET3_RXD_BTYPE_HEAD;
+ else
+ val = VMXNET3_RXD_BTYPE_BODY;
+
+ buf_info->m = mbuf;
+ buf_info->len = (uint16_t)(mbuf->buf_len - RTE_PKTMBUF_HEADROOM);
+ buf_info->bufPA = rte_mbuf_data_dma_addr_default(mbuf);
+
+ rxd->addr = buf_info->bufPA;
+ rxd->btype = val;
+ rxd->len = buf_info->len;
+ rxd->gen = ring->gen;
+
+ vmxnet3_cmd_ring_adv_next2fill(ring);
+}
/*
* Allocates mbufs and clusters. Post rx descriptors with buffer details
* so that device can receive packets in those buffers.
@@ -657,9 +683,17 @@ vmxnet3_recv_pkts(void *rx_queue, struct rte_mbuf
**rx_pkts, uint16_t nb_pkts)
}
while (rcd->gen == rxq->comp_ring.gen) {
+ struct rte_mbuf *newm;
if (nb_rx >= nb_pkts)
break;
+ newm = rte_mbuf_raw_alloc(rxq->mp);
+ if (unlikely(newm == NULL)) {
+ PMD_RX_LOG(ERR, "Error allocating mbuf");
+ rxq->stats.rx_buf_alloc_failure++;
+ break;
+ }
+
idx = rcd->rxdIdx;
ring_idx = (uint8_t)((rcd->rqID == rxq->qid1) ? 0 : 1);
rxd = (Vmxnet3_RxDesc *)rxq->cmd_ring[ring_idx].base + idx;
@@ -759,8 +793,8 @@ rcd_done:
VMXNET3_INC_RING_IDX_ONLY(rxq->cmd_ring[ring_idx].next2comp,
rxq->cmd_ring[ring_idx].size);
- /* It's time to allocate some new buf and renew descriptors */
- vmxnet3_post_rx_bufs(rxq, ring_idx);
+ /* It's time to renew descriptors */
+ vmxnet3_renew_desc(rxq, ring_idx, newm);
if (unlikely(rxq->shared->ctrl.updateRxProd)) {
VMXNET3_WRITE_BAR0_REG(hw, rxprod_reg[ring_idx] +
(rxq->queue_id * VMXNET3_REG_ALIGN),
rxq->cmd_ring[ring_idx].next2fill);
--
1.9.1
[dpdk-dev] [PATCH v1] doc: add template release notes for 17.02
Add template release notes for DPDK 17.02 with inline comments and explanations of the various sections. Signed-off-by: John McNamara --- doc/guides/rel_notes/index.rst | 1 + doc/guides/rel_notes/release_17_02.rst | 223 + 2 files changed, 224 insertions(+) create mode 100644 doc/guides/rel_notes/release_17_02.rst diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst index 7e51b2c..cf8f167 100644 --- a/doc/guides/rel_notes/index.rst +++ b/doc/guides/rel_notes/index.rst @@ -36,6 +36,7 @@ Release Notes :numbered: rel_description +release_17_02 release_16_11 release_16_07 release_16_04 diff --git a/doc/guides/rel_notes/release_17_02.rst b/doc/guides/rel_notes/release_17_02.rst new file mode 100644 index 000..d251752 --- /dev/null +++ b/doc/guides/rel_notes/release_17_02.rst @@ -0,0 +1,223 @@ +DPDK Release 17.02 +== + +.. **Read this first.** + + The text below explains how to update the release notes. + + Use proper spelling, capitalization and punctuation in all sections. + + Variable and config names should be quoted as fixed width text: ``LIKE_THIS``. + + Build the docs and view the output file to ensure the changes are correct:: + + make doc-guides-html + + firefox build/doc/html/guides/rel_notes/release_17_02.html + + +New Features + + +.. This section should contain new features added in this release. Sample format: + + * **Add a title in the past tense with a full stop.** + + Add a short 1-2 sentence description in the past tense. The description + should be enough to allow someone scanning the release notes to understand + the new feature. + + If the feature adds a lot of sub-features you can use a bullet list like this. + + * Added feature foo to do something. + * Enhanced feature bar to do something else. + + Refer to the previous release notes for examples. + + This section is a comment. do not overwrite or remove it. + Also, make sure to start the actual text at the margin. + = + + +Resolved Issues +--- + +.. This section should contain bug fixes added to the relevant sections. Sample format: + + * **code/section Fixed issue in the past tense with a full stop.** + + Add a short 1-2 sentence description of the resolved issue in the past tense. + The title should contain the code/lib section like a commit message. + Add the entries in alphabetic order in the relevant sections below. + + This section is a comment. do not overwrite or remove it. + Also, make sure to start the actual text at the margin. + = + + +EAL +~~~ + + +Drivers +~~~ + + +Libraries +~ + + +Examples + + + +Other +~ + + +Known Issues + + +.. This section should contain new known issues in this release. Sample format: + + * **Add title in present tense with full stop.** + + Add a short 1-2 sentence description of the known issue in the present + tense. Add information on any known workarounds. + + This section is a comment. do not overwrite or remove it. + Also, make sure to start the actual text at the margin. + = + + +API Changes +--- + +.. This section should contain API changes. Sample format: + + * Add a short 1-2 sentence description of the API change. Use fixed width + quotes for ``rte_function_names`` or ``rte_struct_names``. Use the past tense. + + This section is a comment. do not overwrite or remove it. + Also, make sure to start the actual text at the margin. + = + + +ABI Changes +--- + +.. This section should contain ABI changes. Sample format: + + * Add a short 1-2 sentence description of the ABI change that was announced in + the previous releases and made in this release. Use fixed width quotes for + ``rte_function_names`` or ``rte_struct_names``. Use the past tense. + + This section is a comment. do not overwrite or remove it. + Also, make sure to start the actual text at the margin. + = + + + +Shared Library Versions +--- + +.. Update any library version updated in this release and prepend with a ``+`` + sign, like this: + + librte_acl.so.2 + + librte_cfgfile.so.2 + librte_cmdline.so.2 + + This section is a comment. do not overwrite or remove it. + = + + +The libraries prepended with a plus sign were incremented in this version. + +.. code-block:: diff + + librte_acl.so.2 + librte_cfgfile.so.2 + librte_cmdline.so.2 + librte_cryptodev.so.2 + librte_distributor.so.1 + librte_eal.so.3 + librte_ethdev.so.
[dpdk-dev] [PATCH] lib/librte_mempool: a redundant word in comment
From: zhao wei
There is a redundant repetition word "for" in commnet line the
file rte_mempool.h after the definition of RTE_MEMPOOL_OPS_NAMESIZE.
The word "for"appear twice in line 359 and 360.One of them is
redundant, so delete it.
Fixes: 449c49b93a6b ("lib/librte_mempool: mempool: support handler
operations")
Signed-off-by: zhao wei
---
lib/librte_mempool/rte_mempool.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 440f3b1..911102b 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -357,7 +357,7 @@ void rte_mempool_check_cookies(const struct rte_mempool *mp,
* Prototype for implementation specific data provisioning function.
*
* The function should provide the implementation specific memory for
- * for use by the other mempool ops functions in a given mempool ops struct.
+ * use by the other mempool ops functions in a given mempool ops struct.
* E.g. the default ops provides an instance of the rte_ring for this purpose.
* it will most likely point to a different type of data structure, and
* will be transparent to the application programmer.
--
2.5.5
[dpdk-dev] [PATCH] lib/librte_mempool: a redundant word in comment
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wei Zhao
> Sent: Monday, November 14, 2016 2:47 AM
> To: dev at dpdk.org
> Cc: olivier.matz at 6wind.com; Zhao1, Wei
> Subject: [dpdk-dev] [PATCH] lib/librte_mempool: a redundant word in
> comment
>
> From: zhao wei
I think you need to add your name to gitconfig file on the sending machine
to avoid this "From:"
>
> There is a redundant repetition word "for" in commnet line the file
> rte_mempool.h after the definition of RTE_MEMPOOL_OPS_NAMESIZE.
> The word "for"appear twice in line 359 and 360.One of them is redundant,
> so delete it.
>
> Fixes: 449c49b93a6b ("lib/librte_mempool: mempool: support handler
> operations")
>
> Signed-off-by: zhao wei
/commnet/comment/
And same comment as before about the title. Apart from that:
Acked-by: John McNamara
[dpdk-dev] [PATCH] lib/librte_mempool: a redundant of socket_id assignment
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wei Zhao
> Sent: Monday, November 14, 2016 2:16 AM
> To: dev at dpdk.org
> Cc: olivier.matz at 6wind.com; Zhao1, Wei
> Subject: [dpdk-dev] [PATCH] lib/librte_mempool: a redundant of socket_id
> assignment
>
> From: zhao wei
>
> There is a redundant repetition mempool socket_id assignment in the file
> rte_mempool.c in function rte_mempool_create_empty.The statement "mp-
> >socket_id = socket_id;"appear twice in line 821 and 824.One of them is
> redundant, so delete it.
>
> Fixes: 85226f9c526b ("lib/librte_mempool: mempool:introduce a function to
> create an empty pool")
>
> Signed-off-by: zhao wei
Titles should generally start with a verb to indicate what is being done.
Something like:
lib/librte_mempool: remove redundant socket_id assignment
Apart from that.
Acked-by: John McNamara
[dpdk-dev] [PATCH] lib/librte_mempool: a redundant of socket_id assignment
From: zhao wei
There is a redundant repetition mempool socket_id assignment in the
file rte_mempool.c in function rte_mempool_create_empty.The
statement "mp->socket_id = socket_id;"appear twice in line 821
and 824.One of them is redundant, so delete it.
Fixes: 85226f9c526b ("lib/librte_mempool: mempool:introduce
a function to create an empty pool")
Signed-off-by: zhao wei
---
lib/librte_mempool/rte_mempool.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index aa513b9..1c2aed8 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -818,7 +818,6 @@ rte_mempool_create_empty(const char *name, unsigned n,
unsigned elt_size,
goto exit_unlock;
}
mp->mz = mz;
- mp->socket_id = socket_id;
mp->size = n;
mp->flags = flags;
mp->socket_id = socket_id;
--
2.5.5
[dpdk-dev] Clarification for eth_driver changes
On Fri, Nov 11, 2016 at 8:16 PM, Ferruh Yigit wrote: > On 11/10/2016 11:05 AM, Shreyansh Jain wrote: >> On Thursday 10 November 2016 01:46 PM, David Marchand wrote: >>> Do we really need to keep a eth_driver ? >> >> No. As you have rightly mentioned below (as well as in your Jan'16 >> post), it is a mere convenience. > > Isn't it good to separate the logic related which bus device connected > and what functionality it provides. Because these two can be flexible: > > device -> virtual_bus -> ethernet_functionality > device -> pci_bus -> crypto_functionality > device -> x_bus -> y_function "a device is linked to a bus" (fine) "a bus knows what a device does" (?!) Not sure I follow you. -- David Marchand
[dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler
On Mon, Nov 14, 2016 at 02:29:24AM +0530, Jerin Jacob wrote:
> On Fri, Nov 11, 2016 at 10:34:39AM +, Hemant Agrawal wrote:
> > Hi Neil,
> >Pmdinfogen compiles with host compiler. It usages
> > rte_byteorder.h of the target platform.
> > However, if the host compiler is older than 4.8, it will be an issue during
> > cross compilation for some platforms.
> > e.g. if we are compiling on x86 host for ARM, x86 host compiler will not
> > understand the arm asm instructions.
> >
> > /* fix missing __builtin_bswap16 for gcc older then 4.8 */
> > #if !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
> > static inline uint16_t rte_arch_bswap16(uint16_t _x)
> > {
> >register uint16_t x = _x;
> >asm volatile ("rev16 %0,%1"
> > : "=r" (x)
> > : "r" (x)
> > );
> >return x;
> > }
> > #endif
> >
> > One easy solution is that we add compiler platform check in this code
> > section of rte_byteorder.h
> > e.g
> > #if !(defined __arm__ || defined __aarch64__)
> > static inline uint16_t rte_arch_bswap16(uint16_t _x)
> > {
> >return (_x >> 8) | ((_x << 8) & 0xff00);
> > }
> > #else ?.
> >
> > Is there a better way to fix it?
>
> IMO, It is a HOST build infrastructure issue. If a host app is using the
> dpdk service then it should compile and link against HOST target(in this
> specific case, build/x86_64-native-linuxapp-gcc). I think, introducing the
> HOSTTARGET kind of scheme is a clean solution.
>
> /Jerin
>
>
That would be accurate. That is to say, pmdinfogen is a tool that should only
be run on the host doing the build, by the host doing the build, and so should
be compiled to run on the host, not on the target being built for.
Yeah, so what we need is a way to get to the host version of rte_byteorder.h
when building in a cross environment
Neil
[dpdk-dev] [PATCH 2/2] net: align ethdev and eal driver names
Hello Ferruh, On Thu, Nov 10, 2016 at 7:46 PM, Ferruh Yigit wrote: > On 11/10/2016 1:51 PM, David Marchand wrote: >> Some virtual pmds report a different name than the vdev driver name >> registered in eal. >> While it does not hurt, let's try to be consistent. >> >> Signed-off-by: David Marchand >> --- > > Since you did all the work, instead of second patch what do you think > doing something like [1] (basically adding eth_dev->rte_driver link) and > when done for all vdevs, remove eth_dev->data->drv_name completely? Hum, in the end, it is better to wait for Shreyansh 17.02 patches. Either I will rebase this patchset, or it won't be necessary anymore. -- David Marchand
[dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler
On Fri, Nov 11, 2016 at 10:34:39AM +, Hemant Agrawal wrote:
> Hi Neil,
>Pmdinfogen compiles with host compiler. It usages
> rte_byteorder.h of the target platform.
> However, if the host compiler is older than 4.8, it will be an issue during
> cross compilation for some platforms.
> e.g. if we are compiling on x86 host for ARM, x86 host compiler will not
> understand the arm asm instructions.
>
> /* fix missing __builtin_bswap16 for gcc older then 4.8 */
> #if !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
> static inline uint16_t rte_arch_bswap16(uint16_t _x)
> {
>register uint16_t x = _x;
>asm volatile ("rev16 %0,%1"
> : "=r" (x)
> : "r" (x)
> );
>return x;
> }
> #endif
>
> One easy solution is that we add compiler platform check in this code section
> of rte_byteorder.h
> e.g
> #if !(defined __arm__ || defined __aarch64__)
> static inline uint16_t rte_arch_bswap16(uint16_t _x)
> {
>return (_x >> 8) | ((_x << 8) & 0xff00);
> }
> #else ?.
>
> Is there a better way to fix it?
IMO, It is a HOST build infrastructure issue. If a host app is using the
dpdk service then it should compile and link against HOST target(in this
specific case, build/x86_64-native-linuxapp-gcc). I think, introducing the
HOSTTARGET kind of scheme is a clean solution.
/Jerin
