* [PATCH v7 4/7] vhost: use last avail idx for avail ring reservation
From: Yuanhan Liu @ 2016-10-14 9:34 UTC (permalink / raw)
To: dev; +Cc: Maxime Coquelin, Yuanhan Liu, Zhihong Wang
In-Reply-To: <1476437678-7102-1-git-send-email-yuanhan.liu@linux.intel.com>
shadow_used_ring will be introduced later. Since then last avail
idx will not be updated together with last used idx.
So, here we use last_avail_idx for avail ring reservation.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Zhihong Wang <zhihong.wang@intel.com>
---
lib/librte_vhost/virtio_net.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
index 1a40c91..b5ba633 100644
--- a/lib/librte_vhost/virtio_net.c
+++ b/lib/librte_vhost/virtio_net.c
@@ -344,7 +344,7 @@ reserve_avail_buf_mergeable(struct vhost_virtqueue *vq, uint32_t size,
uint32_t vec_idx = 0;
uint16_t tries = 0;
- cur_idx = vq->last_used_idx;
+ cur_idx = vq->last_avail_idx;
while (1) {
avail_idx = *((volatile uint16_t *)&vq->avail->idx);
@@ -370,7 +370,7 @@ reserve_avail_buf_mergeable(struct vhost_virtqueue *vq, uint32_t size,
return -1;
}
- *num_buffers = cur_idx - vq->last_used_idx;
+ *num_buffers = cur_idx - vq->last_avail_idx;
return 0;
}
@@ -536,6 +536,7 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t queue_id,
vhost_log_used_vring(dev, vq, offsetof(struct vring_used, idx),
sizeof(vq->used->idx));
vq->last_used_idx += num_buffers;
+ vq->last_avail_idx += num_buffers;
}
if (likely(pkt_idx)) {
--
1.9.0
^ permalink raw reply related
* [PATCH v7 5/7] vhost: shadow used ring update
From: Yuanhan Liu @ 2016-10-14 9:34 UTC (permalink / raw)
To: dev; +Cc: Maxime Coquelin, Zhihong Wang, Yuanhan Liu
In-Reply-To: <1476437678-7102-1-git-send-email-yuanhan.liu@linux.intel.com>
From: Zhihong Wang <zhihong.wang@intel.com>
The basic idea is to shadow the used ring update: update them into a
local buffer first, and then flush them all to the virtio used vring
at once in the end.
And since we do avail ring reservation before enqueuing data, we would
know which and how many descs will be used. Which means we could update
the shadow used ring at the reservation time. It also introduce another
slight advantage: we don't need access the desc->flag any more inside
copy_mbuf_to_desc_mergeable().
Signed-off-by: Zhihong Wang <zhihong.wang@intel.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
---
lib/librte_vhost/vhost.c | 13 +++-
lib/librte_vhost/vhost.h | 3 +
lib/librte_vhost/vhost_user.c | 23 +++++--
lib/librte_vhost/virtio_net.c | 138 +++++++++++++++++++++++++-----------------
4 files changed, 113 insertions(+), 64 deletions(-)
diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
index 469117a..d8116ff 100644
--- a/lib/librte_vhost/vhost.c
+++ b/lib/librte_vhost/vhost.c
@@ -121,9 +121,18 @@ static void
free_device(struct virtio_net *dev)
{
uint32_t i;
+ struct vhost_virtqueue *rxq, *txq;
- for (i = 0; i < dev->virt_qp_nb; i++)
- rte_free(dev->virtqueue[i * VIRTIO_QNUM]);
+ for (i = 0; i < dev->virt_qp_nb; i++) {
+ rxq = dev->virtqueue[i * VIRTIO_QNUM + VIRTIO_RXQ];
+ txq = dev->virtqueue[i * VIRTIO_QNUM + VIRTIO_TXQ];
+
+ rte_free(rxq->shadow_used_ring);
+ rte_free(txq->shadow_used_ring);
+
+ /* rxq and txq are allocated together as queue-pair */
+ rte_free(rxq);
+ }
rte_free(dev);
}
diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
index 17c557f..acec772 100644
--- a/lib/librte_vhost/vhost.h
+++ b/lib/librte_vhost/vhost.h
@@ -105,6 +105,9 @@ struct vhost_virtqueue {
uint16_t last_zmbuf_idx;
struct zcopy_mbuf *zmbufs;
struct zcopy_mbuf_list zmbuf_list;
+
+ struct vring_used_elem *shadow_used_ring;
+ uint16_t shadow_used_idx;
} __rte_cache_aligned;
/* Old kernels have no such macro defined */
diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
index 3074227..6b83c15 100644
--- a/lib/librte_vhost/vhost_user.c
+++ b/lib/librte_vhost/vhost_user.c
@@ -198,6 +198,15 @@ vhost_user_set_vring_num(struct virtio_net *dev,
}
}
+ vq->shadow_used_ring = rte_malloc(NULL,
+ vq->size * sizeof(struct vring_used_elem),
+ RTE_CACHE_LINE_SIZE);
+ if (!vq->shadow_used_ring) {
+ RTE_LOG(ERR, VHOST_CONFIG,
+ "failed to allocate memory for shadow used ring.\n");
+ return -1;
+ }
+
return 0;
}
@@ -711,6 +720,8 @@ static int
vhost_user_get_vring_base(struct virtio_net *dev,
struct vhost_vring_state *state)
{
+ struct vhost_virtqueue *vq = dev->virtqueue[state->index];
+
/* We have to stop the queue (virtio) if it is running. */
if (dev->flags & VIRTIO_DEV_RUNNING) {
dev->flags &= ~VIRTIO_DEV_RUNNING;
@@ -718,7 +729,7 @@ vhost_user_get_vring_base(struct virtio_net *dev,
}
/* Here we are safe to get the last used index */
- state->num = dev->virtqueue[state->index]->last_used_idx;
+ state->num = vq->last_used_idx;
RTE_LOG(INFO, VHOST_CONFIG,
"vring base idx:%d file:%d\n", state->index, state->num);
@@ -727,13 +738,15 @@ vhost_user_get_vring_base(struct virtio_net *dev,
* sent and only sent in vhost_vring_stop.
* TODO: cleanup the vring, it isn't usable since here.
*/
- if (dev->virtqueue[state->index]->kickfd >= 0)
- close(dev->virtqueue[state->index]->kickfd);
+ if (vq->kickfd >= 0)
+ close(vq->kickfd);
- dev->virtqueue[state->index]->kickfd = VIRTIO_UNINITIALIZED_EVENTFD;
+ vq->kickfd = VIRTIO_UNINITIALIZED_EVENTFD;
if (dev->dequeue_zero_copy)
- free_zmbufs(dev->virtqueue[state->index]);
+ free_zmbufs(vq);
+ rte_free(vq->shadow_used_ring);
+ vq->shadow_used_ring = NULL;
return 0;
}
diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
index b5ba633..2bdc2fe 100644
--- a/lib/librte_vhost/virtio_net.c
+++ b/lib/librte_vhost/virtio_net.c
@@ -91,6 +91,56 @@ is_valid_virt_queue_idx(uint32_t idx, int is_tx, uint32_t qp_nb)
return (is_tx ^ (idx & 1)) == 0 && idx < qp_nb * VIRTIO_QNUM;
}
+static inline void __attribute__((always_inline))
+do_flush_shadow_used_ring(struct virtio_net *dev, struct vhost_virtqueue *vq,
+ uint16_t to, uint16_t from, uint16_t size)
+{
+ rte_memcpy(&vq->used->ring[to],
+ &vq->shadow_used_ring[from],
+ size * sizeof(struct vring_used_elem));
+ vhost_log_used_vring(dev, vq,
+ offsetof(struct vring_used, ring[to]),
+ size * sizeof(struct vring_used_elem));
+}
+
+static inline void __attribute__((always_inline))
+flush_shadow_used_ring(struct virtio_net *dev, struct vhost_virtqueue *vq)
+{
+ uint16_t used_idx = vq->last_used_idx & (vq->size - 1);
+
+ if (used_idx + vq->shadow_used_idx <= vq->size) {
+ do_flush_shadow_used_ring(dev, vq, used_idx, 0,
+ vq->shadow_used_idx);
+ } else {
+ uint16_t size;
+
+ /* update used ring interval [used_idx, vq->size] */
+ size = vq->size - used_idx;
+ do_flush_shadow_used_ring(dev, vq, used_idx, 0, size);
+
+ /* update the left half used ring interval [0, left_size] */
+ do_flush_shadow_used_ring(dev, vq, 0, size,
+ vq->shadow_used_idx - size);
+ }
+ vq->last_used_idx += vq->shadow_used_idx;
+
+ rte_smp_wmb();
+
+ *(volatile uint16_t *)&vq->used->idx += vq->shadow_used_idx;
+ vhost_log_used_vring(dev, vq, offsetof(struct vring_used, idx),
+ sizeof(vq->used->idx));
+}
+
+static inline void __attribute__((always_inline))
+update_shadow_used_ring(struct vhost_virtqueue *vq,
+ uint16_t desc_idx, uint16_t len)
+{
+ uint16_t i = vq->shadow_used_idx++;
+
+ vq->shadow_used_ring[i].id = desc_idx;
+ vq->shadow_used_ring[i].len = len;
+}
+
static void
virtio_enqueue_offload(struct rte_mbuf *m_buf, struct virtio_net_hdr *net_hdr)
{
@@ -300,15 +350,16 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t queue_id,
return count;
}
-static inline int
+static inline int __attribute__((always_inline))
fill_vec_buf(struct vhost_virtqueue *vq, uint32_t avail_idx,
- uint32_t *allocated, uint32_t *vec_idx,
- struct buf_vector *buf_vec)
+ uint32_t *vec_idx, struct buf_vector *buf_vec,
+ uint16_t *desc_chain_head, uint16_t *desc_chain_len)
{
uint16_t idx = vq->avail->ring[avail_idx & (vq->size - 1)];
uint32_t vec_id = *vec_idx;
- uint32_t len = *allocated;
+ uint32_t len = 0;
+ *desc_chain_head = idx;
while (1) {
if (unlikely(vec_id >= BUF_VECTOR_MAX || idx >= vq->size))
return -1;
@@ -325,8 +376,8 @@ fill_vec_buf(struct vhost_virtqueue *vq, uint32_t avail_idx,
idx = vq->desc[idx].next;
}
- *allocated = len;
- *vec_idx = vec_id;
+ *desc_chain_len = len;
+ *vec_idx = vec_id;
return 0;
}
@@ -340,26 +391,30 @@ reserve_avail_buf_mergeable(struct vhost_virtqueue *vq, uint32_t size,
{
uint16_t cur_idx;
uint16_t avail_idx;
- uint32_t allocated = 0;
uint32_t vec_idx = 0;
uint16_t tries = 0;
- cur_idx = vq->last_avail_idx;
+ uint16_t head_idx = 0;
+ uint16_t len = 0;
- while (1) {
+ *num_buffers = 0;
+ cur_idx = vq->last_avail_idx;
+
+ while (size > 0) {
avail_idx = *((volatile uint16_t *)&vq->avail->idx);
if (unlikely(cur_idx == avail_idx))
return -1;
- if (unlikely(fill_vec_buf(vq, cur_idx, &allocated,
- &vec_idx, buf_vec) < 0))
+ if (unlikely(fill_vec_buf(vq, cur_idx, &vec_idx, buf_vec,
+ &head_idx, &len) < 0))
return -1;
+ len = RTE_MIN(len, size);
+ update_shadow_used_ring(vq, head_idx, len);
+ size -= len;
cur_idx++;
tries++;
-
- if (allocated >= size)
- break;
+ *num_buffers += 1;
/*
* if we tried all available ring items, and still
@@ -370,25 +425,19 @@ reserve_avail_buf_mergeable(struct vhost_virtqueue *vq, uint32_t size,
return -1;
}
- *num_buffers = cur_idx - vq->last_avail_idx;
return 0;
}
static inline int __attribute__((always_inline))
-copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq,
- struct rte_mbuf *m, struct buf_vector *buf_vec,
- uint16_t num_buffers)
+copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct rte_mbuf *m,
+ struct buf_vector *buf_vec, uint16_t num_buffers)
{
struct virtio_net_hdr_mrg_rxbuf virtio_hdr = {{0, 0, 0, 0, 0, 0}, 0};
uint32_t vec_idx = 0;
- uint16_t cur_idx = vq->last_used_idx;
uint64_t desc_addr;
- uint32_t desc_chain_head;
- uint32_t desc_chain_len;
uint32_t mbuf_offset, mbuf_avail;
uint32_t desc_offset, desc_avail;
uint32_t cpy_len;
- uint16_t desc_idx, used_idx;
uint64_t hdr_addr, hdr_phys_addr;
struct rte_mbuf *hdr_mbuf;
@@ -409,34 +458,17 @@ copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq,
virtio_hdr.num_buffers = num_buffers;
LOG_DEBUG(VHOST_DATA, "(%d) RX: num merge buffers %d\n",
- dev->vid, virtio_hdr.num_buffers);
+ dev->vid, num_buffers);
desc_avail = buf_vec[vec_idx].buf_len - dev->vhost_hlen;
desc_offset = dev->vhost_hlen;
- desc_chain_head = buf_vec[vec_idx].desc_idx;
- desc_chain_len = desc_offset;
mbuf_avail = rte_pktmbuf_data_len(m);
mbuf_offset = 0;
while (mbuf_avail != 0 || m->next != NULL) {
/* done with current desc buf, get the next one */
if (desc_avail == 0) {
- desc_idx = buf_vec[vec_idx].desc_idx;
vec_idx++;
-
- if (!(vq->desc[desc_idx].flags & VRING_DESC_F_NEXT)) {
- /* Update used ring with desc information */
- used_idx = cur_idx++ & (vq->size - 1);
- vq->used->ring[used_idx].id = desc_chain_head;
- vq->used->ring[used_idx].len = desc_chain_len;
- vhost_log_used_vring(dev, vq,
- offsetof(struct vring_used,
- ring[used_idx]),
- sizeof(vq->used->ring[used_idx]));
- desc_chain_head = buf_vec[vec_idx].desc_idx;
- desc_chain_len = 0;
- }
-
desc_addr = gpa_to_vva(dev, buf_vec[vec_idx].buf_addr);
if (unlikely(!desc_addr))
return -1;
@@ -478,16 +510,8 @@ copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq,
mbuf_offset += cpy_len;
desc_avail -= cpy_len;
desc_offset += cpy_len;
- desc_chain_len += cpy_len;
}
- used_idx = cur_idx & (vq->size - 1);
- vq->used->ring[used_idx].id = desc_chain_head;
- vq->used->ring[used_idx].len = desc_chain_len;
- vhost_log_used_vring(dev, vq,
- offsetof(struct vring_used, ring[used_idx]),
- sizeof(vq->used->ring[used_idx]));
-
return 0;
}
@@ -515,6 +539,7 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t queue_id,
if (count == 0)
return 0;
+ vq->shadow_used_idx = 0;
for (pkt_idx = 0; pkt_idx < count; pkt_idx++) {
uint32_t pkt_len = pkts[pkt_idx]->pkt_len + dev->vhost_hlen;
@@ -523,23 +548,22 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t queue_id,
LOG_DEBUG(VHOST_DATA,
"(%d) failed to get enough desc from vring\n",
dev->vid);
+ vq->shadow_used_idx -= num_buffers;
break;
}
- if (copy_mbuf_to_desc_mergeable(dev, vq, pkts[pkt_idx],
- buf_vec, num_buffers) < 0)
+ if (copy_mbuf_to_desc_mergeable(dev, pkts[pkt_idx],
+ buf_vec, num_buffers) < 0) {
+ vq->shadow_used_idx -= num_buffers;
break;
+ }
- rte_smp_wmb();
-
- *(volatile uint16_t *)&vq->used->idx += num_buffers;
- vhost_log_used_vring(dev, vq, offsetof(struct vring_used, idx),
- sizeof(vq->used->idx));
- vq->last_used_idx += num_buffers;
vq->last_avail_idx += num_buffers;
}
- if (likely(pkt_idx)) {
+ if (likely(vq->shadow_used_idx)) {
+ flush_shadow_used_ring(dev, vq);
+
/* flush used->idx update before we read avail->flags. */
rte_mb();
--
1.9.0
^ permalink raw reply related
* [PATCH v7 7/7] vhost: retrieve avail head once
From: Yuanhan Liu @ 2016-10-14 9:34 UTC (permalink / raw)
To: dev; +Cc: Maxime Coquelin, Yuanhan Liu, Zhihong Wang
In-Reply-To: <1476437678-7102-1-git-send-email-yuanhan.liu@linux.intel.com>
There is no need to retrieve the latest avail head every time we enqueue
a packet in the mereable Rx path by
avail_idx = *((volatile uint16_t *)&vq->avail->idx);
Instead, we could just retrieve it once at the beginning of the enqueue
path. This could diminish the cache penalty slightly, because the virtio
driver could be updating it while vhost is reading it (for each packet).
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Zhihong Wang <zhihong.wang@intel.com>
---
lib/librte_vhost/virtio_net.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
index 12a037b..b784dba 100644
--- a/lib/librte_vhost/virtio_net.c
+++ b/lib/librte_vhost/virtio_net.c
@@ -387,10 +387,10 @@ fill_vec_buf(struct vhost_virtqueue *vq, uint32_t avail_idx,
*/
static inline int
reserve_avail_buf_mergeable(struct vhost_virtqueue *vq, uint32_t size,
- struct buf_vector *buf_vec, uint16_t *num_buffers)
+ struct buf_vector *buf_vec, uint16_t *num_buffers,
+ uint16_t avail_head)
{
uint16_t cur_idx;
- uint16_t avail_idx;
uint32_t vec_idx = 0;
uint16_t tries = 0;
@@ -401,8 +401,7 @@ reserve_avail_buf_mergeable(struct vhost_virtqueue *vq, uint32_t size,
cur_idx = vq->last_avail_idx;
while (size > 0) {
- avail_idx = *((volatile uint16_t *)&vq->avail->idx);
- if (unlikely(cur_idx == avail_idx))
+ if (unlikely(cur_idx == avail_head))
return -1;
if (unlikely(fill_vec_buf(vq, cur_idx, &vec_idx, buf_vec,
@@ -523,6 +522,7 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t queue_id,
uint32_t pkt_idx = 0;
uint16_t num_buffers;
struct buf_vector buf_vec[BUF_VECTOR_MAX];
+ uint16_t avail_head;
LOG_DEBUG(VHOST_DATA, "(%d) %s\n", dev->vid, __func__);
if (unlikely(!is_valid_virt_queue_idx(queue_id, 0, dev->virt_qp_nb))) {
@@ -542,11 +542,12 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t queue_id,
rte_prefetch0(&vq->avail->ring[vq->last_avail_idx & (vq->size - 1)]);
vq->shadow_used_idx = 0;
+ avail_head = *((volatile uint16_t *)&vq->avail->idx);
for (pkt_idx = 0; pkt_idx < count; pkt_idx++) {
uint32_t pkt_len = pkts[pkt_idx]->pkt_len + dev->vhost_hlen;
if (unlikely(reserve_avail_buf_mergeable(vq, pkt_len, buf_vec,
- &num_buffers) < 0)) {
+ &num_buffers, avail_head) < 0)) {
LOG_DEBUG(VHOST_DATA,
"(%d) failed to get enough desc from vring\n",
dev->vid);
--
1.9.0
^ permalink raw reply related
* [PATCH v7 6/7] vhost: prefetch avail ring
From: Yuanhan Liu @ 2016-10-14 9:34 UTC (permalink / raw)
To: dev; +Cc: Maxime Coquelin, Yuanhan Liu, Zhihong Wang
In-Reply-To: <1476437678-7102-1-git-send-email-yuanhan.liu@linux.intel.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Zhihong Wang <zhihong.wang@intel.com>
---
lib/librte_vhost/virtio_net.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
index 2bdc2fe..12a037b 100644
--- a/lib/librte_vhost/virtio_net.c
+++ b/lib/librte_vhost/virtio_net.c
@@ -539,6 +539,8 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t queue_id,
if (count == 0)
return 0;
+ rte_prefetch0(&vq->avail->ring[vq->last_avail_idx & (vq->size - 1)]);
+
vq->shadow_used_idx = 0;
for (pkt_idx = 0; pkt_idx < count; pkt_idx++) {
uint32_t pkt_len = pkts[pkt_idx]->pkt_len + dev->vhost_hlen;
--
1.9.0
^ permalink raw reply related
* Re: [PATCH v9] drivers/net:new PMD using tun/tap host interface
From: Ferruh Yigit @ 2016-10-14 9:39 UTC (permalink / raw)
To: Keith Wiles, dev; +Cc: pmatilai, yuanhan.liu
In-Reply-To: <1476396234-44694-1-git-send-email-keith.wiles@intel.com>
On 10/13/2016 11:03 PM, Keith Wiles wrote:
> The rte_eth_tap.c PMD creates a device using TUN/TAP interfaces
> on the local host. The PMD allows for DPDK and the host to
> communicate using a raw device interface on the host and in
> the DPDK application. The device created is a Tap device with
> a L2 packet header.
>
> v9 - Fix up the docs to use correct syntax
> v8 - Fix issue with tap_tx_queue_setup() not return zero on success.
> v7 - Reword the comment in common_base and fix the data->name issue
> v6 - fixed the checkpatch issues
> v5 - merge in changes from list review see related emails
> fixed many minor edits
> v4 - merge with latest driver changes
> v3 - fix includes by removing ifdef for other type besides Linux
> Fix the copyright notice in the Makefile
> v2 - merge all of the patches into one patch
> Fix a typo on naming the tap device
> Update the maintainers list
>
> Signed-off-by: Keith Wiles <keith.wiles@intel.com>
> ---
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply
* Re: [PATCH v3 0/5] vhost: optimize enqueue
From: Yuanhan Liu @ 2016-10-14 10:11 UTC (permalink / raw)
To: Maxime Coquelin; +Cc: Wang, Zhihong, Jianbo Liu, Thomas Monjalon, dev@dpdk.org
In-Reply-To: <570cc934-590e-8770-9853-f03a1380d181@redhat.com>
On Thu, Oct 13, 2016 at 11:23:44AM +0200, Maxime Coquelin wrote:
> I was going to re-run some PVP benchmark with 0% pkt loss, as I had
> some strange results last week.
>
> Problem is that your series no more apply cleanly due to
> next-virtio's master branch history rewrite.
> Any chance you send me a rebased version so that I can apply the series?
I think it's pointless to do that now: it won't be merged after all.
We have refactored out the new series, please help review if you
got time :)
BTW, apologize that I forgot to include your Reviewed-by for the
first patch. I intended to do that ...
--yliu
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Hemant Agrawal @ 2016-10-14 10:30 UTC (permalink / raw)
To: Jerin Jacob, Bill Fischofer
Cc: dev@dpdk.org, thomas.monjalon@6wind.com,
bruce.richardson@intel.com, narender.vangati@intel.com,
gage.eads@intel.com
In-Reply-To: <20161014092607.GA16828@localhost.localdomain>
Hi Bill/Jerin,
>
> Thanks for the review.
>
> [snip]
> > > + * If the device init operation is successful, the correspondence
> > > + between
> > > + * the device identifier assigned to the new device and its
> > > + associated
> > > + * *rte_event_dev* structure is effectively registered.
> > > + * Otherwise, both the *rte_event_dev* structure and the device
> > > identifier are
> > > + * freed.
> > > + *
> > > + * The functions exported by the application Event API to setup a
> > > + device
> > > + * designated by its device identifier must be invoked in the
> > > + following
> > > order:
> > > + * - rte_event_dev_configure()
> > > + * - rte_event_queue_setup()
> > > + * - rte_event_port_setup()
> > > + * - rte_event_port_link()
> > > + * - rte_event_dev_start()
> > > + *
> > > + * Then, the application can invoke, in any order, the functions
> > > + * exported by the Event API to schedule events, dequeue events,
> > > + enqueue
> > > events,
> > > + * change event queue(s) to event port [un]link establishment and so on.
> > > + *
> > > + * Application may use rte_event_[queue/port]_default_conf_get() to
> > > + get
> > > the
> > > + * default configuration to set up an event queue or event port by
> > > + * overriding few default values.
> > > + *
> > > + * If the application wants to change the configuration (i.e. call
> > > + * rte_event_dev_configure(), rte_event_queue_setup(), or
> > > + * rte_event_port_setup()), it must call rte_event_dev_stop() first
> > > + to
> > > stop the
> > > + * device and then do the reconfiguration before calling
> > > rte_event_dev_start()
> > > + * again. The schedule, enqueue and dequeue functions should not be
> > > invoked
> > > + * when the device is stopped.
> > >
> >
> > Given this requirement, the question is what happens to events that
> > are "in flight" at the time rte_event_dev_stop() is called? Is stop an
> > asynchronous operation that quiesces the event _dev and allows
> > in-flight events to drain from queues/ports prior to fully stopping,
> > or is some sort of separate explicit quiesce mechanism required? If
> > stop is synchronous and simply halts the event_dev, then how is an
> > application to know if subsequent configure/setup calls would leave
> > these pending events with no place to stand?
> >
>
> From an application API perspective rte_event_dev_stop() is a synchronous
> function.
> If the stop has been called for re-configuring the number of queues, ports etc of
> the device, then "in flight" entry preservation will be implementation defined.
> else "in flight" entries will be preserved.
>
> [snip]
>
> > > +extern int
> > > +rte_event_dev_socket_id(uint8_t dev_id);
> > > +
> > > +/* Event device capability bitmap flags */
> > > +#define RTE_EVENT_DEV_CAP_QUEUE_QOS (1 << 0)
> > > +/**< Event scheduling prioritization is based on the priority
> > > +associated
> > > with
> > > + * each event queue.
> > > + *
> > > + * \see rte_event_queue_setup(), RTE_EVENT_QUEUE_PRIORITY_NORMAL
> > > +*/
> > > +#define RTE_EVENT_DEV_CAP_EVENT_QOS (1 << 1)
> > > +/**< Event scheduling prioritization is based on the priority
> > > +associated
> > > with
> > > + * each event. Priority of each event is supplied in *rte_event*
> > > structure
> > > + * on each enqueue operation.
> > > + *
> > > + * \see rte_event_enqueue()
> > > + */
> > > +
> > > +/**
> > > + * Event device information
> > > + */
> > > +struct rte_event_dev_info {
> > > + const char *driver_name; /**< Event driver name */
> > > + struct rte_pci_device *pci_dev; /**< PCI information */
> > > + uint32_t min_dequeue_wait_ns;
> > > + /**< Minimum supported global dequeue wait delay(ns) by this
> > > device */
> > > + uint32_t max_dequeue_wait_ns;
> > > + /**< Maximum supported global dequeue wait delay(ns) by this
> > > device */
> > > + uint32_t dequeue_wait_ns;
> > >
> >
> > Am I reading this correctly that there is no way to support an
> > indefinite waiting capability? Or is this just saying that if a timed
> > wait is performed there are min/max limits for the wait duration?
>
> Application can wait indefinite if required. see
> RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT configuration option.
>
> Trivial application may not need different wait values on each dequeue.This is a
> performance optimization opportunity for implementation.
Jerin, It is irrespective of wait configuration, whether you are using per device wait or per dequeuer wait.
Can the value of MAX_U32 or MAX_U64 be treated as infinite weight?
>
> >
> >
> > > + /**< Configured global dequeue wait delay(ns) for this device */
> > > + uint8_t max_event_queues;
> > > + /**< Maximum event_queues supported by this device */
> > > + uint32_t max_event_queue_flows;
> > > + /**< Maximum supported flows in an event queue by this device*/
> > > + uint8_t max_event_queue_priority_levels;
> > > + /**< Maximum number of event queue priority levels by this device.
> > > + * Valid when the device has RTE_EVENT_DEV_CAP_QUEUE_QOS
> capability
> > > + */
> > > + uint8_t nb_event_queues;
> > > + /**< Configured number of event queues for this device */
> > >
> >
> > Is 256 a sufficient number of queues? While various SoCs may have
> > limits, why impose such a small limit architecturally?
>
> Each event queue potentially can support millions of flows.That way, 256 may
> not be a small limit.The reason to choose queue_id as 8bit to hold all the
> attribute of "struct rte_event" in 128bit. So that SIMD optimization is possible in
> the implementation.
>
[Hemant] 256 is not an small number of event queue. Please consider event queue as logically equivalent of a scheduler group in ODP.
> > > + /**< The maximum number of active flows this queue can track at any
> > > + * given time. The value must be in the range of
> > > + * [1 - max_event_queue_flows)] which previously supplied
> > > + * to rte_event_dev_configure().
> > > + */
> > > + uint32_t nb_atomic_order_sequences;
> > > + /**< The maximum number of outstanding events waiting to be
> > > (egress-)
> > > + * reordered by this queue. In other words, the number of
> > > + entries
> > > in
> > > + * this queue’s reorder buffer.The value must be in the range of
> > > + * [1 - max_event_queue_flows)] which previously supplied
> > > + * to rte_event_dev_configure().
> > >
> >
> > What happens if this limit is exceeded? While atomic limits are
> > bounded by the number of lcores, the same cannot be said for ordered
> queues.
> > Presumably the queue would refuse further dequeues once this limit is
> > reached until pending reorders are resolved to permit continued processing?
> > If so that should be stated explicitly.
>
> OK. I will update details.
>
> >
> >
> > > + *
> > > + *
> > > + * The device start step is the last one and consists of setting
> > > +the event
> > > + * queues to start accepting the events and schedules to event ports.
> > > + *
> > > + * On success, all basic functions exported by the API (event
> > > +enqueue,
> > > + * event dequeue and so on) can be invoked.
> > > + *
> > > + * @param dev_id
> > > + * Event device identifier
> > > + * @return
> > > + * - 0: Success, device started.
> > > + * - <0: Error code of the driver device start function.
> > > + */
> > > +extern int
> > > +rte_event_dev_start(uint8_t dev_id);
> > > +
> > > +/**
> > > + * Stop an event device. The device can be restarted with a call to
> > > + * rte_event_dev_start()
> > > + *
> > > + * @param dev_id
> > > + * Event device identifier.
> > > + */
> > > +extern void
> > > +rte_event_dev_stop(uint8_t dev_id);
> > >
> >
> > Having this be a void function implies this function cannot fail. Is
> > that assumption always correct?
>
> Yes. Subsequent rte_event_dev_start() can return error if the implementation
> really have some critical issues on starting the device.
>
> >
> >
> > > +
> > > +/**
> > > + * Close an event device. The device cannot be restarted!
> > > + *
> > > + * @param dev_id
> > > + * Event device identifier
> > > + *
> > > + * @return
> > > + * - 0 on successfully closing device
> > > + * - <0 on failure to close device */ extern int
^ permalink raw reply
* [PATCH v2 0/4] Generalize PCI specific EAL function/structures
From: Shreyansh Jain @ 2016-10-14 10:55 UTC (permalink / raw)
To: dev; +Cc: viktorin, thomas.monjalon, david.marchand, Shreyansh Jain
In-Reply-To: <1474985551-14219-1-git-send-email-shreyansh.jain@nxp.com>
(Rebased these over HEAD fed622dfd)
These patches were initially part of Jan's original series on SoC
Framework ([1],[2]). An update to that series, without these patches,
was posted here [3].
Main motivation for these is aim of introducing a non-PCI centric
subsystem in EAL. As of now the first usecase is SoC, but not limited to
it.
4 patches in this series are independent of each other, as well as SoC
framework. All these focus on generalizing some structure or functions
present with the PCI specific code to EAL Common area (or splitting a
function to be more userful).
- 0001: move the rte_kernel_driver enum from rte_pci to rte_dev. As of
now this structure is embedded in rte_pci_device, but, going ahead it
can be part of other rte_xxx_device structures. Either way, it has no
impact on PCI.
- 0002: Functions pci_map_resource/pci_unmap_resource are moved to EAL
common as rte_eal_map_resource/rte_eal_unmap_resource, respectively.
- 0003: Split the pci_unbind_kernel_driver into two, still working on
the PCI BDF sysfs layout, first handles the file path (and validations)
and second does the actual unbind. The second part might be useful in
case of non-PCI layouts.
-- This is useful for other subsystem, parallel to PCI, which require
| MMAP support.
`- an equivalent NOTSUP function for BSD has been added in v1
- 0004: Move pci_get_kernel_driver_by_path to
rte_eal_get_kernel_driver_by_path in EAL common. This function is
generic for any sysfs compliant driver and can be re-used by other
non-PCI subsystem.
`- an equivalent NOTSUP function for BSD has been added in v1
Changes since v1
- Rebased over master (fed622dfd)
- Added dummy functions for BSD for unbind and kernel driver fetch
functions (patches 003, 004)
Changes since v0 [4]:
- Fix for checkpatch and check-git-log
- Fix missing include in patch 0001
- Drop patch 2 for splitting sysfs into a sub-function taking file
handle. This patch doesn't really fit into the model of PCI->EAL
movement of generic functions which other patches relate to.
Also, taking cue from review comment [5], it might not have a
viable use-case as of now.
[1] http://dpdk.org/ml/archives/dev/2016-January/030915.html
[2] http://www.dpdk.org/ml/archives/dev/2016-May/038486.html
[3] http://dpdk.org/ml/archives/dev/2016-August/045993.html
[4] http://dpdk.org/ml/archives/dev/2016-September/046035.html
[5] http://dpdk.org/ml/archives/dev/2016-September/046041.html
Jan Viktorin (4):
eal: generalize PCI kernel driver enum to EAL
eal: generalize PCI map/unmap resource to EAL
eal/linux: generalize PCI kernel unbinding driver to EAL
eal/linux: generalize PCI kernel driver extraction to EAL
lib/librte_eal/bsdapp/eal/eal.c | 14 ++++++
lib/librte_eal/bsdapp/eal/eal_pci.c | 6 +--
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 2 +
lib/librte_eal/common/eal_common_dev.c | 39 ++++++++++++++++
lib/librte_eal/common/eal_common_pci.c | 39 ----------------
lib/librte_eal/common/eal_common_pci_uio.c | 16 ++++---
lib/librte_eal/common/eal_private.h | 27 +++++++++++
lib/librte_eal/common/include/rte_dev.h | 44 ++++++++++++++++++
lib/librte_eal/common/include/rte_pci.h | 41 ----------------
lib/librte_eal/linuxapp/eal/eal.c | 55 ++++++++++++++++++++++
lib/librte_eal/linuxapp/eal/eal_pci.c | 62 ++++---------------------
lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 2 +-
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 5 +-
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 2 +
14 files changed, 208 insertions(+), 146 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/4] eal: generalize PCI kernel driver enum to EAL
From: Shreyansh Jain @ 2016-10-14 10:55 UTC (permalink / raw)
To: dev; +Cc: viktorin, thomas.monjalon, david.marchand, Shreyansh Jain
In-Reply-To: <1476442527-30726-1-git-send-email-shreyansh.jain@nxp.com>
From: Jan Viktorin <viktorin@rehivetech.com>
Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
--
Changes since v0:
- fix compilation error due to missing include
---
lib/librte_eal/common/include/rte_dev.h | 12 ++++++++++++
lib/librte_eal/common/include/rte_pci.h | 9 ---------
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/lib/librte_eal/common/include/rte_dev.h b/lib/librte_eal/common/include/rte_dev.h
index b3873bd..e73b0fa 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -109,6 +109,18 @@ struct rte_mem_resource {
void *addr; /**< Virtual address, NULL when not mapped. */
};
+/**
+ * Kernel driver passthrough type
+ */
+enum rte_kernel_driver {
+ RTE_KDRV_UNKNOWN = 0,
+ RTE_KDRV_IGB_UIO,
+ RTE_KDRV_VFIO,
+ RTE_KDRV_UIO_GENERIC,
+ RTE_KDRV_NIC_UIO,
+ RTE_KDRV_NONE,
+};
+
/** Double linked list of device drivers. */
TAILQ_HEAD(rte_driver_list, rte_driver);
/** Double linked list of devices. */
diff --git a/lib/librte_eal/common/include/rte_pci.h b/lib/librte_eal/common/include/rte_pci.h
index 9ce8847..2c7046f 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -135,15 +135,6 @@ struct rte_pci_addr {
struct rte_devargs;
-enum rte_kernel_driver {
- RTE_KDRV_UNKNOWN = 0,
- RTE_KDRV_IGB_UIO,
- RTE_KDRV_VFIO,
- RTE_KDRV_UIO_GENERIC,
- RTE_KDRV_NIC_UIO,
- RTE_KDRV_NONE,
-};
-
/**
* A structure describing a PCI device.
*/
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/4] eal: generalize PCI map/unmap resource to EAL
From: Shreyansh Jain @ 2016-10-14 10:55 UTC (permalink / raw)
To: dev; +Cc: viktorin, thomas.monjalon, david.marchand, Shreyansh Jain
In-Reply-To: <1476442527-30726-1-git-send-email-shreyansh.jain@nxp.com>
From: Jan Viktorin <viktorin@rehivetech.com>
The functions pci_map_resource, pci_unmap_resource are generic so the
pci_* prefix can be omitted. The functions are moved to the
eal_common_dev.c so they can be reused by other infrastructure.
Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
---
lib/librte_eal/bsdapp/eal/eal_pci.c | 2 +-
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 2 ++
lib/librte_eal/common/eal_common_dev.c | 39 +++++++++++++++++++++++++
lib/librte_eal/common/eal_common_pci.c | 39 -------------------------
lib/librte_eal/common/eal_common_pci_uio.c | 16 +++++-----
lib/librte_eal/common/include/rte_dev.h | 32 ++++++++++++++++++++
lib/librte_eal/common/include/rte_pci.h | 32 --------------------
lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 2 +-
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 5 ++--
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 2 ++
10 files changed, 89 insertions(+), 82 deletions(-)
diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c b/lib/librte_eal/bsdapp/eal/eal_pci.c
index 8b3ed88..7ed0115 100644
--- a/lib/librte_eal/bsdapp/eal/eal_pci.c
+++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
@@ -228,7 +228,7 @@ pci_uio_map_resource_by_index(struct rte_pci_device *dev, int res_idx,
/* if matching map is found, then use it */
offset = res_idx * pagesz;
- mapaddr = pci_map_resource(NULL, fd, (off_t)offset,
+ mapaddr = rte_eal_map_resource(NULL, fd, (off_t)offset,
(size_t)dev->mem_resource[res_idx].len, 0);
close(fd);
if (mapaddr == MAP_FAILED)
diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index 2f81f7c..11d9f59 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -170,6 +170,8 @@ DPDK_16.11 {
rte_delay_us_callback_register;
rte_eal_dev_attach;
rte_eal_dev_detach;
+ rte_eal_map_resource;
+ rte_eal_unmap_resource;
rte_eal_vdrv_register;
rte_eal_vdrv_unregister;
diff --git a/lib/librte_eal/common/eal_common_dev.c b/lib/librte_eal/common/eal_common_dev.c
index 4f3b493..457d227 100644
--- a/lib/librte_eal/common/eal_common_dev.c
+++ b/lib/librte_eal/common/eal_common_dev.c
@@ -36,6 +36,7 @@
#include <string.h>
#include <inttypes.h>
#include <sys/queue.h>
+#include <sys/mman.h>
#include <rte_dev.h>
#include <rte_devargs.h>
@@ -151,3 +152,41 @@ err:
RTE_LOG(ERR, EAL, "Driver cannot detach the device (%s)\n", name);
return -EINVAL;
}
+
+/* map a particular resource from a file */
+void *
+rte_eal_map_resource(void *requested_addr, int fd, off_t offset, size_t size,
+ int additional_flags)
+{
+ void *mapaddr;
+
+ /* Map the Memory resource of device */
+ mapaddr = mmap(requested_addr, size, PROT_READ | PROT_WRITE,
+ MAP_SHARED | additional_flags, fd, offset);
+ if (mapaddr == MAP_FAILED) {
+ RTE_LOG(ERR, EAL, "%s(): cannot mmap(%d, %p, 0x%lx, 0x%lx): %s"
+ " (%p)\n", __func__, fd, requested_addr,
+ (unsigned long)size, (unsigned long)offset,
+ strerror(errno), mapaddr);
+ } else
+ RTE_LOG(DEBUG, EAL, " Device memory mapped at %p\n", mapaddr);
+
+ return mapaddr;
+}
+
+/* unmap a particular resource */
+void
+rte_eal_unmap_resource(void *requested_addr, size_t size)
+{
+ if (requested_addr == NULL)
+ return;
+
+ /* Unmap the Memory resource of device */
+ if (munmap(requested_addr, size)) {
+ RTE_LOG(ERR, EAL, "%s(): cannot munmap(%p, 0x%lx): %s\n",
+ __func__, requested_addr, (unsigned long)size,
+ strerror(errno));
+ } else
+ RTE_LOG(DEBUG, EAL, " Device memory unmapped at %p\n",
+ requested_addr);
+}
diff --git a/lib/librte_eal/common/eal_common_pci.c b/lib/librte_eal/common/eal_common_pci.c
index 638cd86..464acc1 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -67,7 +67,6 @@
#include <stdlib.h>
#include <stdio.h>
#include <sys/queue.h>
-#include <sys/mman.h>
#include <rte_interrupts.h>
#include <rte_log.h>
@@ -114,44 +113,6 @@ static struct rte_devargs *pci_devargs_lookup(struct rte_pci_device *dev)
return NULL;
}
-/* map a particular resource from a file */
-void *
-pci_map_resource(void *requested_addr, int fd, off_t offset, size_t size,
- int additional_flags)
-{
- void *mapaddr;
-
- /* Map the PCI memory resource of device */
- mapaddr = mmap(requested_addr, size, PROT_READ | PROT_WRITE,
- MAP_SHARED | additional_flags, fd, offset);
- if (mapaddr == MAP_FAILED) {
- RTE_LOG(ERR, EAL, "%s(): cannot mmap(%d, %p, 0x%lx, 0x%lx): %s (%p)\n",
- __func__, fd, requested_addr,
- (unsigned long)size, (unsigned long)offset,
- strerror(errno), mapaddr);
- } else
- RTE_LOG(DEBUG, EAL, " PCI memory mapped at %p\n", mapaddr);
-
- return mapaddr;
-}
-
-/* unmap a particular resource */
-void
-pci_unmap_resource(void *requested_addr, size_t size)
-{
- if (requested_addr == NULL)
- return;
-
- /* Unmap the PCI memory resource of device */
- if (munmap(requested_addr, size)) {
- RTE_LOG(ERR, EAL, "%s(): cannot munmap(%p, 0x%lx): %s\n",
- __func__, requested_addr, (unsigned long)size,
- strerror(errno));
- } else
- RTE_LOG(DEBUG, EAL, " PCI memory unmapped at %p\n",
- requested_addr);
-}
-
/*
* If vendor/device ID match, call the probe() function of the
* driver.
diff --git a/lib/librte_eal/common/eal_common_pci_uio.c b/lib/librte_eal/common/eal_common_pci_uio.c
index 367a681..3402518 100644
--- a/lib/librte_eal/common/eal_common_pci_uio.c
+++ b/lib/librte_eal/common/eal_common_pci_uio.c
@@ -75,9 +75,11 @@ pci_uio_map_secondary(struct rte_pci_device *dev)
return -1;
}
- void *mapaddr = pci_map_resource(uio_res->maps[i].addr,
- fd, (off_t)uio_res->maps[i].offset,
- (size_t)uio_res->maps[i].size, 0);
+ void *mapaddr = rte_eal_map_resource(
+ uio_res->maps[i].addr, fd,
+ (off_t)uio_res->maps[i].offset,
+ (size_t)uio_res->maps[i].size,
+ 0);
/* fd is not needed in slave process, close it */
close(fd);
if (mapaddr != uio_res->maps[i].addr) {
@@ -88,11 +90,11 @@ pci_uio_map_secondary(struct rte_pci_device *dev)
if (mapaddr != MAP_FAILED) {
/* unmap addrs correctly mapped */
for (j = 0; j < i; j++)
- pci_unmap_resource(
+ rte_eal_unmap_resource(
uio_res->maps[j].addr,
(size_t)uio_res->maps[j].size);
/* unmap addr wrongly mapped */
- pci_unmap_resource(mapaddr,
+ rte_eal_unmap_resource(mapaddr,
(size_t)uio_res->maps[i].size);
}
return -1;
@@ -150,7 +152,7 @@ pci_uio_map_resource(struct rte_pci_device *dev)
return 0;
error:
for (i = 0; i < map_idx; i++) {
- pci_unmap_resource(uio_res->maps[i].addr,
+ rte_eal_unmap_resource(uio_res->maps[i].addr,
(size_t)uio_res->maps[i].size);
rte_free(uio_res->maps[i].path);
}
@@ -167,7 +169,7 @@ pci_uio_unmap(struct mapped_pci_resource *uio_res)
return;
for (i = 0; i != uio_res->nb_maps; i++) {
- pci_unmap_resource(uio_res->maps[i].addr,
+ rte_eal_unmap_resource(uio_res->maps[i].addr,
(size_t)uio_res->maps[i].size);
if (rte_eal_process_type() == RTE_PROC_PRIMARY)
rte_free(uio_res->maps[i].path);
diff --git a/lib/librte_eal/common/include/rte_dev.h b/lib/librte_eal/common/include/rte_dev.h
index e73b0fa..277c07b 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -234,6 +234,38 @@ int rte_eal_dev_attach(const char *name, const char *devargs);
*/
int rte_eal_dev_detach(const char *name);
+/*
+ * @internal
+ * Map a particular resource from a file.
+ *
+ * @param requested_addr
+ * The starting address for the new mapping range.
+ * @param fd
+ * The file descriptor.
+ * @param offset
+ * The offset for the mapping range.
+ * @param size
+ * The size for the mapping range.
+ * @param additional_flags
+ * The additional flags for the mapping range.
+ * @return
+ * - On success, the function returns a pointer to the mapped area.
+ * - On error, the value MAP_FAILED is returned.
+ */
+void *rte_eal_map_resource(void *requested_addr, int fd, off_t offset,
+ size_t size, int additional_flags);
+
+/**
+ * @internal
+ * Unmap a particular resource.
+ *
+ * @param requested_addr
+ * The address for the unmapping range.
+ * @param size
+ * The size for the unmapping range.
+ */
+void rte_eal_unmap_resource(void *requested_addr, size_t size);
+
#define RTE_PMD_EXPORT_NAME_ARRAY(n, idx) n##idx[]
#define RTE_PMD_EXPORT_NAME(name, idx) \
diff --git a/lib/librte_eal/common/include/rte_pci.h b/lib/librte_eal/common/include/rte_pci.h
index 2c7046f..7d6eef5 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -399,38 +399,6 @@ int rte_eal_pci_map_device(struct rte_pci_device *dev);
void rte_eal_pci_unmap_device(struct rte_pci_device *dev);
/**
- * @internal
- * Map a particular resource from a file.
- *
- * @param requested_addr
- * The starting address for the new mapping range.
- * @param fd
- * The file descriptor.
- * @param offset
- * The offset for the mapping range.
- * @param size
- * The size for the mapping range.
- * @param additional_flags
- * The additional flags for the mapping range.
- * @return
- * - On success, the function returns a pointer to the mapped area.
- * - On error, the value MAP_FAILED is returned.
- */
-void *pci_map_resource(void *requested_addr, int fd, off_t offset,
- size_t size, int additional_flags);
-
-/**
- * @internal
- * Unmap a particular resource.
- *
- * @param requested_addr
- * The address for the unmapping range.
- * @param size
- * The size for the unmapping range.
- */
-void pci_unmap_resource(void *requested_addr, size_t size);
-
-/**
* Probe the single PCI device.
*
* Scan the content of the PCI bus, and find the pci device specified by pci
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
index 1786b75..5c34421 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
@@ -347,7 +347,7 @@ pci_uio_map_resource_by_index(struct rte_pci_device *dev, int res_idx,
if (pci_map_addr == NULL)
pci_map_addr = pci_find_max_end_va();
- mapaddr = pci_map_resource(pci_map_addr, fd, 0,
+ mapaddr = rte_eal_map_resource(pci_map_addr, fd, 0,
(size_t)dev->mem_resource[res_idx].len, 0);
close(fd);
if (mapaddr == MAP_FAILED)
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
index 5f478c5..5ad8cbe 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
@@ -465,7 +465,8 @@ pci_vfio_map_resource(struct rte_pci_device *dev)
void *map_addr = NULL;
if (memreg[0].size) {
/* actual map of first part */
- map_addr = pci_map_resource(bar_addr, vfio_dev_fd,
+ map_addr = rte_eal_map_resource(bar_addr,
+ vfio_dev_fd,
memreg[0].offset,
memreg[0].size,
MAP_FIXED);
@@ -477,7 +478,7 @@ pci_vfio_map_resource(struct rte_pci_device *dev)
void *second_addr = RTE_PTR_ADD(bar_addr,
memreg[1].offset -
(uintptr_t)reg.offset);
- map_addr = pci_map_resource(second_addr,
+ map_addr = rte_eal_map_resource(second_addr,
vfio_dev_fd, memreg[1].offset,
memreg[1].size,
MAP_FIXED);
diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
index 83721ba..22b5b59 100644
--- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
@@ -174,6 +174,8 @@ DPDK_16.11 {
rte_delay_us_callback_register;
rte_eal_dev_attach;
rte_eal_dev_detach;
+ rte_eal_map_resource;
+ rte_eal_unmap_resource;
rte_eal_vdrv_register;
rte_eal_vdrv_unregister;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/4] eal/linux: generalize PCI kernel unbinding driver to EAL
From: Shreyansh Jain @ 2016-10-14 10:55 UTC (permalink / raw)
To: dev; +Cc: viktorin, thomas.monjalon, david.marchand, Shreyansh Jain
In-Reply-To: <1476442527-30726-1-git-send-email-shreyansh.jain@nxp.com>
From: Jan Viktorin <viktorin@rehivetech.com>
Generalize the PCI-specific pci_unbind_kernel_driver. It is now divided
into two parts. First, determination of the path and string identification
of the device to be unbound. Second, the actual unbind operation which is
generic.
BSD implementation updated as ENOTSUP
Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
--
Changes since v1:
- update BSD support for unbind kernel driver
---
lib/librte_eal/bsdapp/eal/eal.c | 7 +++++++
lib/librte_eal/bsdapp/eal/eal_pci.c | 4 ++--
lib/librte_eal/common/eal_private.h | 13 +++++++++++++
lib/librte_eal/linuxapp/eal/eal.c | 26 ++++++++++++++++++++++++++
lib/librte_eal/linuxapp/eal/eal_pci.c | 33 +++++++++------------------------
5 files changed, 57 insertions(+), 26 deletions(-)
diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index 35e3117..5271fc2 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -633,3 +633,10 @@ rte_eal_process_type(void)
{
return rte_config.process_type;
}
+
+int
+rte_eal_unbind_kernel_driver(const char *devpath __rte_unused,
+ const char *devid __rte_unused)
+{
+ return -ENOTSUP;
+}
diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c b/lib/librte_eal/bsdapp/eal/eal_pci.c
index 7ed0115..703f034 100644
--- a/lib/librte_eal/bsdapp/eal/eal_pci.c
+++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
@@ -89,11 +89,11 @@
/* unbind kernel driver for this device */
int
-pci_unbind_kernel_driver(struct rte_pci_device *dev __rte_unused)
+pci_unbind_kernel_driver(struct rte_pci_device *dev)
{
RTE_LOG(ERR, EAL, "RTE_PCI_DRV_FORCE_UNBIND flag is not implemented "
"for BSD\n");
- return -ENOTSUP;
+ return rte_eal_unbind_kernel_driver(dev);
}
/* Map pci device */
diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h
index 9e7d8f6..b0c208a 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -256,6 +256,19 @@ int rte_eal_alarm_init(void);
int rte_eal_check_module(const char *module_name);
/**
+ * Unbind kernel driver bound to the device specified by the given devpath,
+ * and its string identification.
+ *
+ * @param devpath path to the device directory ("/sys/.../devices/<name>")
+ * @param devid identification of the device (<name>)
+ *
+ * @return
+ * -1 unbind has failed
+ * 0 module has been unbound
+ */
+int rte_eal_unbind_kernel_driver(const char *devpath, const char *devid);
+
+/**
* Get cpu core_id.
*
* This function is private to the EAL.
diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c
index 2075282..5f6676d 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -943,3 +943,29 @@ rte_eal_check_module(const char *module_name)
/* Module has been found */
return 1;
}
+
+int
+rte_eal_unbind_kernel_driver(const char *devpath, const char *devid)
+{
+ char filename[PATH_MAX];
+ FILE *f;
+
+ snprintf(filename, sizeof(filename),
+ "%s/driver/unbind", devpath);
+
+ f = fopen(filename, "w");
+ if (f == NULL) /* device was not bound */
+ return 0;
+
+ if (fwrite(devid, strlen(devid), 1, f) == 0) {
+ RTE_LOG(ERR, EAL, "%s(): could not write to %s\n", __func__,
+ filename);
+ goto error;
+ }
+
+ fclose(f);
+ return 0;
+error:
+ fclose(f);
+ return -1;
+}
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c b/lib/librte_eal/linuxapp/eal/eal_pci.c
index 876ba38..a03553f 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -59,38 +59,23 @@ int
pci_unbind_kernel_driver(struct rte_pci_device *dev)
{
int n;
- FILE *f;
- char filename[PATH_MAX];
- char buf[BUFSIZ];
+ char devpath[PATH_MAX];
+ char devid[BUFSIZ];
struct rte_pci_addr *loc = &dev->addr;
- /* open /sys/bus/pci/devices/AAAA:BB:CC.D/driver */
- snprintf(filename, sizeof(filename),
- "%s/" PCI_PRI_FMT "/driver/unbind", pci_get_sysfs_path(),
+ /* devpath /sys/bus/pci/devices/AAAA:BB:CC.D */
+ snprintf(devpath, sizeof(devpath),
+ "%s/" PCI_PRI_FMT, pci_get_sysfs_path(),
loc->domain, loc->bus, loc->devid, loc->function);
- f = fopen(filename, "w");
- if (f == NULL) /* device was not bound */
- return 0;
-
- n = snprintf(buf, sizeof(buf), PCI_PRI_FMT "\n",
+ n = snprintf(devid, sizeof(devid), PCI_PRI_FMT "\n",
loc->domain, loc->bus, loc->devid, loc->function);
- if ((n < 0) || (n >= (int)sizeof(buf))) {
+ if ((n < 0) || (n >= (int)sizeof(devid))) {
RTE_LOG(ERR, EAL, "%s(): snprintf failed\n", __func__);
- goto error;
- }
- if (fwrite(buf, n, 1, f) == 0) {
- RTE_LOG(ERR, EAL, "%s(): could not write to %s\n", __func__,
- filename);
- goto error;
+ return -1;
}
- fclose(f);
- return 0;
-
-error:
- fclose(f);
- return -1;
+ return rte_eal_unbind_kernel_driver(devpath, devid);
}
static int
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/4] eal/linux: generalize PCI kernel driver extraction to EAL
From: Shreyansh Jain @ 2016-10-14 10:55 UTC (permalink / raw)
To: dev; +Cc: viktorin, thomas.monjalon, david.marchand, Shreyansh Jain
In-Reply-To: <1476442527-30726-1-git-send-email-shreyansh.jain@nxp.com>
From: Jan Viktorin <viktorin@rehivetech.com>
Generalize the PCI-specific pci_get_kernel_driver_by_path. The function
is general enough, we have just moved it to eal.c, changed the prefix to
rte_eal and provided it privately to other parts of EAL.
Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
--
Changes since v1:
- update BSD support for unbind kernel driver
---
lib/librte_eal/bsdapp/eal/eal.c | 7 +++++++
lib/librte_eal/common/eal_private.h | 14 ++++++++++++++
lib/librte_eal/linuxapp/eal/eal.c | 29 +++++++++++++++++++++++++++++
lib/librte_eal/linuxapp/eal/eal_pci.c | 31 +------------------------------
4 files changed, 51 insertions(+), 30 deletions(-)
diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index 5271fc2..9b93da3 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -640,3 +640,10 @@ rte_eal_unbind_kernel_driver(const char *devpath __rte_unused,
{
return -ENOTSUP;
}
+
+int
+rte_eal_get_kernel_driver_by_path(const char *filename __rte_unused,
+ char *dri_name __rte_unused)
+{
+ return -ENOTSUP;
+}
diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h
index b0c208a..c8c2131 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -269,6 +269,20 @@ int rte_eal_check_module(const char *module_name);
int rte_eal_unbind_kernel_driver(const char *devpath, const char *devid);
/**
+ * Extract the kernel driver name from the absolute path to the driver.
+ *
+ * @param filename path to the driver ("<path-to-device>/driver")
+ * @path dri_name target buffer where to place the driver name
+ * (should be at least PATH_MAX long)
+ *
+ * @return
+ * -1 on failure
+ * 0 when successful
+ * 1 when there is no such driver
+ */
+int rte_eal_get_kernel_driver_by_path(const char *filename, char *dri_name);
+
+/**
* Get cpu core_id.
*
* This function is private to the EAL.
diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c
index 5f6676d..00af21c 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -969,3 +969,32 @@ error:
fclose(f);
return -1;
}
+
+int
+rte_eal_get_kernel_driver_by_path(const char *filename, char *dri_name)
+{
+ int count;
+ char path[PATH_MAX];
+ char *name;
+
+ if (!filename || !dri_name)
+ return -1;
+
+ count = readlink(filename, path, PATH_MAX);
+ if (count >= PATH_MAX)
+ return -1;
+
+ /* For device does not have a driver */
+ if (count < 0)
+ return 1;
+
+ path[count] = '\0';
+
+ name = strrchr(path, '/');
+ if (name) {
+ strncpy(dri_name, name + 1, strlen(name + 1) + 1);
+ return 0;
+ }
+
+ return -1;
+}
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c b/lib/librte_eal/linuxapp/eal/eal_pci.c
index a03553f..e1cf9e8 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -78,35 +78,6 @@ pci_unbind_kernel_driver(struct rte_pci_device *dev)
return rte_eal_unbind_kernel_driver(devpath, devid);
}
-static int
-pci_get_kernel_driver_by_path(const char *filename, char *dri_name)
-{
- int count;
- char path[PATH_MAX];
- char *name;
-
- if (!filename || !dri_name)
- return -1;
-
- count = readlink(filename, path, PATH_MAX);
- if (count >= PATH_MAX)
- return -1;
-
- /* For device does not have a driver */
- if (count < 0)
- return 1;
-
- path[count] = '\0';
-
- name = strrchr(path, '/');
- if (name) {
- strncpy(dri_name, name + 1, strlen(name + 1) + 1);
- return 0;
- }
-
- return -1;
-}
-
/* Map pci device */
int
rte_eal_pci_map_device(struct rte_pci_device *dev)
@@ -354,7 +325,7 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t bus,
/* parse driver */
snprintf(filename, sizeof(filename), "%s/driver", dirname);
- ret = pci_get_kernel_driver_by_path(filename, driver);
+ ret = rte_eal_get_kernel_driver_by_path(filename, driver);
if (ret < 0) {
RTE_LOG(ERR, EAL, "Fail to get kernel driver\n");
free(dev);
--
2.7.4
^ permalink raw reply related
* [PATCH] kni: fix unused variable compile error
From: Ferruh Yigit @ 2016-10-14 11:24 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit
compile error:
CC [M] .../lib/librte_eal/linuxapp/kni/kni_misc.o
cc1: warnings being treated as errors
.../lib/librte_eal/linuxapp/kni/kni_misc.c: In function ‘kni_exit_net’:
.../lib/librte_eal/linuxapp/kni/kni_misc.c:113:18:
error: unused variable ‘knet’
For some kernel versions mutex_destroy() is macro and does nothing,
this cause an unused variable warning for knet which used in mutex_destroy
Added unused attribute to the knet variable.
Fixes: 93a298b34e1b ("kni: support core id parameter in single threaded mode")
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
lib/librte_eal/linuxapp/kni/kni_misc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c b/lib/librte_eal/linuxapp/kni/kni_misc.c
index 3303d9b..497db9b 100644
--- a/lib/librte_eal/linuxapp/kni/kni_misc.c
+++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
@@ -110,9 +110,11 @@ kni_init_net(struct net *net)
static void __net_exit
kni_exit_net(struct net *net)
{
- struct kni_net *knet = net_generic(net, kni_net_id);
+ struct kni_net *knet __maybe_unused;
+ knet = net_generic(net, kni_net_id);
mutex_destroy(&knet->kni_kthread_lock);
+
#ifndef HAVE_SIMPLIFIED_PERNET_OPERATIONS
kfree(knet);
#endif
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 2/2] mempool: pktmbuf pool default fallback for mempool ops error
From: Olivier Matz @ 2016-10-14 12:10 UTC (permalink / raw)
To: Hemant Agrawal; +Cc: dev, jerin.jacob, david.hunt
In-Reply-To: <7e26965e-173b-1cf6-0beb-c94712ad615a@nxp.com>
Hi Hemant,
Sorry for the late answer. Please see some comments inline.
On 10/13/2016 03:15 PM, Hemant Agrawal wrote:
> Hi Olivier,
> Any updates w.r.t this patch set?
>
> Regards
> Hemant
> On 9/22/2016 6:42 PM, Hemant Agrawal wrote:
>> Hi Olivier
>>
>> On 9/19/2016 7:27 PM, Olivier Matz wrote:
>>> Hi Hemant,
>>>
>>> On 09/16/2016 06:46 PM, Hemant Agrawal wrote:
>>>> In the rte_pktmbuf_pool_create, if the default external mempool is
>>>> not available, the implementation can default to "ring_mp_mc", which
>>>> is an software implementation.
>>>>
>>>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>>>> ---
>>>> Changes in V3:
>>>> * adding warning message to say that falling back to default sw pool
>>>> ---
>>>> lib/librte_mbuf/rte_mbuf.c | 8 ++++++++
>>>> 1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
>>>> index 4846b89..8ab0eb1 100644
>>>> --- a/lib/librte_mbuf/rte_mbuf.c
>>>> +++ b/lib/librte_mbuf/rte_mbuf.c
>>>> @@ -176,6 +176,14 @@ rte_pktmbuf_pool_create(const char *name,
>>>> unsigned n,
>>>>
>>>> rte_errno = rte_mempool_set_ops_byname(mp,
>>>> RTE_MBUF_DEFAULT_MEMPOOL_OPS, NULL);
>>>> +
>>>> + /* on error, try falling back to the software based default
>>>> pool */
>>>> + if (rte_errno == -EOPNOTSUPP) {
>>>> + RTE_LOG(WARNING, MBUF, "Default HW Mempool not supported. "
>>>> + "falling back to sw mempool \"ring_mp_mc\"");
>>>> + rte_errno = rte_mempool_set_ops_byname(mp, "ring_mp_mc",
>>>> NULL);
>>>> + }
>>>> +
>>>> if (rte_errno != 0) {
>>>> RTE_LOG(ERR, MBUF, "error setting mempool handler\n");
>>>> return NULL;
>>>>
>>>
>>> Without adding a new method ".supported()", the first call to
>>> rte_mempool_populate() could return the same error ENOTSUP. In this
>>> case, it is still possible to fallback.
>>>
>> It will be bit late.
>>
>> On failure, than we have to set the default ops and do a goto before
>> rte_pktmbuf_pool_init(mp, &mbp_priv);
I still think we can do the job without adding the .supported() method.
The following code is just an (untested) example:
struct rte_mempool *
rte_pktmbuf_pool_create(const char *name, unsigned n,
unsigned cache_size, uint16_t priv_size, uint16_t data_room_size,
int socket_id)
{
struct rte_mempool *mp;
struct rte_pktmbuf_pool_private mbp_priv;
unsigned elt_size;
int ret;
const char *ops[] = {
RTE_MBUF_DEFAULT_MEMPOOL_OPS, "ring_mp_mc", NULL,
};
const char **op;
if (RTE_ALIGN(priv_size, RTE_MBUF_PRIV_ALIGN) != priv_size) {
RTE_LOG(ERR, MBUF, "mbuf priv_size=%u is not aligned\n",
priv_size);
rte_errno = EINVAL;
return NULL;
}
elt_size = sizeof(struct rte_mbuf) + (unsigned)priv_size +
(unsigned)data_room_size;
mbp_priv.mbuf_data_room_size = data_room_size;
mbp_priv.mbuf_priv_size = priv_size;
for (op = &ops[0]; *op != NULL; op++) {
mp = rte_mempool_create_empty(name, n, elt_size, cache_size,
sizeof(struct rte_pktmbuf_pool_private), socket_id, 0);
if (mp == NULL)
return NULL;
ret = rte_mempool_set_ops_byname(mp, *op, NULL);
if (ret != 0) {
RTE_LOG(ERR, MBUF, "error setting mempool handler\n");
rte_mempool_free(mp);
if (ret == -ENOTSUP)
continue;
rte_errno = -ret;
return NULL;
}
rte_pktmbuf_pool_init(mp, &mbp_priv);
ret = rte_mempool_populate_default(mp);
if (ret < 0) {
rte_mempool_free(mp);
if (ret == -ENOTSUP)
continue;
rte_errno = -ret;
return NULL;
}
}
rte_mempool_obj_iter(mp, rte_pktmbuf_init, NULL);
return mp;
}
>>> I've just submitted an RFC, which I think is quite linked:
>>> http://dpdk.org/ml/archives/dev/2016-September/046974.html
>>> Assuming a new parameter "mempool_ops" is added to
>>> rte_pktmbuf_pool_create(), would it make sense to fallback to
>>> "ring_mp_mc"? What about just returning ENOTSUP? The application could
>>> do the job and decide which sw fallback to use.
>>
>> We ran into this issue when trying to run the standard DPDK examples
>> (l3fwd) in VM. Do you think, is it practical to add fallback handling in
>> each of the DPDK examples?
OK. What is still unclear for me, is how the software is aware of the
different hardware-assisted handlers. Moreover, we could imagine more
software handlers, which could be used depending on the use case.
I think this choice has to be made by the user or the application:
- the application may want to use a specific (sw or hw) handler: in
this case, it want to be notified if it fails, instead of having
a quiet fallback to ring_mp_mc
- if several handlers are available, the application may want to
try them in a specific order
- maybe some handlers will have some limitations with some
configurations or driver? The application could decide to use
a different handler according the configuration.
So that's why I think this is an application decision.
>> Typically when someone is writing a application on host, he need not
>> worry non-availability of the hw offloaded mempool. He may also want to
>> run the same binary in virtual machine. In VM, it is not guaranteed that
>> hw offloaded mempools will be available.
Running the same binary is of course a need. But if your VM does not
provide the same virtualized hardware than the host, I think the command
line option makes sense.
AFAIU, on the host, you can use a hw mempool handler or a sw one, and
on the guest, only a sw one. So you need an option to select the
behavior you want on the host, without recompiling.
I understand that modifying all the applications is not a good option
either. I'm thinking a a EAL parameter that would allow to configure a
library (mbuf in this case). Something like kernel boot options.
Example: testpmd -l 2,4 --opt mbuf.handler="ring_mp_mc" -- [app args]
I don't know if this is feasible, this has to be discussed first, but
what do you think on the principle? The value could also be an
ordered list if we want a fallback, and this option could be overriden
by the application before creating the mbuf pool. There was some
discussions about a kind of dpdk global configuration some time ago.
Regards,
Olivier
^ permalink raw reply
* Re: [PATCH] kni: fix unused variable compile error
From: Thomas Monjalon @ 2016-10-14 12:30 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev
In-Reply-To: <20161014112440.12966-1-ferruh.yigit@intel.com>
2016-10-14 12:24, Ferruh Yigit:
> compile error:
> CC [M] .../lib/librte_eal/linuxapp/kni/kni_misc.o
> cc1: warnings being treated as errors
> .../lib/librte_eal/linuxapp/kni/kni_misc.c: In function ‘kni_exit_net’:
> .../lib/librte_eal/linuxapp/kni/kni_misc.c:113:18:
> error: unused variable ‘knet’
>
> For some kernel versions mutex_destroy() is macro and does nothing,
> this cause an unused variable warning for knet which used in mutex_destroy
>
> Added unused attribute to the knet variable.
>
> Fixes: 93a298b34e1b ("kni: support core id parameter in single threaded mode")
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
That's why supporting an out-of-tree kernel module is a nightmare.
Compilation breaks everytime with various kernels :(
Please could you tell which Linux versions are affected?
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Jerin Jacob @ 2016-10-14 12:52 UTC (permalink / raw)
To: Hemant Agrawal
Cc: Bill Fischofer, dev@dpdk.org, thomas.monjalon@6wind.com,
bruce.richardson@intel.com, narender.vangati@intel.com,
gage.eads@intel.com
In-Reply-To: <DB5PR04MB1605D0F7FAAEB2484BEFF76689DF0@DB5PR04MB1605.eurprd04.prod.outlook.com>
On Fri, Oct 14, 2016 at 10:30:33AM +0000, Hemant Agrawal wrote:
> > > Am I reading this correctly that there is no way to support an
> > > indefinite waiting capability? Or is this just saying that if a timed
> > > wait is performed there are min/max limits for the wait duration?
> >
> > Application can wait indefinite if required. see
> > RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT configuration option.
> >
> > Trivial application may not need different wait values on each dequeue.This is a
> > performance optimization opportunity for implementation.
>
> Jerin, It is irrespective of wait configuration, whether you are using per device wait or per dequeuer wait.
> Can the value of MAX_U32 or MAX_U64 be treated as infinite weight?
That will be yet another check in the fast path in the implementation, I
think, for more fine-grained wait scheme. Let application configure the device
with RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT so that the application can have
two different function pointer-based implementation for dequeue function
if required.
With RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT configuration, implicitly
MAX_U64 becomes infinite weight as the wait is uint64_t.
I can add this info in v3 if required.
Jerin
>
> >
^ permalink raw reply
* Re: [PATCH v2 2/5] i40e: implement vector PMD for ARM architecture
From: Jerin Jacob @ 2016-10-14 13:26 UTC (permalink / raw)
To: Jianbo Liu; +Cc: helin.zhang, jingjing.wu, dev, qi.z.zhang
In-Reply-To: <1476417604-22400-3-git-send-email-jianbo.liu@linaro.org>
On Fri, Oct 14, 2016 at 09:30:01AM +0530, Jianbo Liu wrote:
> Use ARM NEON intrinsic to implement i40e vPMD
>
> Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
I'm not entirely familiar with i40e internals.The patch looks OK interms
of using NEON instructions.
Acked-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> ---
> drivers/net/i40e/Makefile | 4 +
> drivers/net/i40e/i40e_rxtx_vec_neon.c | 614 ++++++++++++++++++++++++++++++++++
> 2 files changed, 618 insertions(+)
> create mode 100644 drivers/net/i40e/i40e_rxtx_vec_neon.c
>
^ permalink raw reply
* Re: [PATCH v2 3/5] i40e: enable i40e vector PMD on ARMv8a platform
From: Jerin Jacob @ 2016-10-14 13:28 UTC (permalink / raw)
To: Jianbo Liu; +Cc: helin.zhang, jingjing.wu, dev, qi.z.zhang
In-Reply-To: <1476417604-22400-4-git-send-email-jianbo.liu@linaro.org>
On Fri, Oct 14, 2016 at 09:30:02AM +0530, Jianbo Liu wrote:
> Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
Reviewed-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> ---
> config/defconfig_arm64-armv8a-linuxapp-gcc | 1 -
> doc/guides/nics/features/i40e_vec.ini | 1 +
> doc/guides/nics/features/i40e_vf_vec.ini | 1 +
> 3 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc
> index a0f4473..6321884 100644
> --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
> +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
> @@ -45,6 +45,5 @@ CONFIG_RTE_TOOLCHAIN_GCC=y
> CONFIG_RTE_EAL_IGB_UIO=n
>
> CONFIG_RTE_LIBRTE_FM10K_PMD=n
> -CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=n
>
> CONFIG_RTE_SCHED_VECTOR=n
> diff --git a/doc/guides/nics/features/i40e_vec.ini b/doc/guides/nics/features/i40e_vec.ini
> index 0953d84..edd6b71 100644
> --- a/doc/guides/nics/features/i40e_vec.ini
> +++ b/doc/guides/nics/features/i40e_vec.ini
> @@ -37,3 +37,4 @@ Linux UIO = Y
> Linux VFIO = Y
> x86-32 = Y
> x86-64 = Y
> +ARMv8 = Y
> diff --git a/doc/guides/nics/features/i40e_vf_vec.ini b/doc/guides/nics/features/i40e_vf_vec.ini
> index 2a44bf6..d6674f7 100644
> --- a/doc/guides/nics/features/i40e_vf_vec.ini
> +++ b/doc/guides/nics/features/i40e_vf_vec.ini
> @@ -26,3 +26,4 @@ Linux UIO = Y
> Linux VFIO = Y
> x86-32 = Y
> x86-64 = Y
> +ARMv8 = Y
> --
> 2.4.11
>
^ permalink raw reply
* [PATCH v2] net/ixgbe: support multiqueue mode VMDq DCB with SRIOV
From: Bernard Iremonger @ 2016-10-14 13:29 UTC (permalink / raw)
To: dev, rahul.r.shah, wenzhuo.lu; +Cc: Bernard Iremonger
In-Reply-To: <1472202487-20119-1-git-send-email-bernard.iremonger@intel.com>
modify ixgbe_dcb_tx_hw_config function.
modify ixgbe_dev_mq_rx_configure function.
modify ixgbe_configure_dcb function.
Changes in v2:
Rebased to DPDK v16.11-rc1
Signed-off-by: Rahul R Shah <rahul.r.shah@intel.com>
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
---
drivers/net/ixgbe/ixgbe_ethdev.c | 9 ++++-----
drivers/net/ixgbe/ixgbe_rxtx.c | 37 +++++++++++++++++++++----------------
2 files changed, 25 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 4ca5747..114698d 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -1977,6 +1977,8 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
/* check multi-queue mode */
switch (dev_conf->rxmode.mq_mode) {
case ETH_MQ_RX_VMDQ_DCB:
+ PMD_INIT_LOG(INFO, "ETH_MQ_RX_VMDQ_DCB mode supported in SRIOV");
+ break;
case ETH_MQ_RX_VMDQ_DCB_RSS:
/* DCB/RSS VMDQ in SRIOV mode, not implement yet */
PMD_INIT_LOG(ERR, "SRIOV active,"
@@ -2012,11 +2014,8 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
switch (dev_conf->txmode.mq_mode) {
case ETH_MQ_TX_VMDQ_DCB:
- /* DCB VMDQ in SRIOV mode, not implement yet */
- PMD_INIT_LOG(ERR, "SRIOV is active,"
- " unsupported VMDQ mq_mode tx %d.",
- dev_conf->txmode.mq_mode);
- return -EINVAL;
+ PMD_INIT_LOG(INFO, "ETH_MQ_TX_VMDQ_DCB mode supported in SRIOV");
+ break;
default: /* ETH_MQ_TX_VMDQ_ONLY or ETH_MQ_TX_NONE */
dev->data->dev_conf.txmode.mq_mode = ETH_MQ_TX_VMDQ_ONLY;
break;
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index 2ce8234..bb13889 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
* Copyright 2014 6WIND S.A.
* All rights reserved.
*
@@ -3313,15 +3313,16 @@ ixgbe_vmdq_dcb_configure(struct rte_eth_dev *dev)
/**
* ixgbe_dcb_config_tx_hw_config - Configure general DCB TX parameters
- * @hw: pointer to hardware structure
+ * @dev: pointer to eth_dev structure
* @dcb_config: pointer to ixgbe_dcb_config structure
*/
static void
-ixgbe_dcb_tx_hw_config(struct ixgbe_hw *hw,
+ixgbe_dcb_tx_hw_config(struct rte_eth_dev *dev,
struct ixgbe_dcb_config *dcb_config)
{
uint32_t reg;
uint32_t q;
+ struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
PMD_INIT_FUNC_TRACE();
if (hw->mac.type != ixgbe_mac_82598EB) {
@@ -3339,11 +3340,17 @@ ixgbe_dcb_tx_hw_config(struct ixgbe_hw *hw,
if (dcb_config->vt_mode)
reg |= IXGBE_MTQC_VT_ENA;
IXGBE_WRITE_REG(hw, IXGBE_MTQC, reg);
-
- /* Disable drop for all queues */
- for (q = 0; q < 128; q++)
- IXGBE_WRITE_REG(hw, IXGBE_QDE,
- (IXGBE_QDE_WRITE | (q << IXGBE_QDE_IDX_SHIFT)));
+ if (RTE_ETH_DEV_SRIOV(dev).active == 0) {
+ /* Disable drop for all queues in VMDQ mode*/
+ for (q = 0; q < 128; q++)
+ IXGBE_WRITE_REG(hw, IXGBE_QDE,
+ (IXGBE_QDE_WRITE | (q << IXGBE_QDE_IDX_SHIFT) | IXGBE_QDE_ENABLE));
+ } else {
+ /* Enable drop for all queues in SRIOV mode */
+ for (q = 0; q < 128; q++)
+ IXGBE_WRITE_REG(hw, IXGBE_QDE,
+ (IXGBE_QDE_WRITE | (q << IXGBE_QDE_IDX_SHIFT)));
+ }
/* Enable the Tx desc arbiter */
reg = IXGBE_READ_REG(hw, IXGBE_RTTDCS);
@@ -3378,7 +3385,7 @@ ixgbe_vmdq_dcb_hw_tx_config(struct rte_eth_dev *dev,
vmdq_tx_conf->nb_queue_pools == ETH_16_POOLS ? 0xFFFF : 0xFFFFFFFF);
/*Configure general DCB TX parameters*/
- ixgbe_dcb_tx_hw_config(hw, dcb_config);
+ ixgbe_dcb_tx_hw_config(dev, dcb_config);
}
static void
@@ -3661,7 +3668,7 @@ ixgbe_dcb_hw_configure(struct rte_eth_dev *dev,
/*get DCB TX configuration parameters from rte_eth_conf*/
ixgbe_dcb_tx_config(dev, dcb_config);
/*Configure general DCB TX parameters*/
- ixgbe_dcb_tx_hw_config(hw, dcb_config);
+ ixgbe_dcb_tx_hw_config(dev, dcb_config);
break;
default:
PMD_INIT_LOG(ERR, "Incorrect DCB TX mode configuration");
@@ -3810,9 +3817,6 @@ void ixgbe_configure_dcb(struct rte_eth_dev *dev)
(dev_conf->rxmode.mq_mode != ETH_MQ_RX_DCB_RSS))
return;
- if (dev->data->nb_rx_queues != ETH_DCB_NUM_QUEUES)
- return;
-
/** Configure DCB hardware **/
ixgbe_dcb_hw_configure(dev, dcb_cfg);
}
@@ -4082,12 +4086,13 @@ ixgbe_dev_mq_rx_configure(struct rte_eth_dev *dev)
case ETH_MQ_RX_VMDQ_RSS:
ixgbe_config_vf_rss(dev);
break;
-
- /* FIXME if support DCB/RSS together with VMDq & SRIOV */
case ETH_MQ_RX_VMDQ_DCB:
+ ixgbe_vmdq_dcb_configure(dev);
+ break;
+ /* FIXME if support DCB/RSS together with VMDq & SRIOV */
case ETH_MQ_RX_VMDQ_DCB_RSS:
PMD_INIT_LOG(ERR,
- "Could not support DCB with VMDq & SRIOV");
+ "Could not support DCB/RSS with VMDq & SRIOV");
return -1;
default:
ixgbe_config_vf_default(dev);
--
2.10.1
^ permalink raw reply related
* Re: [PATCH v5 1/6] ethdev: add Tx preparation
From: Kulasek, TomaszX @ 2016-10-14 14:02 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev@dpdk.org, Ananyev, Konstantin
In-Reply-To: <8024593.WaNfoiub2G@xps13>
Hi Thomas,
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Thursday, October 13, 2016 21:21
> To: Kulasek, TomaszX <tomaszx.kulasek@intel.com>
> Cc: dev@dpdk.org; Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Subject: Re: [PATCH v5 1/6] ethdev: add Tx preparation
>
> Hi,
>
> 2016-10-13 19:36, Tomasz Kulasek:
> > Added API for `rte_eth_tx_prep`
> >
> > uint16_t rte_eth_tx_prep(uint8_t port_id, uint16_t queue_id,
> > struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
> >
> > Added fields to the `struct rte_eth_desc_lim`:
> >
> > uint16_t nb_seg_max;
> > /**< Max number of segments per whole packet. */
> >
> > uint16_t nb_mtu_seg_max;
> > /**< Max number of segments per one MTU */
> >
> > Created `rte_pkt.h` header with common used functions:
>
> Same comment as in previous revision:
> this description lacks the usability and performance considerations.
>
> > +static inline uint16_t
> > +rte_eth_tx_prep(uint8_t port_id __rte_unused, uint16_t queue_id
> __rte_unused,
> > + struct rte_mbuf **tx_pkts __rte_unused, uint16_t nb_pkts)
>
> Doxygen still do not parse it well (same issue as previous revision).
>
> > +/**
> > + * Fix pseudo header checksum for TSO and non-TSO tcp/udp packets
> before
> > + * hardware tx checksum.
> > + * For non-TSO tcp/udp packets full pseudo-header checksum is counted
> and set.
> > + * For TSO the IP payload length is not included.
> > + */
> > +static inline int
> > +rte_phdr_cksum_fix(struct rte_mbuf *m)
>
> You probably don't need this function since the recent improvements from
> Olivier.
Do you mean this improvement: "net: add function to calculate a checksum in a mbuf"
http://dpdk.org/dev/patchwork/patch/16542/
I see only full raw checksum computation on mbuf in Olivier patches, while this function counts only pseudo-header checksum to be used with tx offload.
Tomasz
^ permalink raw reply
* Re: [PATCH v5 1/6] ethdev: add Tx preparation
From: Thomas Monjalon @ 2016-10-14 14:20 UTC (permalink / raw)
To: Kulasek, TomaszX; +Cc: dev, Ananyev, Konstantin, olivier.matz
In-Reply-To: <3042915272161B4EB253DA4D77EB373A14F35FFC@IRSMSX102.ger.corp.intel.com>
2016-10-14 14:02, Kulasek, TomaszX:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 2016-10-13 19:36, Tomasz Kulasek:
> > > +/**
> > > + * Fix pseudo header checksum for TSO and non-TSO tcp/udp packets
> > before
> > > + * hardware tx checksum.
> > > + * For non-TSO tcp/udp packets full pseudo-header checksum is counted
> > and set.
> > > + * For TSO the IP payload length is not included.
> > > + */
> > > +static inline int
> > > +rte_phdr_cksum_fix(struct rte_mbuf *m)
> >
> > You probably don't need this function since the recent improvements from
> > Olivier.
>
> Do you mean this improvement: "net: add function to calculate a checksum in a mbuf"
> http://dpdk.org/dev/patchwork/patch/16542/
>
> I see only full raw checksum computation on mbuf in Olivier patches, while this function counts only pseudo-header checksum to be used with tx offload.
OK. Please check what exists already in librte_net (especially rte_ip.h)
and try to re-use code if possible. Thanks
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Eads, Gage @ 2016-10-14 15:00 UTC (permalink / raw)
To: Jerin Jacob, dev@dpdk.org
Cc: thomas.monjalon@6wind.com, Richardson, Bruce, Vangati, Narender,
hemant.agrawal@nxp.com
In-Reply-To: <1476214216-31982-1-git-send-email-jerin.jacob@caviumnetworks.com>
Thanks Jerin, this looks good. I've put a few notes/questions inline.
Thanks,
Gage
> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Tuesday, October 11, 2016 2:30 PM
> To: dev@dpdk.org
> Cc: thomas.monjalon@6wind.com; Richardson, Bruce
> <bruce.richardson@intel.com>; Vangati, Narender
> <narender.vangati@intel.com>; hemant.agrawal@nxp.com; Eads, Gage
> <gage.eads@intel.com>; Jerin Jacob <jerin.jacob@caviumnetworks.com>
> Subject: [dpdk-dev] [RFC] [PATCH v2] libeventdev: event driven programming
> model framework for DPDK
>
> Thanks to Intel and NXP folks for the positive and constructive feedback
> I've received so far. Here is the updated RFC(v2).
>
> I've attempted to address as many comments as possible.
>
> This series adds rte_eventdev.h to the DPDK tree with
> adequate documentation in doxygen format.
>
> Updates are also available online:
>
> Related draft header file (this patch):
> https://rawgit.com/jerinjacobk/libeventdev/master/rte_eventdev.h
>
> PDF version(doxgen output):
> https://rawgit.com/jerinjacobk/libeventdev/master/librte_eventdev_v2.pdf
>
> Repo:
> https://github.com/jerinjacobk/libeventdev
>
> v1..v2
>
> - Added Cavium, Intel, NXP copyrights in header file
>
> - Changed the concept of flow queues to flow ids.
> This is avoid dictating a specific structure to hold the flows.
> A s/w implementation can do atomic load balancing on multiple
> flow ids more efficiently than maintaining each event in a specific flow queue.
>
> - Change the scheduling group to event queue.
> A scheduling group is more a stream of events, so an event queue is a better
> abstraction.
>
> - Introduced event port concept, Instead of trying eventdev access to the lcore,
> a higher level of abstraction called event port is needed which is the
> application i/f to the eventdev to dequeue and enqueue the events.
> One or more event queues can be linked to single event port.
> There can be more than one event port per lcore allowing multiple lightweight
> threads to have their own i/f into eventdev, if the implementation supports it.
> An event port will be bound to a lcore or a lightweight thread to keep
> portable application workflow.
> An event port abstraction also encapsulates dequeue depth and enqueue depth
> for
> a scheduler implementations which can schedule multiple events at a time and
> output events that can be buffered.
>
> - Added configuration options with event queue(nb_atomic_flows,
> nb_atomic_order_sequences, single consumer etc)
> and event port(dequeue_queue_depth, enqueue_queue_depth etc) to define
> the
> limits on the resource usage.(Useful for optimized software implementation)
>
> - Introduced RTE_EVENT_DEV_CAP_QUEUE_QOS and
> RTE_EVENT_DEV_CAP_EVENT_QOS
> schemes of priority handling
>
> - Added event port to event queue servicing priority.
> This allows two event ports to connect to the same event queue with
> different priorities.
>
> - Changed the workflow as schedule/dequeue/enqueue.
> An implementation is free to define schedule as NOOP.
> A distributed s/w scheduler can use this to schedule events;
> also a centralized s/w scheduler can make this a NOOP on non-scheduler cores.
>
> - Removed Cavium HW specific schedule_from_group API
>
> - Removed Cavium HW specific ctxt_update/ctxt_wait APIs.
> Introduced a more generic "event pinning" concept. i.e
> If the normal workflow is a dequeue -> do work based on event type ->
> enqueue,
> a pin_event argument to enqueue
> where the pinned event is returned through the normal dequeue)
> allows application workflow to remain the same whether or not an
> implementation supports it.
>
> - Added dequeue() burst variant
>
> - Added the definition of a closed/open system - where open system is memory
> backed and closed system eventdev has limited capacity.
> In such systems, it is also useful to denote per event port how many packets
> can be active in the system.
> This can serve as a threshold for ethdev like devices so they don't overwhelm
> core to core events.
>
> - Added the option to specify maximum amount of time(in ns) application needs
> wait on dequeue()
>
> - Removed the scheme of expressing the number of flows in log2 format
>
> Open item or the item needs improvement.
> ----------------------------------------
> - Abstract the differences in event QoS management with different priority
> schemes
> available in different HW or SW implementations with portable application
> workflow.
>
> Based on the feedback, there three different kinds of QoS support available in
> three different HW or SW implementations.
> 1) Priority associated with the event queue
> 2) Priority associated with each event enqueue
> (Same flow can have two different priority on two separate enqueue)
> 3) Priority associated with the flow(each flow has unique priority)
>
> In v2, The differences abstracted based on device capability
> (RTE_EVENT_DEV_CAP_QUEUE_QOS for the first scheme,
> RTE_EVENT_DEV_CAP_EVENT_QOS for the second and third scheme).
> This scheme would call for different application workflow for
> nontrivial QoS-enabled applications.
>
> Looking forward to getting comments from both application and driver
> implementation perspective.
>
> /Jerin
>
> ---
> doc/api/doxy-api-index.md | 1 +
> doc/api/doxy-api.conf | 1 +
> lib/librte_eventdev/rte_eventdev.h | 1204
> ++++++++++++++++++++++++++++++++++++
> 3 files changed, 1206 insertions(+)
> create mode 100644 lib/librte_eventdev/rte_eventdev.h
>
> diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
> index 6675f96..28c1329 100644
> --- a/doc/api/doxy-api-index.md
> +++ b/doc/api/doxy-api-index.md
> @@ -40,6 +40,7 @@ There are many libraries, so their headers may be
> grouped by topics:
> [ethdev] (@ref rte_ethdev.h),
> [ethctrl] (@ref rte_eth_ctrl.h),
> [cryptodev] (@ref rte_cryptodev.h),
> + [eventdev] (@ref rte_eventdev.h),
> [devargs] (@ref rte_devargs.h),
> [bond] (@ref rte_eth_bond.h),
> [vhost] (@ref rte_virtio_net.h),
> diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf
> index 9dc7ae5..9841477 100644
> --- a/doc/api/doxy-api.conf
> +++ b/doc/api/doxy-api.conf
> @@ -41,6 +41,7 @@ INPUT = doc/api/doxy-api-index.md \
> lib/librte_cryptodev \
> lib/librte_distributor \
> lib/librte_ether \
> + lib/librte_eventdev \
> lib/librte_hash \
> lib/librte_ip_frag \
> lib/librte_jobstats \
> diff --git a/lib/librte_eventdev/rte_eventdev.h
> b/lib/librte_eventdev/rte_eventdev.h
> new file mode 100644
> index 0000000..f60e461
> --- /dev/null
> +++ b/lib/librte_eventdev/rte_eventdev.h
> @@ -0,0 +1,1204 @@
> +/*
> + * BSD LICENSE
> + *
> + * Copyright 2016 Cavium.
> + * Copyright 2016 Intel Corporation.
> + * Copyright 2016 NXP.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + *
> + * * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in
> + * the documentation and/or other materials provided with the
> + * distribution.
> + * * Neither the name of Cavium nor the names of its
> + * contributors may be used to endorse or promote products derived
> + * from this software without specific prior written permission.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS
> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
> NOT
> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
> FITNESS FOR
> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> COPYRIGHT
> + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> INCIDENTAL,
> + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> NOT
> + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
> OF USE,
> + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
> AND ON ANY
> + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
> THE USE
> + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> DAMAGE.
> + */
> +
> +#ifndef _RTE_EVENTDEV_H_
> +#define _RTE_EVENTDEV_H_
> +
> +/**
> + * @file
> + *
> + * RTE Event Device API
> + *
> + * The Event Device API is composed of two parts:
> + *
> + * - The application-oriented Event API that includes functions to setup
> + * an event device (configure it, setup its queues, ports and start it), to
> + * establish the link between queues to port and to receive events, and so on.
> + *
> + * - The driver-oriented Event API that exports a function allowing
> + * an event poll Mode Driver (PMD) to simultaneously register itself as
> + * an event device driver.
> + *
> + * Event device components:
> + *
> + * +-----------------+
> + * | +-------------+ |
> + * +-------+ | | flow 0 | |
> + * |Packet | | +-------------+ |
> + * |event | | +-------------+ |
> + * | | | | flow 1 | |event_port_link(port0, queue0)
> + * +-------+ | +-------------+ | | +--------+
> + * +-------+ | +-------------+ o-----v-----o |dequeue +------+
> + * |Crypto | | | flow n | | | event +------->|Core 0|
> + * |work | | +-------------+ o----+ | port 0 | | |
> + * |done ev| | event queue 0 | | +--------+ +------+
> + * +-------+ +-----------------+ |
> + * +-------+ |
> + * |Timer | +-----------------+ | +--------+
> + * |expiry | | +-------------+ | +------o |dequeue +------+
> + * |event | | | flow 0 | o-----------o event +------->|Core 1|
> + * +-------+ | +-------------+ | +----o port 1 | | |
> + * Event enqueue | +-------------+ | | +--------+ +------+
> + * o-------------> | | flow 1 | | |
> + * enqueue( | +-------------+ | |
> + * queue_id, | | | +--------+ +------+
> + * flow_id, | +-------------+ | | | |dequeue |Core 2|
> + * sched_type, | | flow n | o-----------o event +------->| |
> + * event_type, | +-------------+ | | | port 2 | +------+
> + * subev_type, | event queue 1 | | +--------+
> + * event) +-----------------+ | +--------+
> + * | | |dequeue +------+
> + * +-------+ +-----------------+ | | event +------->|Core n|
> + * |Core | | +-------------+ o-----------o port n | | |
> + * |(SW) | | | flow 0 | | | +--------+ +--+---+
> + * |event | | +-------------+ | | |
> + * +-------+ | +-------------+ | | |
> + * ^ | | flow 1 | | | |
> + * | | +-------------+ o------+ |
> + * | | +-------------+ | |
> + * | | | flow n | | |
> + * | | +-------------+ | |
> + * | | event queue n | |
> + * | +-----------------+ |
> + * | |
> + * +-----------------------------------------------------------+
> + *
> + *
> + *
> + * Event device: A hardware or software-based event scheduler.
> + *
> + * Event: A unit of scheduling that encapsulates a packet or other datatype
> + * like SW generated event from the core, Crypto work completion
> notification,
> + * Timer expiry event notification etc as well as metadata.
> + * The metadata includes flow ID, scheduling type, event priority, event_type,
> + * sub_event_type etc.
> + *
> + * Event queue: A queue containing events that are scheduled by the event
> dev.
> + * An event queue contains events of different flows associated with
> scheduling
> + * types, such as atomic, ordered, or parallel.
> + *
> + * Event port: An application's interface into the event dev for enqueue and
> + * dequeue operations. Each event port can be linked with one or more
> + * event queues for dequeue operations.
> + *
> + * By default, all the functions of the Event Device API exported by a PMD
> + * are lock-free functions which assume to not be invoked in parallel on
> + * different logical cores to work on the same target object. For instance,
> + * the dequeue function of a PMD cannot be invoked in parallel on two logical
> + * cores to operates on same event port. Of course, this function
> + * can be invoked in parallel by different logical cores on different ports.
> + * It is the responsibility of the upper level application to enforce this rule.
> + *
> + * In all functions of the Event API, the Event device is
> + * designated by an integer >= 0 named the device identifier *dev_id*
> + *
> + * At the Event driver level, Event devices are represented by a generic
> + * data structure of type *rte_event_dev*.
> + *
> + * Event devices are dynamically registered during the PCI/SoC device probing
> + * phase performed at EAL initialization time.
> + * When an Event device is being probed, a *rte_event_dev* structure and
> + * a new device identifier are allocated for that device. Then, the
> + * event_dev_init() function supplied by the Event driver matching the probed
> + * device is invoked to properly initialize the device.
> + *
> + * The role of the device init function consists of resetting the hardware or
> + * software event driver implementations.
> + *
> + * If the device init operation is successful, the correspondence between
> + * the device identifier assigned to the new device and its associated
> + * *rte_event_dev* structure is effectively registered.
> + * Otherwise, both the *rte_event_dev* structure and the device identifier are
> + * freed.
> + *
> + * The functions exported by the application Event API to setup a device
> + * designated by its device identifier must be invoked in the following order:
> + * - rte_event_dev_configure()
> + * - rte_event_queue_setup()
> + * - rte_event_port_setup()
> + * - rte_event_port_link()
> + * - rte_event_dev_start()
> + *
> + * Then, the application can invoke, in any order, the functions
> + * exported by the Event API to schedule events, dequeue events, enqueue
> events,
> + * change event queue(s) to event port [un]link establishment and so on.
> + *
> + * Application may use rte_event_[queue/port]_default_conf_get() to get the
> + * default configuration to set up an event queue or event port by
> + * overriding few default values.
> + *
> + * If the application wants to change the configuration (i.e. call
> + * rte_event_dev_configure(), rte_event_queue_setup(), or
> + * rte_event_port_setup()), it must call rte_event_dev_stop() first to stop the
> + * device and then do the reconfiguration before calling rte_event_dev_start()
> + * again. The schedule, enqueue and dequeue functions should not be invoked
> + * when the device is stopped.
> + *
> + * Finally, an application can close an Event device by invoking the
> + * rte_event_dev_close() function.
> + *
> + * Each function of the application Event API invokes a specific function
> + * of the PMD that controls the target device designated by its device
> + * identifier.
> + *
> + * For this purpose, all device-specific functions of an Event driver are
> + * supplied through a set of pointers contained in a generic structure of type
> + * *event_dev_ops*.
> + * The address of the *event_dev_ops* structure is stored in the
> *rte_event_dev*
> + * structure by the device init function of the Event driver, which is
> + * invoked during the PCI/SoC device probing phase, as explained earlier.
> + *
> + * In other words, each function of the Event API simply retrieves the
> + * *rte_event_dev* structure associated with the device identifier and
> + * performs an indirect invocation of the corresponding driver function
> + * supplied in the *event_dev_ops* structure of the *rte_event_dev*
> structure.
> + *
> + * For performance reasons, the address of the fast-path functions of the
> + * Event driver is not contained in the *event_dev_ops* structure.
> + * Instead, they are directly stored at the beginning of the *rte_event_dev*
> + * structure to avoid an extra indirect memory access during their invocation.
> + *
> + * RTE event device drivers do not use interrupts for enqueue or dequeue
> + * operation. Instead, Event drivers export Poll-Mode enqueue and dequeue
> + * functions to applications.
> + *
> + * An event driven based application has following typical workflow on
> fastpath:
> + * \code{.c}
> + * while (1) {
> + *
> + * rte_event_schedule(dev_id);
> + *
> + * rte_event_dequeue(...);
> + *
> + * (event processing)
> + *
> + * rte_event_enqueue(...);
> + * }
> + * \endcode
> + *
> + * The *schedule* operation is intended to do event scheduling, and the
> + * *dequeue* operation returns the scheduled events. An implementation
> + * is free to define the semantics between *schedule* and *dequeue*. For
> + * example, a system based on a hardware scheduler can define its
> + * rte_event_schedule() to be an NOOP, whereas a software scheduler can use
> + * the *schedule* operation to schedule events.
> + *
> + * The events are injected to event device through *enqueue* operation by
> + * event producers in the system. The typical event producers are ethdev
> + * subsystem for generating packet events, core(SW) for generating events
> based
> + * on different stages of application processing, cryptodev for generating
> + * crypto work completion notification etc
> + *
> + * The *dequeue* operation gets one or more events from the event ports.
> + * The application process the events and send to downstream event queue
> through
> + * rte_event_enqueue() if it is an intermediate stage of event processing, on
> + * the final stage, the application may send to different subsystem like ethdev
> + * to send the packet/event on the wire using ethdev rte_eth_tx_burst() API.
> + *
> + */
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include <rte_pci.h>
> +#include <rte_dev.h>
> +#include <rte_devargs.h>
> +#include <rte_errno.h>
> +
> +/**
> + * Get the total number of event devices that have been successfully
> + * initialised.
> + *
> + * @return
> + * The total number of usable event devices.
> + */
> +extern uint8_t
> +rte_event_dev_count(void);
> +
> +/**
> + * Get the device identifier for the named event device.
> + *
> + * @param name
> + * Event device name to select the event device identifier.
> + *
> + * @return
> + * Returns event device identifier on success.
> + * - <0: Failure to find named event device.
> + */
> +extern uint8_t
> +rte_event_dev_get_dev_id(const char *name);
This return type should be int8_t, or some signed type, to support the failure case.
> +
> +/**
> + * Return the NUMA socket to which a device is connected.
> + *
> + * @param dev_id
> + * The identifier of the device.
> + * @return
> + * The NUMA socket id to which the device is connected or
> + * a default of zero if the socket could not be determined.
> + * - -1: dev_id value is out of range.
> + */
> +extern int
> +rte_event_dev_socket_id(uint8_t dev_id);
> +
> +/* Event device capability bitmap flags */
> +#define RTE_EVENT_DEV_CAP_QUEUE_QOS (1 << 0)
> +/**< Event scheduling prioritization is based on the priority associated with
> + * each event queue.
> + *
> + * \see rte_event_queue_setup(), RTE_EVENT_QUEUE_PRIORITY_NORMAL
> + */
> +#define RTE_EVENT_DEV_CAP_EVENT_QOS (1 << 1)
> +/**< Event scheduling prioritization is based on the priority associated with
> + * each event. Priority of each event is supplied in *rte_event* structure
> + * on each enqueue operation.
> + *
> + * \see rte_event_enqueue()
> + */
> +
> +/**
> + * Event device information
> + */
> +struct rte_event_dev_info {
> + const char *driver_name; /**< Event driver name */
> + struct rte_pci_device *pci_dev; /**< PCI information */
> + uint32_t min_dequeue_wait_ns;
> + /**< Minimum supported global dequeue wait delay(ns) by this device
> */
> + uint32_t max_dequeue_wait_ns;
> + /**< Maximum supported global dequeue wait delay(ns) by this device
> */
> + uint32_t dequeue_wait_ns;
> + /**< Configured global dequeue wait delay(ns) for this device */
> + uint8_t max_event_queues;
> + /**< Maximum event_queues supported by this device */
> + uint32_t max_event_queue_flows;
> + /**< Maximum supported flows in an event queue by this device*/
> + uint8_t max_event_queue_priority_levels;
> + /**< Maximum number of event queue priority levels by this device.
> + * Valid when the device has RTE_EVENT_DEV_CAP_QUEUE_QOS
> capability
> + */
> + uint8_t nb_event_queues;
> + /**< Configured number of event queues for this device */
> + uint8_t max_event_priority_levels;
> + /**< Maximum number of event priority levels by this device.
> + * Valid when the device has RTE_EVENT_DEV_CAP_EVENT_QOS
> capability
> + */
> + uint8_t max_event_ports;
> + /**< Maximum number of event ports supported by this device */
> + uint8_t nb_event_ports;
> + /**< Configured number of event ports for this device */
> + uint8_t max_event_port_dequeue_queue_depth;
> + /**< Maximum dequeue queue depth for any event port.
> + * Implementations can schedule N events at a time to an event port.
> + * A device that does not support bulk dequeue will set this as 1.
> + * \see rte_event_port_setup()
> + */
> + uint32_t max_event_port_enqueue_queue_depth;
> + /**< Maximum enqueue queue depth for any event port.
> Implementations
> + * can batch N events at a time to enqueue through event port
> + * \see rte_event_port_setup()
> + */
> + int32_t max_num_events;
> + /**< A *closed system* event dev has a limit on the number of events
> it
> + * can manage at a time. An *open system* event dev does not have a
> + * limit and will specify this as -1.
> + */
> + uint32_t event_dev_cap;
> + /**< Event device capabilities(RTE_EVENT_DEV_CAP_)*/
> +};
> +
> +/**
> + * Retrieve the contextual information of an event device.
> + *
> + * @param dev_id
> + * The identifier of the device.
> + *
> + * @param[out] dev_info
> + * A pointer to a structure of type *rte_event_dev_info* to be filled with the
> + * contextual information of the device.
> + *
> + */
> +extern void
> +rte_event_dev_info_get(uint8_t dev_id, struct rte_event_dev_info
> *dev_info);
I'm wondering if this return type should be int, so we can return an error if the dev_id is invalid.
> +
> +/* Event device configuration bitmap flags */
> +#define RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT (1 << 0)
> +/**< Override the global *dequeue_wait_ns* and use per dequeue wait in ns.
> + * \see rte_event_dequeue_wait_time(), rte_event_dequeue()
> + */
> +
> +/** Event device configuration structure */
> +struct rte_event_dev_config {
> + uint32_t dequeue_wait_ns;
> + /**< rte_event_dequeue() wait for *dequeue_wait_ns* ns on this
> device.
> + * This value should be in the range of *min_dequeue_wait_ns* and
> + * *max_dequeue_wait_ns* which previously provided in
> + * rte_event_dev_info_get()
> + * \see RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT
> + */
> + int32_t nb_events_limit;
> + /**< Applies to *closed system* event dev only. This field indicates a
> + * limit to ethdev-like devices to limit the number of events injected
> + * into the system to not overwhelm core-to-core events.
> + * This value cannot exceed the *max_num_events* which previously
> + * provided in rte_event_dev_info_get()
> + */
> + uint8_t nb_event_queues;
> + /**< Number of event queues to configure on this device.
> + * This value cannot exceed the *max_event_queues* which previously
> + * provided in rte_event_dev_info_get()
> + */
> + uint8_t nb_event_ports;
> + /**< Number of event ports to configure on this device.
> + * This value cannot exceed the *max_event_ports* which previously
> + * provided in rte_event_dev_info_get()
> + */
> + uint32_t event_dev_cfg;
> + /**< Event device config flags(RTE_EVENT_DEV_CFG_)*/
> +};
> +
> +/**
> + * Configure an event device.
> + *
> + * This function must be invoked first before any other function in the
> + * API. This function can also be re-invoked when a device is in the
> + * stopped state.
> + *
> + * The caller may use rte_event_dev_info_get() to get the capability of each
> + * resources available for this event device.
> + *
> + * @param dev_id
> + * The identifier of the device to configure.
> + * @param config
> + * The event device configuration structure.
> + *
> + * @return
> + * - 0: Success, device configured.
> + * - <0: Error code returned by the driver configuration function.
> + */
> +extern int
> +rte_event_dev_configure(uint8_t dev_id, struct rte_event_dev_config
> *config);
> +
> +
> +/* Event queue specific APIs */
> +
> +#define RTE_EVENT_QUEUE_PRIORITY_HIGHEST 0
> +/**< Highest event queue priority */
> +#define RTE_EVENT_QUEUE_PRIORITY_NORMAL 128
> +/**< Normal event queue priority */
> +#define RTE_EVENT_QUEUE_PRIORITY_LOWEST 255
> +/**< Lowest event queue priority */
> +
> +/* Event queue configuration bitmap flags */
> +#define RTE_EVENT_QUEUE_CFG_SINGLE_CONSUMER (1 << 0)
> +/**< This event queue links only to a single event port.
> + *
> + * \see rte_event_port_setup(), rte_event_port_link()
> + */
> +
> +/** Event queue configuration structure */
> +struct rte_event_queue_conf {
> + uint32_t nb_atomic_flows;
> + /**< The maximum number of active flows this queue can track at any
> + * given time. The value must be in the range of
> + * [1 - max_event_queue_flows)] which previously supplied
> + * to rte_event_dev_configure().
> + */
> + uint32_t nb_atomic_order_sequences;
> + /**< The maximum number of outstanding events waiting to be
> (egress-)
> + * reordered by this queue. In other words, the number of entries in
> + * this queue’s reorder buffer.The value must be in the range of
> + * [1 - max_event_queue_flows)] which previously supplied
> + * to rte_event_dev_configure().
> + */
> + uint32_t event_queue_cfg; /**< Queue config
> flags(EVENT_QUEUE_CFG_) */
> + uint8_t priority;
> + /**< Priority for this event queue relative to other event queues.
> + * The requested priority should in the range of
> + * [RTE_EVENT_QUEUE_PRIORITY_HIGHEST,
> RTE_EVENT_QUEUE_PRIORITY_LOWEST].
> + * The implementation shall normalize the requested priority to
> + * event device supported priority value.
> + * Valid when the device has RTE_EVENT_DEV_CAP_QUEUE_QOS
> capability
> + */
> +};
> +
> +/**
> + * Retrieve the default configuration information of an event queue
> designated
> + * by its *queue_id* from the event driver for an event device.
> + *
> + * This function intended to be used in conjunction with
> rte_event_queue_setup()
> + * where caller needs to set up the queue by overriding few default values.
> + *
> + * @param dev_id
> + * The identifier of the device.
> + * @param queue_id
> + * The index of the event queue to get the configuration information.
> + * The value must be in the range [0, nb_event_queues - 1]
> + * previously supplied to rte_event_dev_configure().
> + * @param[out] queue_conf
> + * The pointer to the default event queue configuration data.
> + *
> + * \see rte_event_queue_setup()
> + *
> + */
> +extern void
> +rte_event_queue_default_conf_get(uint8_t dev_id, uint8_t queue_id,
> + struct rte_event_queue_conf *queue_conf);
> +
> +/**
> + * Allocate and set up an event queue for an event device.
> + *
> + * @param dev_id
> + * The identifier of the device.
> + * @param queue_id
> + * The index of the event queue to setup. The value must be in the range
> + * [0, nb_event_queues - 1] previously supplied to
> rte_event_dev_configure().
> + * @param queue_conf
> + * The pointer to the configuration data to be used for the event queue.
> + * NULL value is allowed, in which case default configuration used.
> + *
> + * \see rte_event_queue_default_conf_get()
> + *
> + * @return
> + * - 0: Success, event queue correctly set up.
> + * - <0: event queue configuration failed
> + */
> +extern int
> +rte_event_queue_setup(uint8_t dev_id, uint8_t queue_id,
> + struct rte_event_queue_conf *queue_conf);
> +
> +/**
> + * Get the number of event queues on a specific event device
> + *
> + * @param dev_id
> + * Event device identifier.
> + * @return
> + * - The number of configured event queues
> + */
> +extern uint16_t
> +rte_event_queue_count(uint8_t dev_id);
> +
> +/**
> + * Get the priority of the event queue on a specific event device
> + *
> + * @param dev_id
> + * Event device identifier.
> + * @param queue_id
> + * Event queue identifier.
> + * @return
> + * - If the device has RTE_EVENT_DEV_CAP_QUEUE_QOS capability then the
> + * configured priority of the event queue in
> + * [RTE_EVENT_QUEUE_PRIORITY_HIGHEST,
> RTE_EVENT_QUEUE_PRIORITY_LOWEST] range
> + * else the value one
> + */
> +extern uint8_t
> +rte_event_queue_priority(uint8_t dev_id, uint8_t queue_id);
> +
> +/* Event port specific APIs */
> +
> +/** Event port configuration structure */
> +struct rte_event_port_conf {
> + int32_t new_event_threshold;
> + /**< A backpressure threshold for new event enqueues on this port.
> + * Use for *closed system* event dev where event capacity is limited,
> + * and cannot exceed the capacity of the event dev.
> + * Configuring ports with different thresholds can make higher priority
> + * traffic less likely to be backpressured.
> + * For example, a port used to inject NIC Rx packets into the event dev
> + * can have a lower threshold so as not to overwhelm the device,
> + * while ports used for worker pools can have a higher threshold.
> + */
> + uint8_t dequeue_queue_depth;
> + /**< Configure number of bulk dequeues for this event port.
> + * This value cannot exceed the
> *max_event_port_dequeue_queue_depth*
> + * which previously supplied to rte_event_dev_configure()
> + */
> + uint8_t enqueue_queue_depth;
> + /**< Configure number of bulk enqueues for this event port.
> + * This value cannot exceed the
> *max_event_port_enqueue_queue_depth*
> + * which previously supplied to rte_event_dev_configure()
> + */
> +};
> +
> +/**
> + * Retrieve the default configuration information of an event port designated
> + * by its *port_id* from the event driver for an event device.
> + *
> + * This function intended to be used in conjunction with
> rte_event_port_setup()
> + * where caller needs to set up the port by overriding few default values.
> + *
> + * @param dev_id
> + * The identifier of the device.
> + * @param port_id
> + * The index of the event port to get the configuration information.
> + * The value must be in the range [0, nb_event_ports - 1]
> + * previously supplied to rte_event_dev_configure().
> + * @param[out] port_conf
> + * The pointer to the default event port configuration data
> + *
> + * \see rte_event_port_setup()
> + *
> + */
> +extern void
> +rte_event_port_default_conf_get(uint8_t dev_id, uint8_t port_id,
> + struct rte_event_port_conf *port_conf);
> +
> +/**
> + * Allocate and set up an event port for an event device.
> + *
> + * @param dev_id
> + * The identifier of the device.
> + * @param port_id
> + * The index of the event port to setup. The value must be in the range
> + * [0, nb_event_ports - 1] previously supplied to rte_event_dev_configure().
> + * @param port_conf
> + * The pointer to the configuration data to be used for the queue.
> + * NULL value is allowed, in which case default configuration used.
> + *
> + * \see rte_event_port_default_conf_get()
> + *
> + * @return
> + * - 0: Success, event port correctly set up.
> + * - <0: Port configuration failed
> + * - (-EDQUOT) Quota exceeded(Application tried to link the queue
> configured
> + * with RTE_EVENT_QUEUE_CFG_SINGLE_CONSUMER to more than one
> event ports)
> + */
> +extern int
> +rte_event_port_setup(uint8_t dev_id, uint8_t port_id,
> + struct rte_event_port_conf *port_conf);
> +
> +/**
> + * Get the number of dequeue queue depth configured for event port
> designated
> + * by its *port_id* on a specific event device
> + *
> + * @param dev_id
> + * Event device identifier.
> + * @param port_id
> + * Event port identifier.
> + * @return
> + * - The number of configured dequeue queue depth
> + *
> + * \see rte_event_dequeue_burst()
> + */
> +extern uint8_t
> +rte_event_port_dequeue_depth(uint8_t dev_id, uint8_t port_id);
> +
> +/**
> + * Get the number of enqueue queue depth configured for event port
> designated
> + * by its *port_id* on a specific event device
> + *
> + * @param dev_id
> + * Event device identifier.
> + * @param port_id
> + * Event port identifier.
> + * @return
> + * - The number of configured enqueue queue depth
> + *
> + * \see rte_event_enqueue_burst()
> + */
> +extern uint8_t
> +rte_event_port_enqueue_depth(uint8_t dev_id, uint8_t port_id);
> +
> +/**
> + * Get the number of ports on a specific event device
> + *
> + * @param dev_id
> + * Event device identifier.
> + * @return
> + * - The number of configured ports
> + */
> +extern uint8_t
> +rte_event_port_count(uint8_t dev_id);
> +
> +/**
> + * Start an event device.
> + *
> + * The device start step is the last one and consists of setting the event
> + * queues to start accepting the events and schedules to event ports.
> + *
> + * On success, all basic functions exported by the API (event enqueue,
> + * event dequeue and so on) can be invoked.
> + *
> + * @param dev_id
> + * Event device identifier
> + * @return
> + * - 0: Success, device started.
> + * - <0: Error code of the driver device start function.
> + */
> +extern int
> +rte_event_dev_start(uint8_t dev_id);
> +
> +/**
> + * Stop an event device. The device can be restarted with a call to
> + * rte_event_dev_start()
> + *
> + * @param dev_id
> + * Event device identifier.
> + */
> +extern void
> +rte_event_dev_stop(uint8_t dev_id);
> +
> +/**
> + * Close an event device. The device cannot be restarted!
> + *
> + * @param dev_id
> + * Event device identifier
> + *
> + * @return
> + * - 0 on successfully closing device
> + * - <0 on failure to close device
> + */
> +extern int
> +rte_event_dev_close(uint8_t dev_id);
> +
> +/* Scheduler type definitions */
> +#define RTE_SCHED_TYPE_ORDERED 0
> +/**< Ordered scheduling
> + *
> + * Events from an ordered flow of an event queue can be scheduled to
> multiple
> + * ports for concurrent processing while maintaining the original event order.
> + * This scheme enables the user to achieve high single flow throughput by
> + * avoiding SW synchronization for ordering between ports which bound to
> cores.
> + *
> + * The source flow ordering from an event queue is maintained when events
> are
> + * enqueued to their destination queue within the same ordered flow context.
> + * An event port holds the context until application call rte_event_dequeue()
> + * from the same port, which implicitly releases the context.
> + * User may allow the scheduler to release the context earlier than that
> + * by calling rte_event_release()
> + *
> + * Events from the source queue appear in their original order when dequeued
> + * from a destination queue.
> + * Event ordering is based on the received event(s), but also other
> + * (newly allocated or stored) events are ordered when enqueued within the
> same
> + * ordered context. Events not enqueued (e.g. released or stored) within the
> + * context are considered missing from reordering and are skipped at this
> time
> + * (but can be ordered again within another context).
> + *
> + * \see rte_event_dequeue(), rte_event_release()
> + */
> +
> +#define RTE_SCHED_TYPE_ATOMIC 1
> +/**< Atomic scheduling
> + *
> + * Events from an atomic flow of an event queue can be scheduled only to a
> + * single port at a time. The port is guaranteed to have exclusive (atomic)
> + * access to the associated flow context, which enables the user to avoid SW
> + * synchronization. Atomic flows also help to maintain event ordering
> + * since only one port at a time can process events from a flow of an
> + * event queue.
> + *
> + * The atomic queue synchronization context is dedicated to the port until
> + * application call rte_event_dequeue() from the same port, which implicitly
> + * releases the context. User may allow the scheduler to release the context
> + * earlier than that by calling rte_event_release()
> + *
> + * \see rte_event_dequeue(), rte_event_release()
> + */
> +
> +#define RTE_SCHED_TYPE_PARALLEL 2
> +/**< Parallel scheduling
> + *
> + * The scheduler performs priority scheduling, load balancing, etc. functions
> + * but does not provide additional event synchronization or ordering.
> + * It is free to schedule events from a single parallel flow of an event queue
> + * to multiple events ports for concurrent processing.
> + * The application is responsible for flow context synchronization and
> + * event ordering (SW synchronization).
> + */
> +
> +/* Event types to classify the event source */
> +#define RTE_EVENT_TYPE_ETHDEV 0x0
> +/**< The event generated from ethdev subsystem */
> +#define RTE_EVENT_TYPE_CRYPTODEV 0x1
> +/**< The event generated from crypodev subsystem */
> +#define RTE_EVENT_TYPE_TIMERDEV 0x2
> +/**< The event generated from timerdev subsystem */
> +#define RTE_EVENT_TYPE_CORE 0x3
> +/**< The event generated from core.
> + * Application may use *sub_event_type* to further classify the event
> + */
> +#define RTE_EVENT_TYPE_MAX 0x10
> +/**< Maximum number of event types */
> +
> +/* Event priority */
> +#define RTE_EVENT_PRIORITY_HIGHEST 0
> +/**< Highest event priority */
> +#define RTE_EVENT_PRIORITY_NORMAL 128
> +/**< Normal event priority */
> +#define RTE_EVENT_PRIORITY_LOWEST 255
> +/**< Lowest event priority */
> +
> +/**
> + * The generic *rte_event* structure to hold the event attributes
> + * for dequeue and enqueue operation
> + */
> +struct rte_event {
> + /** WORD0 */
> + RTE_STD_C11
> + union {
> + uint64_t u64;
> + /** Event attributes for dequeue or enqueue operation */
> + struct {
> + uint32_t flow_id:24;
> + /**< Targeted flow identifier for the enqueue and
> + * dequeue operation.
> + * The value must be in the range of
> + * [1 - max_event_queue_flows)] which
> + * previously supplied to rte_event_dev_configure().
> + */
> + uint32_t queue_id:8;
> + /**< Targeted event queue identifier for the enqueue
> or
> + * dequeue operation.
> + * The value must be in the range of
> + * [0, nb_event_queues - 1] which previously supplied
> to
> + * rte_event_dev_configure().
> + */
> + uint8_t sched_type;
> + /**< Scheduler synchronization type
> (RTE_SCHED_TYPE_)
> + * associated with flow id on a given event queue
> + * for the enqueue and dequeue operation.
> + */
> + uint8_t event_type;
> + /**< Event type to classify the event source. */
> + uint8_t sub_event_type;
> + /**< Sub-event types based on the event source.
> + * \see RTE_EVENT_TYPE_CORE
> + */
> + uint8_t priority;
> + /**< Event priority relative to other events in the
> + * event queue. The requested priority should in the
> + * range of [RTE_EVENT_PRIORITY_HIGHEST,
> + * RTE_EVENT_PRIORITY_LOWEST].
> + * The implementation shall normalize the requested
> + * priority to supported priority value.
> + * Valid when the device has
> RTE_EVENT_DEV_CAP_EVENT_QOS
> + * capability.
> + */
> + };
> + };
> + /** WORD1 */
> + RTE_STD_C11
> + union {
> + uintptr_t event;
> + /**< Opaque event pointer */
> + struct rte_mbuf *mbuf;
> + /**< mbuf pointer if dequeued event is associated with mbuf
> */
> + };
> +};
> +
> +/**
> + * Schedule one or more events in the event dev.
> + *
> + * An event dev implementation may define this is a NOOP, for instance if
> + * the event dev performs its scheduling in hardware.
> + *
> + * @param dev_id
> + * The identifier of the device.
> + */
> +extern void
> +rte_event_schedule(uint8_t dev_id);
One idea: Have the function return the number of scheduled packets (or 0 for implementations that do scheduling in hardware). This could be a helpful diagnostic for the software scheduler.
> +
> +/**
> + * Enqueue the event object supplied in the *rte_event* structure on an
> + * event device designated by its *dev_id* through the event port specified by
> + * *port_id*. The event object specifies the event queue on which this
> + * event will be enqueued.
> + *
> + * @param dev_id
> + * Event device identifier.
> + * @param port_id
> + * The identifier of the event port.
> + * @param ev
> + * Pointer to struct rte_event
> + * @param pin_event
> + * Hint to the scheduler that the event can be pinned to the same port for
> + * the next scheduling stage. For implementations that support it, this
> + * allows the same core to process the next stage in the pipeline for a given
> + * event, taking advantage of cache locality. The pinned event will be
> + * received through rte_event_dequeue(). This is a hint and the event is
> + * not guaranteed to be pinned to the port. This hint is valid only when the
> + * event is dequeued with rte_event_dequeue() followed by
> rte_event_enqueue().
> + *
> + * @return
> + * - 0 on success
> + * - <0 on failure. Failure can occur if the event port's output queue is
> + * backpressured, for instance.
> + */
> +extern int
> +rte_event_enqueue(uint8_t dev_id, uint8_t port_id, struct rte_event *ev,
> + bool pin_event);
> +
> +/**
> + * Enqueue a burst of events objects supplied in *rte_event* structure on an
> + * event device designated by its *dev_id* through the event port specified by
> + * *port_id*. Each event object specifies the event queue on which it
> + * will be enqueued.
> + *
> + * The rte_event_enqueue_burst() function is invoked to enqueue
> + * multiple event objects.
> + * It is the burst variant of rte_event_enqueue() function.
> + *
> + * The *num* parameter is the number of event objects to enqueue which are
> + * supplied in the *ev* array of *rte_event* structure.
> + *
> + * The rte_event_enqueue_burst() function returns the number of
> + * events objects it actually enqueued. A return value equal to *num* means
> + * that all event objects have been enqueued.
> + *
> + * @param dev_id
> + * The identifier of the device.
> + * @param port_id
> + * The identifier of the event port.
> + * @param ev
> + * An array of *num* pointers to *rte_event* structure
> + * which contain the event object enqueue operations to be processed.
> + * @param num
> + * The number of event objects to enqueue, typically number of
> + * rte_event_port_enqueue_depth() available for this port.
> + * @param pin_event
> + * Hint to the scheduler that the event can be pinned to the same port for
> + * the next scheduling stage. For implementations that support it, this
> + * allows the same core to process the next stage in the pipeline for a given
> + * event, taking advantage of cache locality. The pinned event will be
> + * received through rte_event_dequeue(). This is a hint and the event is
> + * not guaranteed to be pinned to the port. This hint is valid only when the
> + * event is dequeued with rte_event_dequeue() followed by
> rte_event_enqueue().
> + *
> + * @return
> + * The number of event objects actually enqueued on the event device. The
> + * return value can be less than the value of the *num* parameter when the
> + * event devices queue is full or if invalid parameters are specified in a
> + * *rte_event*. If return value is less than *num*, the remaining events at
> + * the end of ev[] are not consumed, and the caller has to take care of them.
> + *
> + * \see rte_event_enqueue(), rte_event_port_enqueue_depth()
> + */
> +extern int
> +rte_event_enqueue_burst(uint8_t dev_id, uint8_t port_id,
> + struct rte_event ev[], int num, bool pin_event);
> +
> +/**
> + * Converts nanoseconds to *wait* value for rte_event_dequeue()
> + *
> + * If the device is configured with
> RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT flag then
> + * application can use this function to convert wait value in nanoseconds to
> + * implementations specific wait value supplied in rte_event_dequeue()
> + *
> + * @param dev_id
> + * The identifier of the device.
> + * @param ns
> + * Wait time in nanosecond
> + *
> + * @return
> + * Value for the *wait* parameter in rte_event_dequeue() function
> + *
> + * \see rte_event_dequeue(), RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT
> + * \see rte_event_dev_configure()
> + *
> + */
> +extern uint64_t
> +rte_event_dequeue_wait_time(uint8_t dev_id, uint64_t ns);
> +
> +/**
> + * Dequeue an event from the event port specified by *port_id* on the
> + * event device designated by its *dev_id*.
> + *
> + * rte_event_dequeue() does not dictate the specifics of scheduling algorithm
> as
> + * each eventdev driver may have different criteria to schedule an event.
> + * However, in general, from an application perspective scheduler may use the
> + * following scheme to dispatch an event to the port.
> + *
> + * 1) Selection of event queue based on
> + * a) The list of event queues are linked to the event port.
> + * b) If the device has RTE_EVENT_DEV_CAP_QUEUE_QOS capability then
> event
> + * queue selection from list is based on event queue priority relative to
> + * other event queue supplied as *priority* in rte_event_queue_setup()
> + * c) If the device has RTE_EVENT_DEV_CAP_EVENT_QOS capability then
> event
> + * queue selection from the list is based on event priority supplied as
> + * *priority* in rte_event_enqueue_burst()
> + * 2) Selection of event
> + * a) The number of flows available in selected event queue.
> + * b) Schedule type method associated with the event
> + *
> + * On a successful dequeue, the event port holds flow id and schedule type
> + * context associated with the dispatched event. The context is automatically
> + * released in the next rte_event_dequeue() invocation, or rte_event_release()
> + * can be called to release the context early.
> + *
> + * @param dev_id
> + * The identifier of the device.
> + * @param port_id
> + * The identifier of the event port.
> + * @param[out] ev
> + * Pointer to struct rte_event. On successful event dispatch, implementation
> + * updates the event attributes.
> + * @param wait
> + * 0 - no-wait, returns immediately if there is no event.
> + * >0 - wait for the event, if the device is configured with
> + * RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT then this function will wait
> until
> + * the event available or *wait* time.
> + * if the device is not configured with
> RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT
> + * then this function will wait until the event available or *dequeue_wait_ns*
> + * ns which was previously supplied to rte_event_dev_configure()
> + *
> + * @return
> + * When true, a valid event has been dispatched by the scheduler.
> + *
> + */
> +extern bool
> +rte_event_dequeue(uint8_t dev_id, uint8_t port_id,
> + struct rte_event *ev, uint64_t wait);
> +
> +/**
> + * Dequeue a burst of events objects from the event port designated by its
> + * *event_port_id*, on an event device designated by its *dev_id*.
> + *
> + * The rte_event_dequeue_burst() function is invoked to dequeue
> + * multiple event objects. It is the burst variant of rte_event_dequeue()
> + * function.
> + *
> + * The *num* parameter is the maximum number of event objects to dequeue
> which
> + * are returned in the *ev* array of *rte_event* structure.
> + *
> + * The rte_event_dequeue_burst() function returns the number of
> + * events objects it actually dequeued. A return value equal to
> + * *num* means that all event objects have been dequeued.
> + *
> + * The number of events dequeued is the number of scheduler contexts held
> by
> + * this port. These contexts are automatically released in the next
> + * rte_event_dequeue() invocation, or rte_event_release() can be called once
> + * per event to release the contexts early.
> + *
> + * @param dev_id
> + * The identifier of the device.
> + * @param port_id
> + * The identifier of the event port.
> + * @param[out] ev
> + * An array of *num* pointers to *rte_event* structure which is populated
> + * with the dequeued event objects.
> + * @param num
> + * The maximum number of event objects to dequeue, typically number of
> + * rte_event_port_dequeue_depth() available for this port.
> + * @param wait
> + * 0 - no-wait, returns immediately if there is no event.
> + * >0 - wait for the event, if the device is configured with
> + * RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT then this function will wait
> until the
> + * event available or *wait* time.
> + * if the device is not configured with
> RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT
> + * then this function will wait until the event available or *dequeue_wait_ns*
> + * ns which was previously supplied to rte_event_dev_configure()
> + *
> + * @return
> + * The number of event objects actually dequeued from the port. The return
> + * value can be less than the value of the *num* parameter when the
> + * event port's queue is not full.
> + *
> + * \see rte_event_dequeue(), rte_event_port_dequeue_depth()
> + */
> +extern int
> +rte_event_dequeue_burst(uint8_t dev_id, uint8_t port_id,
> + struct rte_event *ev, int num, uint64_t wait);
> +
> +/**
> + * Release the current flow context associated with a schedule type which
> + * dequeued from a given event queue though the event port designated by
> + * its *port_id*
> + *
> + * If current flow's scheduler type method is *RTE_SCHED_TYPE_ATOMIC*
> + * then this function hints the scheduler that the user has completed critical
> + * section processing in the current atomic context.
> + * The scheduler is now allowed to schedule events from the same flow from
> + * an event queue to another port. However, the context may be still held
> + * until the next rte_event_dequeue() or rte_event_dequeue_burst() call, this
> + * call allows but does not force the scheduler to release the context early.
> + *
> + * Early atomic context release may increase parallelism and thus system
> + * performance, but the user needs to design carefully the split into critical
> + * vs non-critical sections.
> + *
> + * If current flow's scheduler type method is *RTE_SCHED_TYPE_ORDERED*
> + * then this function hints the scheduler that the user has done all that need
> + * to maintain event order in the current ordered context.
> + * The scheduler is allowed to release the ordered context of this port and
> + * avoid reordering any following enqueues.
> + *
> + * Early ordered context release may increase parallelism and thus system
> + * performance.
> + *
> + * If current flow's scheduler type method is *RTE_SCHED_TYPE_PARALLEL*
> + * or no scheduling context is held then this function may be an NOOP,
> + * depending on the implementation.
> + *
> + * If multiple events are dequeued with rte_event_dequeue_burst(),
> + * rte_event_release() will release each flow context associated with a
> + * schedule type of an event though *index*, it denotes the order in
> + * which it was dequeued with rte_event_dequeue_burst()
> + *
> + * @param dev_id
> + * The identifier of the device.
> + * @param port_id
> + * The identifier of the event port.
> + * @param index
> + * The index of the event that dequeued with rte_event_dequeue_burst()
> + * which needs to release. The value zero used if the event dequeued with
> + * rte_event_dequeue()
> + *
> + * \see rte_event_dequeue(), rte_event_dequeue_burst()
> + */
> +extern void
> +rte_event_release(uint8_t dev_id, uint8_t port_id, uint8_t index);
> +
> +#define RTE_EVENT_QUEUE_SERVICE_PRIORITY_HIGHEST 0
> +/**< Highest event queue servicing priority */
> +#define RTE_EVENT_QUEUE_SERVICE_PRIORITY_NORMAL 128
> +/**< Normal event queue servicing priority */
> +#define RTE_EVENT_QUEUE_SERVICE_PRIORITY_LOWEST 255
> +/**< Lowest event queue servicing priority */
> +
> +/** Structure to hold the queue to port link establishment attributes */
> +struct rte_event_queue_link {
> + uint8_t queue_id;
> + /**< Event queue identifier to select the source queue to link */
> + uint8_t priority;
> + /**< The priority of the event queue for this event port.
> + * The priority defines the event port's servicing priority for
> + * event queue, which may be ignored by an implementation.
> + * The requested priority should in the range of
> + * [RTE_EVENT_QUEUE_SERVICE_PRIORITY_HIGHEST,
> + * RTE_EVENT_QUEUE_SERVICE_PRIORITY_LOWEST].
> + * The implementation shall normalize the requested priority to
> + * implementation supported priority value.
> + */
> +};
> +
> +/**
> + * Link multiple source event queues supplied in *rte_event_queue_link*
> + * structure as *queue_id* to the destination event port designated by its
> + * *port_id* on the event device designated by its *dev_id*.
> + *
> + * The link establishment shall enable the event port *port_id* from
> + * receiving events from the specified event queue *queue_id*
> + *
> + * An event queue may link to one or more event ports.
> + * The number of links can be established from an event queue to event port is
> + * implementation defined.
> + *
> + * Event queue(s) to event port link establishment can be changed at runtime
> + * without re-configuring the device to support scaling and to reduce the
> + * latency of critical work by establishing the link with more event ports
> + * at runtime.
> + *
> + * @param dev_id
> + * The identifier of the device.
> + *
> + * @param port_id
> + * Event port identifier to select the destination port to link.
> + *
> + * @param link
> + * An array of *num* pointers to *rte_event_queue_link* structure
> + * which contain the event queue to event port link establishment attributes.
> + * NULL value is allowed, in which case this function links all the configured
> + * event queues *nb_event_queues* which previously supplied to
> + * rte_event_dev_configure() to the event port *port_id* with normal
> servicing
> + * priority(RTE_EVENT_QUEUE_SERVICE_PRIORITY_NORMAL).
> + *
> + * @param num
> + * The number of links to establish
> + *
> + * @return
> + * The number of links actually established on the event device. The return
> + * value can be less than the value of the *num* parameter when the
> + * implementation has the limitation on specific queue to port link
> + * establishment or if invalid parameters are specified
> + * in a *rte_event_queue_link*.
> + * If the return value is less than *num*, the remaining links at the end of
> + * link[] are not established, and the caller has to take care of them.
> + * If return value is less than *num* then implementation shall update the
> + * rte_errno accordingly, Possible rte_errno values are
> + * (-EDQUOT) Quota exceeded(Application tried to link the queue configured
> with
> + * RTE_EVENT_QUEUE_CFG_SINGLE_CONSUMER to more than one event
> ports)
> + * (-EINVAL) Invalid parameter
> + *
> + */
> +extern int
> +rte_event_port_link(uint8_t dev_id, uint8_t port_id,
> + struct rte_event_queue_link link[], int num);
> +
> +/**
> + * Unlink multiple source event queues supplied in *queues* from the
> destination
> + * event port designated by its *port_id* on the event device designated
> + * by its *dev_id*.
> + *
> + * The unlink establishment shall disable the event port *port_id* from
> + * receiving events from the specified event queue *queue_id*
> + *
> + * Event queue(s) to event port unlink establishment can be changed at
> runtime
> + * without re-configuring the device.
> + *
> + * @param dev_id
> + * The identifier of the device.
> + *
> + * @param port_id
> + * Event port identifier to select the destination port to unlink.
> + *
> + * @param queues
> + * An array of *num* event queues to be unlinked from the event port.
> + * NULL value is allowed, in which case this function unlinks all the
> + * event queue(s) from the event port *port_id*.
> + *
> + * @param num
> + * The number of unlinks to establish
> + *
> + * @return
> + * The number of unlinks actually established on the event device. The return
> + * value can be less than the value of the *num* parameter when the
> + * implementation has the limitation on specific queue to port unlink
> + * establishment or if invalid parameters are specified.
> + * If the return value is less than *num*, the remaining queues at the end of
> + * queues[] are not established, and the caller has to take care of them.
> + * If return value is less than *num* then implementation shall update the
> + * rte_errno accordingly, Possible rte_errno values are
> + * (-EINVAL) Invalid parameter
> + *
> + */
> +extern int
> +rte_event_port_unlink(uint8_t dev_id, uint8_t port_id,
> + uint8_t queues[], int num);
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* _RTE_EVENTDEV_H_ */
> --
> 2.5.5
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Francois Ozog @ 2016-10-14 15:00 UTC (permalink / raw)
To: dev, EXT Jacob, Jerin
Cc: Thomas Monjalon, bruce.richardson, narender.vangati,
hemant.agrawal, gage.eads
Dear Jerin,
Very nice work!
This new RFC version opens the way to a unified conceptual model of
Software Defined Data Planes supported by diverse implementations such
as OpenDataPlane and DPDK.
I think this is an important signal to the industry.
François-Frédéric
________________________________
From: dev <dev-bounces@dpdk.org> on behalf of Jerin Jacob
<jerin.jacob@caviumnetworks.com>
Sent: Tuesday, October 11, 2016 9:30 PM
To: dev@dpdk.org
Cc: thomas.monjalon@6wind.com; bruce.richardson@intel.com;
narender.vangati@intel.com; hemant.agrawal@nxp.com;
gage.eads@intel.com; Jerin Jacob
Subject: [dpdk-dev] [RFC] [PATCH v2] libeventdev: event driven
programming model framework for DPDK
Thanks to Intel and NXP folks for the positive and constructive feedback
I've received so far. Here is the updated RFC(v2).
I've attempted to address as many comments as possible.
This series adds rte_eventdev.h to the DPDK tree with
adequate documentation in doxygen format.
Updates are also available online:
Related draft header file (this patch):
https://rawgit.com/jerinjacobk/libeventdev/master/rte_eventdev.h
PDF version(doxgen output):
https://rawgit.com/jerinjacobk/libeventdev/master/librte_eventdev_v2.pdf
Repo:
https://github.com/jerinjacobk/libeventdev
v1..v2
- Added Cavium, Intel, NXP copyrights in header file
- Changed the concept of flow queues to flow ids.
This is avoid dictating a specific structure to hold the flows.
A s/w implementation can do atomic load balancing on multiple
flow ids more efficiently than maintaining each event in a specific flow queue.
- Change the scheduling group to event queue.
A scheduling group is more a stream of events, so an event queue is a better
abstraction.
- Introduced event port concept, Instead of trying eventdev access to the lcore,
a higher level of abstraction called event port is needed which is the
application i/f to the eventdev to dequeue and enqueue the events.
One or more event queues can be linked to single event port.
There can be more than one event port per lcore allowing multiple lightweight
threads to have their own i/f into eventdev, if the implementation supports it.
An event port will be bound to a lcore or a lightweight thread to keep
portable application workflow.
An event port abstraction also encapsulates dequeue depth and enqueue depth for
a scheduler implementations which can schedule multiple events at a time and
output events that can be buffered.
- Added configuration options with event queue(nb_atomic_flows,
nb_atomic_order_sequences, single consumer etc)
and event port(dequeue_queue_depth, enqueue_queue_depth etc) to define the
limits on the resource usage.(Useful for optimized software implementation)
- Introduced RTE_EVENT_DEV_CAP_QUEUE_QOS and RTE_EVENT_DEV_CAP_EVENT_QOS
schemes of priority handling
- Added event port to event queue servicing priority.
This allows two event ports to connect to the same event queue with
different priorities.
- Changed the workflow as schedule/dequeue/enqueue.
An implementation is free to define schedule as NOOP.
A distributed s/w scheduler can use this to schedule events;
also a centralized s/w scheduler can make this a NOOP on non-scheduler cores.
- Removed Cavium HW specific schedule_from_group API
- Removed Cavium HW specific ctxt_update/ctxt_wait APIs.
Introduced a more generic "event pinning" concept. i.e
If the normal workflow is a dequeue -> do work based on event type -> enqueue,
a pin_event argument to enqueue
where the pinned event is returned through the normal dequeue)
allows application workflow to remain the same whether or not an
implementation supports it.
- Added dequeue() burst variant
- Added the definition of a closed/open system - where open system is memory
backed and closed system eventdev has limited capacity.
In such systems, it is also useful to denote per event port how many packets
can be active in the system.
This can serve as a threshold for ethdev like devices so they don't overwhelm
core to core events.
- Added the option to specify maximum amount of time(in ns) application needs
wait on dequeue()
- Removed the scheme of expressing the number of flows in log2 format
Open item or the item needs improvement.
----------------------------------------
- Abstract the differences in event QoS management with different
priority schemes
available in different HW or SW implementations with portable
application workflow.
Based on the feedback, there three different kinds of QoS support available in
three different HW or SW implementations.
1) Priority associated with the event queue
2) Priority associated with each event enqueue
(Same flow can have two different priority on two separate enqueue)
3) Priority associated with the flow(each flow has unique priority)
In v2, The differences abstracted based on device capability
(RTE_EVENT_DEV_CAP_QUEUE_QOS for the first scheme,
RTE_EVENT_DEV_CAP_EVENT_QOS for the second and third scheme).
This scheme would call for different application workflow for
nontrivial QoS-enabled applications.
Looking forward to getting comments from both application and driver
implementation perspective.
/Jerin
---
doc/api/doxy-api-index.md | 1 +
doc/api/doxy-api.conf | 1 +
lib/librte_eventdev/rte_eventdev.h | 1204 ++++++++++++++++++++++++++++++++++++
3 files changed, 1206 insertions(+)
create mode 100644 lib/librte_eventdev/rte_eventdev.h
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 6675f96..28c1329 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -40,6 +40,7 @@ There are many libraries, so their headers may be
grouped by topics:
[ethdev] (@ref rte_ethdev.h),
[ethctrl] (@ref rte_eth_ctrl.h),
[cryptodev] (@ref rte_cryptodev.h),
+ [eventdev] (@ref rte_eventdev.h),
[devargs] (@ref rte_devargs.h),
[bond] (@ref rte_eth_bond.h),
[vhost] (@ref rte_virtio_net.h),
diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf
index 9dc7ae5..9841477 100644
--- a/doc/api/doxy-api.conf
+++ b/doc/api/doxy-api.conf
@@ -41,6 +41,7 @@ INPUT = doc/api/doxy-api-index.md \
lib/librte_cryptodev \
lib/librte_distributor \
lib/librte_ether \
+ lib/librte_eventdev \
lib/librte_hash \
lib/librte_ip_frag \
lib/librte_jobstats \
diff --git a/lib/librte_eventdev/rte_eventdev.h
b/lib/librte_eventdev/rte_eventdev.h
new file mode 100644
index 0000000..f60e461
--- /dev/null
+++ b/lib/librte_eventdev/rte_eventdev.h
@@ -0,0 +1,1204 @@
+/*
+ * BSD LICENSE
+ *
+ * Copyright 2016 Cavium.
+ * Copyright 2016 Intel Corporation.
+ * Copyright 2016 NXP.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Cavium nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_EVENTDEV_H_
+#define _RTE_EVENTDEV_H_
+
+/**
+ * @file
+ *
+ * RTE Event Device API
+ *
+ * The Event Device API is composed of two parts:
+ *
+ * - The application-oriented Event API that includes functions to setup
+ * an event device (configure it, setup its queues, ports and start it), to
+ * establish the link between queues to port and to receive events,
and so on.
+ *
+ * - The driver-oriented Event API that exports a function allowing
+ * an event poll Mode Driver (PMD) to simultaneously register itself as
+ * an event device driver.
+ *
+ * Event device components:
+ *
+ * +-----------------+
+ * | +-------------+ |
+ * +-------+ | | flow 0 | |
+ * |Packet | | +-------------+ |
+ * |event | | +-------------+ |
+ * | | | | flow 1 | |event_port_link(port0, queue0)
+ * +-------+ | +-------------+ | | +--------+
+ * +-------+ | +-------------+ o-----v-----o |dequeue +------+
+ * |Crypto | | | flow n | | | event +------->|Core 0|
+ * |work | | +-------------+ o----+ | port 0 | | |
+ * |done ev| | event queue 0 | | +--------+ +------+
+ * +-------+ +-----------------+ |
+ * +-------+ |
+ * |Timer | +-----------------+ | +--------+
+ * |expiry | | +-------------+ | +------o |dequeue +------+
+ * |event | | | flow 0 | o-----------o event +------->|Core 1|
+ * +-------+ | +-------------+ | +----o port 1 | | |
+ * Event enqueue | +-------------+ | | +--------+ +------+
+ * o-------------> | | flow 1 | | |
+ * enqueue( | +-------------+ | |
+ * queue_id, | | | +--------+ +------+
+ * flow_id, | +-------------+ | | | |dequeue |Core 2|
+ * sched_type, | | flow n | o-----------o event +------->| |
+ * event_type, | +-------------+ | | | port 2 | +------+
+ * subev_type, | event queue 1 | | +--------+
+ * event) +-----------------+ | +--------+
+ * | | |dequeue +------+
+ * +-------+ +-----------------+ | | event +------->|Core n|
+ * |Core | | +-------------+ o-----------o port n | | |
+ * |(SW) | | | flow 0 | | | +--------+ +--+---+
+ * |event | | +-------------+ | | |
+ * +-------+ | +-------------+ | | |
+ * ^ | | flow 1 | | | |
+ * | | +-------------+ o------+ |
+ * | | +-------------+ | |
+ * | | | flow n | | |
+ * | | +-------------+ | |
+ * | | event queue n | |
+ * | +-----------------+ |
+ * | |
+ * +-----------------------------------------------------------+
+ *
+ *
+ *
+ * Event device: A hardware or software-based event scheduler.
+ *
+ * Event: A unit of scheduling that encapsulates a packet or other datatype
+ * like SW generated event from the core, Crypto work completion notification,
+ * Timer expiry event notification etc as well as metadata.
+ * The metadata includes flow ID, scheduling type, event priority, event_type,
+ * sub_event_type etc.
+ *
+ * Event queue: A queue containing events that are scheduled by the event dev.
+ * An event queue contains events of different flows associated with scheduling
+ * types, such as atomic, ordered, or parallel.
+ *
+ * Event port: An application's interface into the event dev for enqueue and
+ * dequeue operations. Each event port can be linked with one or more
+ * event queues for dequeue operations.
+ *
+ * By default, all the functions of the Event Device API exported by a PMD
+ * are lock-free functions which assume to not be invoked in parallel on
+ * different logical cores to work on the same target object. For instance,
+ * the dequeue function of a PMD cannot be invoked in parallel on two logical
+ * cores to operates on same event port. Of course, this function
+ * can be invoked in parallel by different logical cores on different ports.
+ * It is the responsibility of the upper level application to enforce
this rule.
+ *
+ * In all functions of the Event API, the Event device is
+ * designated by an integer >= 0 named the device identifier *dev_id*
+ *
+ * At the Event driver level, Event devices are represented by a generic
+ * data structure of type *rte_event_dev*.
+ *
+ * Event devices are dynamically registered during the PCI/SoC device probing
+ * phase performed at EAL initialization time.
+ * When an Event device is being probed, a *rte_event_dev* structure and
+ * a new device identifier are allocated for that device. Then, the
+ * event_dev_init() function supplied by the Event driver matching the probed
+ * device is invoked to properly initialize the device.
+ *
+ * The role of the device init function consists of resetting the hardware or
+ * software event driver implementations.
+ *
+ * If the device init operation is successful, the correspondence between
+ * the device identifier assigned to the new device and its associated
+ * *rte_event_dev* structure is effectively registered.
+ * Otherwise, both the *rte_event_dev* structure and the device identifier are
+ * freed.
+ *
+ * The functions exported by the application Event API to setup a device
+ * designated by its device identifier must be invoked in the following order:
+ * - rte_event_dev_configure()
+ * - rte_event_queue_setup()
+ * - rte_event_port_setup()
+ * - rte_event_port_link()
+ * - rte_event_dev_start()
+ *
+ * Then, the application can invoke, in any order, the functions
+ * exported by the Event API to schedule events, dequeue events,
enqueue events,
+ * change event queue(s) to event port [un]link establishment and so on.
+ *
+ * Application may use rte_event_[queue/port]_default_conf_get() to get the
+ * default configuration to set up an event queue or event port by
+ * overriding few default values.
+ *
+ * If the application wants to change the configuration (i.e. call
+ * rte_event_dev_configure(), rte_event_queue_setup(), or
+ * rte_event_port_setup()), it must call rte_event_dev_stop() first to stop the
+ * device and then do the reconfiguration before calling rte_event_dev_start()
+ * again. The schedule, enqueue and dequeue functions should not be invoked
+ * when the device is stopped.
+ *
+ * Finally, an application can close an Event device by invoking the
+ * rte_event_dev_close() function.
+ *
+ * Each function of the application Event API invokes a specific function
+ * of the PMD that controls the target device designated by its device
+ * identifier.
+ *
+ * For this purpose, all device-specific functions of an Event driver are
+ * supplied through a set of pointers contained in a generic structure of type
+ * *event_dev_ops*.
+ * The address of the *event_dev_ops* structure is stored in the
*rte_event_dev*
+ * structure by the device init function of the Event driver, which is
+ * invoked during the PCI/SoC device probing phase, as explained earlier.
+ *
+ * In other words, each function of the Event API simply retrieves the
+ * *rte_event_dev* structure associated with the device identifier and
+ * performs an indirect invocation of the corresponding driver function
+ * supplied in the *event_dev_ops* structure of the *rte_event_dev* structure.
+ *
+ * For performance reasons, the address of the fast-path functions of the
+ * Event driver is not contained in the *event_dev_ops* structure.
+ * Instead, they are directly stored at the beginning of the *rte_event_dev*
+ * structure to avoid an extra indirect memory access during their invocation.
+ *
+ * RTE event device drivers do not use interrupts for enqueue or dequeue
+ * operation. Instead, Event drivers export Poll-Mode enqueue and dequeue
+ * functions to applications.
+ *
+ * An event driven based application has following typical workflow
on fastpath:
+ * \code{.c}
+ * while (1) {
+ *
+ * rte_event_schedule(dev_id);
+ *
+ * rte_event_dequeue(...);
+ *
+ * (event processing)
+ *
+ * rte_event_enqueue(...);
+ * }
+ * \endcode
+ *
+ * The *schedule* operation is intended to do event scheduling, and the
+ * *dequeue* operation returns the scheduled events. An implementation
+ * is free to define the semantics between *schedule* and *dequeue*. For
+ * example, a system based on a hardware scheduler can define its
+ * rte_event_schedule() to be an NOOP, whereas a software scheduler can use
+ * the *schedule* operation to schedule events.
+ *
+ * The events are injected to event device through *enqueue* operation by
+ * event producers in the system. The typical event producers are ethdev
+ * subsystem for generating packet events, core(SW) for generating events based
+ * on different stages of application processing, cryptodev for generating
+ * crypto work completion notification etc
+ *
+ * The *dequeue* operation gets one or more events from the event ports.
+ * The application process the events and send to downstream event
queue through
+ * rte_event_enqueue() if it is an intermediate stage of event processing, on
+ * the final stage, the application may send to different subsystem like ethdev
+ * to send the packet/event on the wire using ethdev rte_eth_tx_burst() API.
+ *
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <rte_pci.h>
+#include <rte_dev.h>
+#include <rte_devargs.h>
+#include <rte_errno.h>
+
+/**
+ * Get the total number of event devices that have been successfully
+ * initialised.
+ *
+ * @return
+ * The total number of usable event devices.
+ */
+extern uint8_t
+rte_event_dev_count(void);
+
+/**
+ * Get the device identifier for the named event device.
+ *
+ * @param name
+ * Event device name to select the event device identifier.
+ *
+ * @return
+ * Returns event device identifier on success.
+ * - <0: Failure to find named event device.
+ */
+extern uint8_t
+rte_event_dev_get_dev_id(const char *name);
+
+/**
+ * Return the NUMA socket to which a device is connected.
+ *
+ * @param dev_id
+ * The identifier of the device.
+ * @return
+ * The NUMA socket id to which the device is connected or
+ * a default of zero if the socket could not be determined.
+ * - -1: dev_id value is out of range.
+ */
+extern int
+rte_event_dev_socket_id(uint8_t dev_id);
+
+/* Event device capability bitmap flags */
+#define RTE_EVENT_DEV_CAP_QUEUE_QOS (1 << 0)
+/**< Event scheduling prioritization is based on the priority associated with
+ * each event queue.
+ *
+ * \see rte_event_queue_setup(), RTE_EVENT_QUEUE_PRIORITY_NORMAL
+ */
+#define RTE_EVENT_DEV_CAP_EVENT_QOS (1 << 1)
+/**< Event scheduling prioritization is based on the priority associated with
+ * each event. Priority of each event is supplied in *rte_event* structure
+ * on each enqueue operation.
+ *
+ * \see rte_event_enqueue()
+ */
+
+/**
+ * Event device information
+ */
+struct rte_event_dev_info {
+ const char *driver_name; /**< Event driver name */
+ struct rte_pci_device *pci_dev; /**< PCI information */
+ uint32_t min_dequeue_wait_ns;
+ /**< Minimum supported global dequeue wait delay(ns) by this device */
+ uint32_t max_dequeue_wait_ns;
+ /**< Maximum supported global dequeue wait delay(ns) by this device */
+ uint32_t dequeue_wait_ns;
+ /**< Configured global dequeue wait delay(ns) for this device */
+ uint8_t max_event_queues;
+ /**< Maximum event_queues supported by this device */
+ uint32_t max_event_queue_flows;
+ /**< Maximum supported flows in an event queue by this device*/
+ uint8_t max_event_queue_priority_levels;
+ /**< Maximum number of event queue priority levels by this device.
+ * Valid when the device has RTE_EVENT_DEV_CAP_QUEUE_QOS capability
+ */
+ uint8_t nb_event_queues;
+ /**< Configured number of event queues for this device */
+ uint8_t max_event_priority_levels;
+ /**< Maximum number of event priority levels by this device.
+ * Valid when the device has RTE_EVENT_DEV_CAP_EVENT_QOS capability
+ */
+ uint8_t max_event_ports;
+ /**< Maximum number of event ports supported by this device */
+ uint8_t nb_event_ports;
+ /**< Configured number of event ports for this device */
+ uint8_t max_event_port_dequeue_queue_depth;
+ /**< Maximum dequeue queue depth for any event port.
+ * Implementations can schedule N events at a time to an event port.
+ * A device that does not support bulk dequeue will set this as 1.
+ * \see rte_event_port_setup()
+ */
+ uint32_t max_event_port_enqueue_queue_depth;
+ /**< Maximum enqueue queue depth for any event port. Implementations
+ * can batch N events at a time to enqueue through event port
+ * \see rte_event_port_setup()
+ */
+ int32_t max_num_events;
+ /**< A *closed system* event dev has a limit on the number of events it
+ * can manage at a time. An *open system* event dev does not have a
+ * limit and will specify this as -1.
+ */
+ uint32_t event_dev_cap;
+ /**< Event device capabilities(RTE_EVENT_DEV_CAP_)*/
+};
+
+/**
+ * Retrieve the contextual information of an event device.
+ *
+ * @param dev_id
+ * The identifier of the device.
+ *
+ * @param[out] dev_info
+ * A pointer to a structure of type *rte_event_dev_info* to be
filled with the
+ * contextual information of the device.
+ *
+ */
+extern void
+rte_event_dev_info_get(uint8_t dev_id, struct rte_event_dev_info *dev_info);
+
+/* Event device configuration bitmap flags */
+#define RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT (1 << 0)
+/**< Override the global *dequeue_wait_ns* and use per dequeue wait in ns.
+ * \see rte_event_dequeue_wait_time(), rte_event_dequeue()
+ */
+
+/** Event device configuration structure */
+struct rte_event_dev_config {
+ uint32_t dequeue_wait_ns;
+ /**< rte_event_dequeue() wait for *dequeue_wait_ns* ns on this device.
+ * This value should be in the range of *min_dequeue_wait_ns* and
+ * *max_dequeue_wait_ns* which previously provided in
+ * rte_event_dev_info_get()
+ * \see RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT
+ */
+ int32_t nb_events_limit;
+ /**< Applies to *closed system* event dev only. This field indicates a
+ * limit to ethdev-like devices to limit the number of events injected
+ * into the system to not overwhelm core-to-core events.
+ * This value cannot exceed the *max_num_events* which previously
+ * provided in rte_event_dev_info_get()
+ */
+ uint8_t nb_event_queues;
+ /**< Number of event queues to configure on this device.
+ * This value cannot exceed the *max_event_queues* which previously
+ * provided in rte_event_dev_info_get()
+ */
+ uint8_t nb_event_ports;
+ /**< Number of event ports to configure on this device.
+ * This value cannot exceed the *max_event_ports* which previously
+ * provided in rte_event_dev_info_get()
+ */
+ uint32_t event_dev_cfg;
+ /**< Event device config flags(RTE_EVENT_DEV_CFG_)*/
+};
+
+/**
+ * Configure an event device.
+ *
+ * This function must be invoked first before any other function in the
+ * API. This function can also be re-invoked when a device is in the
+ * stopped state.
+ *
+ * The caller may use rte_event_dev_info_get() to get the capability of each
+ * resources available for this event device.
+ *
+ * @param dev_id
+ * The identifier of the device to configure.
+ * @param config
+ * The event device configuration structure.
+ *
+ * @return
+ * - 0: Success, device configured.
+ * - <0: Error code returned by the driver configuration function.
+ */
+extern int
+rte_event_dev_configure(uint8_t dev_id, struct rte_event_dev_config *config);
+
+
+/* Event queue specific APIs */
+
+#define RTE_EVENT_QUEUE_PRIORITY_HIGHEST 0
+/**< Highest event queue priority */
+#define RTE_EVENT_QUEUE_PRIORITY_NORMAL 128
+/**< Normal event queue priority */
+#define RTE_EVENT_QUEUE_PRIORITY_LOWEST 255
+/**< Lowest event queue priority */
+
+/* Event queue configuration bitmap flags */
+#define RTE_EVENT_QUEUE_CFG_SINGLE_CONSUMER (1 << 0)
+/**< This event queue links only to a single event port.
+ *
+ * \see rte_event_port_setup(), rte_event_port_link()
+ */
+
+/** Event queue configuration structure */
+struct rte_event_queue_conf {
+ uint32_t nb_atomic_flows;
+ /**< The maximum number of active flows this queue can track at any
+ * given time. The value must be in the range of
+ * [1 - max_event_queue_flows)] which previously supplied
+ * to rte_event_dev_configure().
+ */
+ uint32_t nb_atomic_order_sequences;
+ /**< The maximum number of outstanding events waiting to be (egress-)
+ * reordered by this queue. In other words, the number of entries in
+ * this queue’s reorder buffer.The value must be in the range of
+ * [1 - max_event_queue_flows)] which previously supplied
+ * to rte_event_dev_configure().
+ */
+ uint32_t event_queue_cfg; /**< Queue config flags(EVENT_QUEUE_CFG_) */
+ uint8_t priority;
+ /**< Priority for this event queue relative to other event queues.
+ * The requested priority should in the range of
+ * [RTE_EVENT_QUEUE_PRIORITY_HIGHEST, RTE_EVENT_QUEUE_PRIORITY_LOWEST].
+ * The implementation shall normalize the requested priority to
+ * event device supported priority value.
+ * Valid when the device has RTE_EVENT_DEV_CAP_QUEUE_QOS capability
+ */
+};
+
+/**
+ * Retrieve the default configuration information of an event queue designated
+ * by its *queue_id* from the event driver for an event device.
+ *
+ * This function intended to be used in conjunction with
rte_event_queue_setup()
+ * where caller needs to set up the queue by overriding few default values.
+ *
+ * @param dev_id
+ * The identifier of the device.
+ * @param queue_id
+ * The index of the event queue to get the configuration information.
+ * The value must be in the range [0, nb_event_queues - 1]
+ * previously supplied to rte_event_dev_configure().
+ * @param[out] queue_conf
+ * The pointer to the default event queue configuration data.
+ *
+ * \see rte_event_queue_setup()
+ *
+ */
+extern void
+rte_event_queue_default_conf_get(uint8_t dev_id, uint8_t queue_id,
+ struct rte_event_queue_conf *queue_conf);
+
+/**
+ * Allocate and set up an event queue for an event device.
+ *
+ * @param dev_id
+ * The identifier of the device.
+ * @param queue_id
+ * The index of the event queue to setup. The value must be in the range
+ * [0, nb_event_queues - 1] previously supplied to rte_event_dev_configure().
+ * @param queue_conf
+ * The pointer to the configuration data to be used for the event queue.
+ * NULL value is allowed, in which case default configuration used.
+ *
+ * \see rte_event_queue_default_conf_get()
+ *
+ * @return
+ * - 0: Success, event queue correctly set up.
+ * - <0: event queue configuration failed
+ */
+extern int
+rte_event_queue_setup(uint8_t dev_id, uint8_t queue_id,
+ struct rte_event_queue_conf *queue_conf);
+
+/**
+ * Get the number of event queues on a specific event device
+ *
+ * @param dev_id
+ * Event device identifier.
+ * @return
+ * - The number of configured event queues
+ */
+extern uint16_t
+rte_event_queue_count(uint8_t dev_id);
+
+/**
+ * Get the priority of the event queue on a specific event device
+ *
+ * @param dev_id
+ * Event device identifier.
+ * @param queue_id
+ * Event queue identifier.
+ * @return
+ * - If the device has RTE_EVENT_DEV_CAP_QUEUE_QOS capability then the
+ * configured priority of the event queue in
+ * [RTE_EVENT_QUEUE_PRIORITY_HIGHEST, RTE_EVENT_QUEUE_PRIORITY_LOWEST] range
+ * else the value one
+ */
+extern uint8_t
+rte_event_queue_priority(uint8_t dev_id, uint8_t queue_id);
+
+/* Event port specific APIs */
+
+/** Event port configuration structure */
+struct rte_event_port_conf {
+ int32_t new_event_threshold;
+ /**< A backpressure threshold for new event enqueues on this port.
+ * Use for *closed system* event dev where event capacity is limited,
+ * and cannot exceed the capacity of the event dev.
+ * Configuring ports with different thresholds can make higher priority
+ * traffic less likely to be backpressured.
+ * For example, a port used to inject NIC Rx packets into the event dev
+ * can have a lower threshold so as not to overwhelm the device,
+ * while ports used for worker pools can have a higher threshold.
+ */
+ uint8_t dequeue_queue_depth;
+ /**< Configure number of bulk dequeues for this event port.
+ * This value cannot exceed the *max_event_port_dequeue_queue_depth*
+ * which previously supplied to rte_event_dev_configure()
+ */
+ uint8_t enqueue_queue_depth;
+ /**< Configure number of bulk enqueues for this event port.
+ * This value cannot exceed the *max_event_port_enqueue_queue_depth*
+ * which previously supplied to rte_event_dev_configure()
+ */
+};
+
+/**
+ * Retrieve the default configuration information of an event port designated
+ * by its *port_id* from the event driver for an event device.
+ *
+ * This function intended to be used in conjunction with rte_event_port_setup()
+ * where caller needs to set up the port by overriding few default values.
+ *
+ * @param dev_id
+ * The identifier of the device.
+ * @param port_id
+ * The index of the event port to get the configuration information.
+ * The value must be in the range [0, nb_event_ports - 1]
+ * previously supplied to rte_event_dev_configure().
+ * @param[out] port_conf
+ * The pointer to the default event port configuration data
+ *
+ * \see rte_event_port_setup()
+ *
+ */
+extern void
+rte_event_port_default_conf_get(uint8_t dev_id, uint8_t port_id,
+ struct rte_event_port_conf *port_conf);
+
+/**
+ * Allocate and set up an event port for an event device.
+ *
+ * @param dev_id
+ * The identifier of the device.
+ * @param port_id
+ * The index of the event port to setup. The value must be in the range
+ * [0, nb_event_ports - 1] previously supplied to rte_event_dev_configure().
+ * @param port_conf
+ * The pointer to the configuration data to be used for the queue.
+ * NULL value is allowed, in which case default configuration used.
+ *
+ * \see rte_event_port_default_conf_get()
+ *
+ * @return
+ * - 0: Success, event port correctly set up.
+ * - <0: Port configuration failed
+ * - (-EDQUOT) Quota exceeded(Application tried to link the queue configured
+ * with RTE_EVENT_QUEUE_CFG_SINGLE_CONSUMER to more than one event ports)
+ */
+extern int
+rte_event_port_setup(uint8_t dev_id, uint8_t port_id,
+ struct rte_event_port_conf *port_conf);
+
+/**
+ * Get the number of dequeue queue depth configured for event port designated
+ * by its *port_id* on a specific event device
+ *
+ * @param dev_id
+ * Event device identifier.
+ * @param port_id
+ * Event port identifier.
+ * @return
+ * - The number of configured dequeue queue depth
+ *
+ * \see rte_event_dequeue_burst()
+ */
+extern uint8_t
+rte_event_port_dequeue_depth(uint8_t dev_id, uint8_t port_id);
+
+/**
+ * Get the number of enqueue queue depth configured for event port designated
+ * by its *port_id* on a specific event device
+ *
+ * @param dev_id
+ * Event device identifier.
+ * @param port_id
+ * Event port identifier.
+ * @return
+ * - The number of configured enqueue queue depth
+ *
+ * \see rte_event_enqueue_burst()
+ */
+extern uint8_t
+rte_event_port_enqueue_depth(uint8_t dev_id, uint8_t port_id);
+
+/**
+ * Get the number of ports on a specific event device
+ *
+ * @param dev_id
+ * Event device identifier.
+ * @return
+ * - The number of configured ports
+ */
+extern uint8_t
+rte_event_port_count(uint8_t dev_id);
+
+/**
+ * Start an event device.
+ *
+ * The device start step is the last one and consists of setting the event
+ * queues to start accepting the events and schedules to event ports.
+ *
+ * On success, all basic functions exported by the API (event enqueue,
+ * event dequeue and so on) can be invoked.
+ *
+ * @param dev_id
+ * Event device identifier
+ * @return
+ * - 0: Success, device started.
+ * - <0: Error code of the driver device start function.
+ */
+extern int
+rte_event_dev_start(uint8_t dev_id);
+
+/**
+ * Stop an event device. The device can be restarted with a call to
+ * rte_event_dev_start()
+ *
+ * @param dev_id
+ * Event device identifier.
+ */
+extern void
+rte_event_dev_stop(uint8_t dev_id);
+
+/**
+ * Close an event device. The device cannot be restarted!
+ *
+ * @param dev_id
+ * Event device identifier
+ *
+ * @return
+ * - 0 on successfully closing device
+ * - <0 on failure to close device
+ */
+extern int
+rte_event_dev_close(uint8_t dev_id);
+
+/* Scheduler type definitions */
+#define RTE_SCHED_TYPE_ORDERED 0
+/**< Ordered scheduling
+ *
+ * Events from an ordered flow of an event queue can be scheduled to multiple
+ * ports for concurrent processing while maintaining the original event order.
+ * This scheme enables the user to achieve high single flow throughput by
+ * avoiding SW synchronization for ordering between ports which bound to cores.
+ *
+ * The source flow ordering from an event queue is maintained when events are
+ * enqueued to their destination queue within the same ordered flow context.
+ * An event port holds the context until application call rte_event_dequeue()
+ * from the same port, which implicitly releases the context.
+ * User may allow the scheduler to release the context earlier than that
+ * by calling rte_event_release()
+ *
+ * Events from the source queue appear in their original order when dequeued
+ * from a destination queue.
+ * Event ordering is based on the received event(s), but also other
+ * (newly allocated or stored) events are ordered when enqueued within the same
+ * ordered context. Events not enqueued (e.g. released or stored) within the
+ * context are considered missing from reordering and are skipped at this time
+ * (but can be ordered again within another context).
+ *
+ * \see rte_event_dequeue(), rte_event_release()
+ */
+
+#define RTE_SCHED_TYPE_ATOMIC 1
+/**< Atomic scheduling
+ *
+ * Events from an atomic flow of an event queue can be scheduled only to a
+ * single port at a time. The port is guaranteed to have exclusive (atomic)
+ * access to the associated flow context, which enables the user to avoid SW
+ * synchronization. Atomic flows also help to maintain event ordering
+ * since only one port at a time can process events from a flow of an
+ * event queue.
+ *
+ * The atomic queue synchronization context is dedicated to the port until
+ * application call rte_event_dequeue() from the same port, which implicitly
+ * releases the context. User may allow the scheduler to release the context
+ * earlier than that by calling rte_event_release()
+ *
+ * \see rte_event_dequeue(), rte_event_release()
+ */
+
+#define RTE_SCHED_TYPE_PARALLEL 2
+/**< Parallel scheduling
+ *
+ * The scheduler performs priority scheduling, load balancing, etc. functions
+ * but does not provide additional event synchronization or ordering.
+ * It is free to schedule events from a single parallel flow of an event queue
+ * to multiple events ports for concurrent processing.
+ * The application is responsible for flow context synchronization and
+ * event ordering (SW synchronization).
+ */
+
+/* Event types to classify the event source */
+#define RTE_EVENT_TYPE_ETHDEV 0x0
+/**< The event generated from ethdev subsystem */
+#define RTE_EVENT_TYPE_CRYPTODEV 0x1
+/**< The event generated from crypodev subsystem */
+#define RTE_EVENT_TYPE_TIMERDEV 0x2
+/**< The event generated from timerdev subsystem */
+#define RTE_EVENT_TYPE_CORE 0x3
+/**< The event generated from core.
+ * Application may use *sub_event_type* to further classify the event
+ */
+#define RTE_EVENT_TYPE_MAX 0x10
+/**< Maximum number of event types */
+
+/* Event priority */
+#define RTE_EVENT_PRIORITY_HIGHEST 0
+/**< Highest event priority */
+#define RTE_EVENT_PRIORITY_NORMAL 128
+/**< Normal event priority */
+#define RTE_EVENT_PRIORITY_LOWEST 255
+/**< Lowest event priority */
+
+/**
+ * The generic *rte_event* structure to hold the event attributes
+ * for dequeue and enqueue operation
+ */
+struct rte_event {
+ /** WORD0 */
+ RTE_STD_C11
+ union {
+ uint64_t u64;
+ /** Event attributes for dequeue or enqueue operation */
+ struct {
+ uint32_t flow_id:24;
+ /**< Targeted flow identifier for the enqueue and
+ * dequeue operation.
+ * The value must be in the range of
+ * [1 - max_event_queue_flows)] which
+ * previously supplied to rte_event_dev_configure().
+ */
+ uint32_t queue_id:8;
+ /**< Targeted event queue identifier for the enqueue or
+ * dequeue operation.
+ * The value must be in the range of
+ * [0, nb_event_queues - 1] which previously supplied to
+ * rte_event_dev_configure().
+ */
+ uint8_t sched_type;
+ /**< Scheduler synchronization type (RTE_SCHED_TYPE_)
+ * associated with flow id on a given event queue
+ * for the enqueue and dequeue operation.
+ */
+ uint8_t event_type;
+ /**< Event type to classify the event source. */
+ uint8_t sub_event_type;
+ /**< Sub-event types based on the event source.
+ * \see RTE_EVENT_TYPE_CORE
+ */
+ uint8_t priority;
+ /**< Event priority relative to other events in the
+ * event queue. The requested priority should in the
+ * range of [RTE_EVENT_PRIORITY_HIGHEST,
+ * RTE_EVENT_PRIORITY_LOWEST].
+ * The implementation shall normalize the requested
+ * priority to supported priority value.
+ * Valid when the device has RTE_EVENT_DEV_CAP_EVENT_QOS
+ * capability.
+ */
+ };
+ };
+ /** WORD1 */
+ RTE_STD_C11
+ union {
+ uintptr_t event;
+ /**< Opaque event pointer */
+ struct rte_mbuf *mbuf;
+ /**< mbuf pointer if dequeued event is associated with mbuf */
+ };
+};
+
+/**
+ * Schedule one or more events in the event dev.
+ *
+ * An event dev implementation may define this is a NOOP, for instance if
+ * the event dev performs its scheduling in hardware.
+ *
+ * @param dev_id
+ * The identifier of the device.
+ */
+extern void
+rte_event_schedule(uint8_t dev_id);
+
+/**
+ * Enqueue the event object supplied in the *rte_event* structure on an
+ * event device designated by its *dev_id* through the event port specified by
+ * *port_id*. The event object specifies the event queue on which this
+ * event will be enqueued.
+ *
+ * @param dev_id
+ * Event device identifier.
+ * @param port_id
+ * The identifier of the event port.
+ * @param ev
+ * Pointer to struct rte_event
+ * @param pin_event
+ * Hint to the scheduler that the event can be pinned to the same port for
+ * the next scheduling stage. For implementations that support it, this
+ * allows the same core to process the next stage in the pipeline for a given
+ * event, taking advantage of cache locality. The pinned event will be
+ * received through rte_event_dequeue(). This is a hint and the event is
+ * not guaranteed to be pinned to the port. This hint is valid only when the
+ * event is dequeued with rte_event_dequeue() followed by
rte_event_enqueue().
+ *
+ * @return
+ * - 0 on success
+ * - <0 on failure. Failure can occur if the event port's output queue is
+ * backpressured, for instance.
+ */
+extern int
+rte_event_enqueue(uint8_t dev_id, uint8_t port_id, struct rte_event *ev,
+ bool pin_event);
+
+/**
+ * Enqueue a burst of events objects supplied in *rte_event* structure on an
+ * event device designated by its *dev_id* through the event port specified by
+ * *port_id*. Each event object specifies the event queue on which it
+ * will be enqueued.
+ *
+ * The rte_event_enqueue_burst() function is invoked to enqueue
+ * multiple event objects.
+ * It is the burst variant of rte_event_enqueue() function.
+ *
+ * The *num* parameter is the number of event objects to enqueue which are
+ * supplied in the *ev* array of *rte_event* structure.
+ *
+ * The rte_event_enqueue_burst() function returns the number of
+ * events objects it actually enqueued. A return value equal to *num* means
+ * that all event objects have been enqueued.
+ *
+ * @param dev_id
+ * The identifier of the device.
+ * @param port_id
+ * The identifier of the event port.
+ * @param ev
+ * An array of *num* pointers to *rte_event* structure
+ * which contain the event object enqueue operations to be processed.
+ * @param num
+ * The number of event objects to enqueue, typically number of
+ * rte_event_port_enqueue_depth() available for this port.
+ * @param pin_event
+ * Hint to the scheduler that the event can be pinned to the same port for
+ * the next scheduling stage. For implementations that support it, this
+ * allows the same core to process the next stage in the pipeline for a given
+ * event, taking advantage of cache locality. The pinned event will be
+ * received through rte_event_dequeue(). This is a hint and the event is
+ * not guaranteed to be pinned to the port. This hint is valid only when the
+ * event is dequeued with rte_event_dequeue() followed by
rte_event_enqueue().
+ *
+ * @return
+ * The number of event objects actually enqueued on the event device. The
+ * return value can be less than the value of the *num* parameter when the
+ * event devices queue is full or if invalid parameters are specified in a
+ * *rte_event*. If return value is less than *num*, the remaining events at
+ * the end of ev[] are not consumed, and the caller has to take care of them.
+ *
+ * \see rte_event_enqueue(), rte_event_port_enqueue_depth()
+ */
+extern int
+rte_event_enqueue_burst(uint8_t dev_id, uint8_t port_id,
+ struct rte_event ev[], int num, bool pin_event);
+
+/**
+ * Converts nanoseconds to *wait* value for rte_event_dequeue()
+ *
+ * If the device is configured with
RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT flag then
+ * application can use this function to convert wait value in nanoseconds to
+ * implementations specific wait value supplied in rte_event_dequeue()
+ *
+ * @param dev_id
+ * The identifier of the device.
+ * @param ns
+ * Wait time in nanosecond
+ *
+ * @return
+ * Value for the *wait* parameter in rte_event_dequeue() function
+ *
+ * \see rte_event_dequeue(), RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT
+ * \see rte_event_dev_configure()
+ *
+ */
+extern uint64_t
+rte_event_dequeue_wait_time(uint8_t dev_id, uint64_t ns);
+
+/**
+ * Dequeue an event from the event port specified by *port_id* on the
+ * event device designated by its *dev_id*.
+ *
+ * rte_event_dequeue() does not dictate the specifics of scheduling
algorithm as
+ * each eventdev driver may have different criteria to schedule an event.
+ * However, in general, from an application perspective scheduler may use the
+ * following scheme to dispatch an event to the port.
+ *
+ * 1) Selection of event queue based on
+ * a) The list of event queues are linked to the event port.
+ * b) If the device has RTE_EVENT_DEV_CAP_QUEUE_QOS capability then event
+ * queue selection from list is based on event queue priority relative to
+ * other event queue supplied as *priority* in rte_event_queue_setup()
+ * c) If the device has RTE_EVENT_DEV_CAP_EVENT_QOS capability then event
+ * queue selection from the list is based on event priority supplied as
+ * *priority* in rte_event_enqueue_burst()
+ * 2) Selection of event
+ * a) The number of flows available in selected event queue.
+ * b) Schedule type method associated with the event
+ *
+ * On a successful dequeue, the event port holds flow id and schedule type
+ * context associated with the dispatched event. The context is automatically
+ * released in the next rte_event_dequeue() invocation, or rte_event_release()
+ * can be called to release the context early.
+ *
+ * @param dev_id
+ * The identifier of the device.
+ * @param port_id
+ * The identifier of the event port.
+ * @param[out] ev
+ * Pointer to struct rte_event. On successful event dispatch, implementation
+ * updates the event attributes.
+ * @param wait
+ * 0 - no-wait, returns immediately if there is no event.
+ * >0 - wait for the event, if the device is configured with
+ * RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT then this function will wait until
+ * the event available or *wait* time.
+ * if the device is not configured with RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT
+ * then this function will wait until the event available or
*dequeue_wait_ns*
+ * ns which was previously supplied to rte_event_dev_configure()
+ *
+ * @return
+ * When true, a valid event has been dispatched by the scheduler.
+ *
+ */
+extern bool
+rte_event_dequeue(uint8_t dev_id, uint8_t port_id,
+ struct rte_event *ev, uint64_t wait);
+
+/**
+ * Dequeue a burst of events objects from the event port designated by its
+ * *event_port_id*, on an event device designated by its *dev_id*.
+ *
+ * The rte_event_dequeue_burst() function is invoked to dequeue
+ * multiple event objects. It is the burst variant of rte_event_dequeue()
+ * function.
+ *
+ * The *num* parameter is the maximum number of event objects to dequeue which
+ * are returned in the *ev* array of *rte_event* structure.
+ *
+ * The rte_event_dequeue_burst() function returns the number of
+ * events objects it actually dequeued. A return value equal to
+ * *num* means that all event objects have been dequeued.
+ *
+ * The number of events dequeued is the number of scheduler contexts held by
+ * this port. These contexts are automatically released in the next
+ * rte_event_dequeue() invocation, or rte_event_release() can be called once
+ * per event to release the contexts early.
+ *
+ * @param dev_id
+ * The identifier of the device.
+ * @param port_id
+ * The identifier of the event port.
+ * @param[out] ev
+ * An array of *num* pointers to *rte_event* structure which is populated
+ * with the dequeued event objects.
+ * @param num
+ * The maximum number of event objects to dequeue, typically number of
+ * rte_event_port_dequeue_depth() available for this port.
+ * @param wait
+ * 0 - no-wait, returns immediately if there is no event.
+ * >0 - wait for the event, if the device is configured with
+ * RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT then this function will wait until the
+ * event available or *wait* time.
+ * if the device is not configured with RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT
+ * then this function will wait until the event available or
*dequeue_wait_ns*
+ * ns which was previously supplied to rte_event_dev_configure()
+ *
+ * @return
+ * The number of event objects actually dequeued from the port. The return
+ * value can be less than the value of the *num* parameter when the
+ * event port's queue is not full.
+ *
+ * \see rte_event_dequeue(), rte_event_port_dequeue_depth()
+ */
+extern int
+rte_event_dequeue_burst(uint8_t dev_id, uint8_t port_id,
+ struct rte_event *ev, int num, uint64_t wait);
+
+/**
+ * Release the current flow context associated with a schedule type which
+ * dequeued from a given event queue though the event port designated by
+ * its *port_id*
+ *
+ * If current flow's scheduler type method is *RTE_SCHED_TYPE_ATOMIC*
+ * then this function hints the scheduler that the user has completed critical
+ * section processing in the current atomic context.
+ * The scheduler is now allowed to schedule events from the same flow from
+ * an event queue to another port. However, the context may be still held
+ * until the next rte_event_dequeue() or rte_event_dequeue_burst() call, this
+ * call allows but does not force the scheduler to release the context early.
+ *
+ * Early atomic context release may increase parallelism and thus system
+ * performance, but the user needs to design carefully the split into critical
+ * vs non-critical sections.
+ *
+ * If current flow's scheduler type method is *RTE_SCHED_TYPE_ORDERED*
+ * then this function hints the scheduler that the user has done all that need
+ * to maintain event order in the current ordered context.
+ * The scheduler is allowed to release the ordered context of this port and
+ * avoid reordering any following enqueues.
+ *
+ * Early ordered context release may increase parallelism and thus system
+ * performance.
+ *
+ * If current flow's scheduler type method is *RTE_SCHED_TYPE_PARALLEL*
+ * or no scheduling context is held then this function may be an NOOP,
+ * depending on the implementation.
+ *
+ * If multiple events are dequeued with rte_event_dequeue_burst(),
+ * rte_event_release() will release each flow context associated with a
+ * schedule type of an event though *index*, it denotes the order in
+ * which it was dequeued with rte_event_dequeue_burst()
+ *
+ * @param dev_id
+ * The identifier of the device.
+ * @param port_id
+ * The identifier of the event port.
+ * @param index
+ * The index of the event that dequeued with rte_event_dequeue_burst()
+ * which needs to release. The value zero used if the event dequeued with
+ * rte_event_dequeue()
+ *
+ * \see rte_event_dequeue(), rte_event_dequeue_burst()
+ */
+extern void
+rte_event_release(uint8_t dev_id, uint8_t port_id, uint8_t index);
+
+#define RTE_EVENT_QUEUE_SERVICE_PRIORITY_HIGHEST 0
+/**< Highest event queue servicing priority */
+#define RTE_EVENT_QUEUE_SERVICE_PRIORITY_NORMAL 128
+/**< Normal event queue servicing priority */
+#define RTE_EVENT_QUEUE_SERVICE_PRIORITY_LOWEST 255
+/**< Lowest event queue servicing priority */
+
+/** Structure to hold the queue to port link establishment attributes */
+struct rte_event_queue_link {
+ uint8_t queue_id;
+ /**< Event queue identifier to select the source queue to link */
+ uint8_t priority;
+ /**< The priority of the event queue for this event port.
+ * The priority defines the event port's servicing priority for
+ * event queue, which may be ignored by an implementation.
+ * The requested priority should in the range of
+ * [RTE_EVENT_QUEUE_SERVICE_PRIORITY_HIGHEST,
+ * RTE_EVENT_QUEUE_SERVICE_PRIORITY_LOWEST].
+ * The implementation shall normalize the requested priority to
+ * implementation supported priority value.
+ */
+};
+
+/**
+ * Link multiple source event queues supplied in *rte_event_queue_link*
+ * structure as *queue_id* to the destination event port designated by its
+ * *port_id* on the event device designated by its *dev_id*.
+ *
+ * The link establishment shall enable the event port *port_id* from
+ * receiving events from the specified event queue *queue_id*
+ *
+ * An event queue may link to one or more event ports.
+ * The number of links can be established from an event queue to event port is
+ * implementation defined.
+ *
+ * Event queue(s) to event port link establishment can be changed at runtime
+ * without re-configuring the device to support scaling and to reduce the
+ * latency of critical work by establishing the link with more event ports
+ * at runtime.
+ *
+ * @param dev_id
+ * The identifier of the device.
+ *
+ * @param port_id
+ * Event port identifier to select the destination port to link.
+ *
+ * @param link
+ * An array of *num* pointers to *rte_event_queue_link* structure
+ * which contain the event queue to event port link establishment attributes.
+ * NULL value is allowed, in which case this function links all the
configured
+ * event queues *nb_event_queues* which previously supplied to
+ * rte_event_dev_configure() to the event port *port_id* with
normal servicing
+ * priority(RTE_EVENT_QUEUE_SERVICE_PRIORITY_NORMAL).
+ *
+ * @param num
+ * The number of links to establish
+ *
+ * @return
+ * The number of links actually established on the event device. The return
+ * value can be less than the value of the *num* parameter when the
+ * implementation has the limitation on specific queue to port link
+ * establishment or if invalid parameters are specified
+ * in a *rte_event_queue_link*.
+ * If the return value is less than *num*, the remaining links at the end of
+ * link[] are not established, and the caller has to take care of them.
+ * If return value is less than *num* then implementation shall update the
+ * rte_errno accordingly, Possible rte_errno values are
+ * (-EDQUOT) Quota exceeded(Application tried to link the queue configured with
+ * RTE_EVENT_QUEUE_CFG_SINGLE_CONSUMER to more than one event ports)
+ * (-EINVAL) Invalid parameter
+ *
+ */
+extern int
+rte_event_port_link(uint8_t dev_id, uint8_t port_id,
+ struct rte_event_queue_link link[], int num);
+
+/**
+ * Unlink multiple source event queues supplied in *queues* from the
destination
+ * event port designated by its *port_id* on the event device designated
+ * by its *dev_id*.
+ *
+ * The unlink establishment shall disable the event port *port_id* from
+ * receiving events from the specified event queue *queue_id*
+ *
+ * Event queue(s) to event port unlink establishment can be changed at runtime
+ * without re-configuring the device.
+ *
+ * @param dev_id
+ * The identifier of the device.
+ *
+ * @param port_id
+ * Event port identifier to select the destination port to unlink.
+ *
+ * @param queues
+ * An array of *num* event queues to be unlinked from the event port.
+ * NULL value is allowed, in which case this function unlinks all the
+ * event queue(s) from the event port *port_id*.
+ *
+ * @param num
+ * The number of unlinks to establish
+ *
+ * @return
+ * The number of unlinks actually established on the event device. The return
+ * value can be less than the value of the *num* parameter when the
+ * implementation has the limitation on specific queue to port unlink
+ * establishment or if invalid parameters are specified.
+ * If the return value is less than *num*, the remaining queues at the end of
+ * queues[] are not established, and the caller has to take care of them.
+ * If return value is less than *num* then implementation shall update the
+ * rte_errno accordingly, Possible rte_errno values are
+ * (-EINVAL) Invalid parameter
+ *
+ */
+extern int
+rte_event_port_unlink(uint8_t dev_id, uint8_t port_id,
+ uint8_t queues[], int num);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_EVENTDEV_H_ */
--
2.5.5
^ permalink raw reply related
* [PATCH v6 0/6] add Tx preparation
From: Tomasz Kulasek @ 2016-10-14 15:05 UTC (permalink / raw)
To: dev; +Cc: konstantin.ananyev, thomas.monjalon
In-Reply-To: <1476380222-9900-1-git-send-email-tomaszx.kulasek@intel.com>
As discussed in that thread:
http://dpdk.org/ml/archives/dev/2015-September/023603.html
Different NIC models depending on HW offload requested might impose different requirements on packets to be TX-ed in terms of:
- Max number of fragments per packet allowed
- Max number of fragments per TSO segments
- The way pseudo-header checksum should be pre-calculated
- L3/L4 header fields filling
- etc.
MOTIVATION:
-----------
1) Some work cannot (and didn't should) be done in rte_eth_tx_burst.
However, this work is sometimes required, and now, it's an
application issue.
2) Different hardware may have different requirements for TX offloads,
other subset can be supported and so on.
3) Some parameters (e.g. number of segments in ixgbe driver) may hung
device. These parameters may be vary for different devices.
For example i40e HW allows 8 fragments per packet, but that is after
TSO segmentation. While ixgbe has a 38-fragment pre-TSO limit.
4) Fields in packet may require different initialization (like e.g. will
require pseudo-header checksum precalculation, sometimes in a
different way depending on packet type, and so on). Now application
needs to care about it.
5) Using additional API (rte_eth_tx_prep) before rte_eth_tx_burst let to
prepare packet burst in acceptable form for specific device.
6) Some additional checks may be done in debug mode keeping tx_burst
implementation clean.
PROPOSAL:
---------
To help user to deal with all these varieties we propose to:
1) Introduce rte_eth_tx_prep() function to do necessary preparations of
packet burst to be safely transmitted on device for desired HW
offloads (set/reset checksum field according to the hardware
requirements) and check HW constraints (number of segments per
packet, etc).
While the limitations and requirements may differ for devices, it
requires to extend rte_eth_dev structure with new function pointer
"tx_pkt_prep" which can be implemented in the driver to prepare and
verify packets, in devices specific way, before burst, what should to
prevent application to send malformed packets.
2) Also new fields will be introduced in rte_eth_desc_lim:
nb_seg_max and nb_mtu_seg_max, providing an information about max
segments in TSO and non-TSO packets acceptable by device.
This information is useful for application to not create/limit
malicious packet.
APPLICATION (CASE OF USE):
--------------------------
1) Application should to initialize burst of packets to send, set
required tx offload flags and required fields, like l2_len, l3_len,
l4_len, and tso_segsz
2) Application passes burst to the rte_eth_tx_prep to check conditions
required to send packets through the NIC.
3) The result of rte_eth_tx_prep can be used to send valid packets
and/or restore invalid if function fails.
e.g.
for (i = 0; i < nb_pkts; i++) {
/* initialize or process packet */
bufs[i]->tso_segsz = 800;
bufs[i]->ol_flags = PKT_TX_TCP_SEG | PKT_TX_IPV4
| PKT_TX_IP_CKSUM;
bufs[i]->l2_len = sizeof(struct ether_hdr);
bufs[i]->l3_len = sizeof(struct ipv4_hdr);
bufs[i]->l4_len = sizeof(struct tcp_hdr);
}
/* Prepare burst of TX packets */
nb_prep = rte_eth_tx_prep(port, 0, bufs, nb_pkts);
if (nb_prep < nb_pkts) {
printf("tx_prep failed\n");
/* nb_prep indicates here first invalid packet. rte_eth_tx_prep
* can be used on remaining packets to find another ones.
*/
}
/* Send burst of TX packets */
nb_tx = rte_eth_tx_burst(port, 0, bufs, nb_prep);
/* Free any unsent packets. */
v5 changes:
- rebased csum engine modification
- added information to the csum engine about performance tests
- some performance improvements
v4 changes:
- tx_prep is now set to default behavior (NULL) for simple/vector path
in fm10k, i40e and ixgbe drivers to increase performance, when
Tx offloads are not intentionally available
v3 changes:
- reworked csum testpmd engine instead adding new one,
- fixed checksum initialization procedure to include also outer
checksum offloads,
- some minor formattings and optimalizations
v2 changes:
- rte_eth_tx_prep() returns number of packets when device doesn't
support tx_prep functionality,
- introduced CONFIG_RTE_ETHDEV_TX_PREP allowing to turn off tx_prep
Tomasz Kulasek (6):
ethdev: add Tx preparation
e1000: add Tx preparation
fm10k: add Tx preparation
i40e: add Tx preparation
ixgbe: add Tx preparation
testpmd: use Tx preparation in csum engine
app/test-pmd/csumonly.c | 36 ++++------
config/common_base | 1 +
drivers/net/e1000/e1000_ethdev.h | 11 +++
drivers/net/e1000/em_ethdev.c | 5 +-
drivers/net/e1000/em_rxtx.c | 48 ++++++++++++-
drivers/net/e1000/igb_ethdev.c | 4 ++
drivers/net/e1000/igb_rxtx.c | 52 ++++++++++++++-
drivers/net/fm10k/fm10k.h | 6 ++
drivers/net/fm10k/fm10k_ethdev.c | 5 ++
drivers/net/fm10k/fm10k_rxtx.c | 50 +++++++++++++-
drivers/net/i40e/i40e_ethdev.c | 3 +
drivers/net/i40e/i40e_rxtx.c | 72 +++++++++++++++++++-
drivers/net/i40e/i40e_rxtx.h | 8 +++
drivers/net/ixgbe/ixgbe_ethdev.c | 3 +
drivers/net/ixgbe/ixgbe_ethdev.h | 5 +-
drivers/net/ixgbe/ixgbe_rxtx.c | 58 +++++++++++++++-
drivers/net/ixgbe/ixgbe_rxtx.h | 2 +
lib/librte_ether/rte_ethdev.h | 85 +++++++++++++++++++++++
lib/librte_mbuf/rte_mbuf.h | 9 +++
lib/librte_net/Makefile | 3 +-
lib/librte_net/rte_pkt.h | 137 ++++++++++++++++++++++++++++++++++++++
21 files changed, 572 insertions(+), 31 deletions(-)
create mode 100644 lib/librte_net/rte_pkt.h
--
1.7.9.5
^ permalink raw reply
* Re: [PATCH v2 1/3] lib/librte_port: enable file descriptor port support
From: Thomas Monjalon @ 2016-10-14 15:08 UTC (permalink / raw)
To: Dumitrescu, Cristian; +Cc: Singh, Jasvinder, dev
In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D8912647A91878@IRSMSX108.ger.corp.intel.com>
2016-10-12 20:44, Dumitrescu, Cristian:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > This patchset was probably not tested as it does not compile.
> > And it could be useless if a TAP PMD is integrated.
> > I suggest to wait 17.02 cycle and see.
>
> This patch was tested by me and Jasvinder as well and it works brilliantly.
>
> We did not enable stats when testing, will sort out the missing semicolon issue in the stats macros and resend v3 asap. This is a trivial issue, no need to wait for 17.02.
So the stats were not tested.
> This is not conflicting with TAP PMD, and as said the scope of this supersedes the TAP PMD.
The v3 has been applied and it breaks FreeBSD compilation now.
I felt it was not ready but you won with the words "it works brilliantly" ;)
(sorry I have not resisted to make the joke)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox