* [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 3/7] vhost: simplify mergeable Rx vring 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>
Let it return "num_buffers" we reserved, so that we could re-use it
with copy_mbuf_to_desc_mergeable() directly, instead of calculating
it again there.
Meanwhile, the return type of copy_mbuf_to_desc_mergeable is changed
to "int". -1 will be return on error.
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 | 41 +++++++++++++++++++++--------------------
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
index d4fc62a..1a40c91 100644
--- a/lib/librte_vhost/virtio_net.c
+++ b/lib/librte_vhost/virtio_net.c
@@ -336,7 +336,7 @@ 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,
- uint16_t *end, struct buf_vector *buf_vec)
+ struct buf_vector *buf_vec, uint16_t *num_buffers)
{
uint16_t cur_idx;
uint16_t avail_idx;
@@ -370,19 +370,18 @@ reserve_avail_buf_mergeable(struct vhost_virtqueue *vq, uint32_t size,
return -1;
}
- *end = cur_idx;
+ *num_buffers = cur_idx - vq->last_used_idx;
return 0;
}
-static inline uint32_t __attribute__((always_inline))
+static inline int __attribute__((always_inline))
copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq,
- uint16_t end_idx, struct rte_mbuf *m,
- struct buf_vector *buf_vec)
+ 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 start_idx = vq->last_used_idx;
- uint16_t cur_idx = start_idx;
+ uint16_t cur_idx = vq->last_used_idx;
uint64_t desc_addr;
uint32_t desc_chain_head;
uint32_t desc_chain_len;
@@ -394,21 +393,21 @@ copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq,
struct rte_mbuf *hdr_mbuf;
if (unlikely(m == NULL))
- return 0;
+ return -1;
LOG_DEBUG(VHOST_DATA, "(%d) current index %d | end index %d\n",
dev->vid, cur_idx, end_idx);
desc_addr = gpa_to_vva(dev, buf_vec[vec_idx].buf_addr);
if (buf_vec[vec_idx].buf_len < dev->vhost_hlen || !desc_addr)
- return 0;
+ return -1;
hdr_mbuf = m;
hdr_addr = desc_addr;
hdr_phys_addr = buf_vec[vec_idx].buf_addr;
rte_prefetch0((void *)(uintptr_t)hdr_addr);
- virtio_hdr.num_buffers = end_idx - start_idx;
+ virtio_hdr.num_buffers = num_buffers;
LOG_DEBUG(VHOST_DATA, "(%d) RX: num merge buffers %d\n",
dev->vid, virtio_hdr.num_buffers);
@@ -440,7 +439,7 @@ copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq,
desc_addr = gpa_to_vva(dev, buf_vec[vec_idx].buf_addr);
if (unlikely(!desc_addr))
- return 0;
+ return -1;
/* Prefetch buffer address. */
rte_prefetch0((void *)(uintptr_t)desc_addr);
@@ -489,7 +488,7 @@ copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq,
offsetof(struct vring_used, ring[used_idx]),
sizeof(vq->used->ring[used_idx]));
- return end_idx - start_idx;
+ return 0;
}
static inline uint32_t __attribute__((always_inline))
@@ -497,8 +496,8 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t queue_id,
struct rte_mbuf **pkts, uint32_t count)
{
struct vhost_virtqueue *vq;
- uint32_t pkt_idx = 0, nr_used = 0;
- uint16_t end;
+ uint32_t pkt_idx = 0;
+ uint16_t num_buffers;
struct buf_vector buf_vec[BUF_VECTOR_MAX];
LOG_DEBUG(VHOST_DATA, "(%d) %s\n", dev->vid, __func__);
@@ -519,22 +518,24 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t queue_id,
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,
- &end, buf_vec) < 0)) {
+ if (unlikely(reserve_avail_buf_mergeable(vq, pkt_len, buf_vec,
+ &num_buffers) < 0)) {
LOG_DEBUG(VHOST_DATA,
"(%d) failed to get enough desc from vring\n",
dev->vid);
break;
}
- nr_used = copy_mbuf_to_desc_mergeable(dev, vq, end,
- pkts[pkt_idx], buf_vec);
+ if (copy_mbuf_to_desc_mergeable(dev, vq, pkts[pkt_idx],
+ buf_vec, num_buffers) < 0)
+ break;
+
rte_smp_wmb();
- *(volatile uint16_t *)&vq->used->idx += nr_used;
+ *(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 += nr_used;
+ vq->last_used_idx += num_buffers;
}
if (likely(pkt_idx)) {
--
1.9.0
^ permalink raw reply related
* [PATCH v7 2/7] vhost: optimize cache access
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>
This patch reorders the code to delay virtio header write to improve
cache access efficiency for cases where the mrg_rxbuf feature is turned
on. CPU pipeline stall cycles can be significantly reduced.
Virtio header write and mbuf data copy are all remote store operations
which takes a long time to finish. It's a good idea to put them together
to remove bubbles in between, to let as many remote store instructions
as possible go into store buffer at the same time to hide latency, and
to let the H/W prefetcher goes to work as early as possible.
On a Haswell machine, about 100 cycles can be saved per packet by this
patch alone. Taking 64B packets traffic for example, this means about 60%
efficiency improvement for the enqueue operation.
Signed-off-by: Zhihong Wang <zhihong.wang@intel.com>
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
---
lib/librte_vhost/virtio_net.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
index 812e5d3..d4fc62a 100644
--- a/lib/librte_vhost/virtio_net.c
+++ b/lib/librte_vhost/virtio_net.c
@@ -390,6 +390,8 @@ copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq,
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;
if (unlikely(m == NULL))
return 0;
@@ -401,17 +403,15 @@ copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq,
if (buf_vec[vec_idx].buf_len < dev->vhost_hlen || !desc_addr)
return 0;
- rte_prefetch0((void *)(uintptr_t)desc_addr);
+ hdr_mbuf = m;
+ hdr_addr = desc_addr;
+ hdr_phys_addr = buf_vec[vec_idx].buf_addr;
+ rte_prefetch0((void *)(uintptr_t)hdr_addr);
virtio_hdr.num_buffers = end_idx - start_idx;
LOG_DEBUG(VHOST_DATA, "(%d) RX: num merge buffers %d\n",
dev->vid, virtio_hdr.num_buffers);
- virtio_enqueue_offload(m, &virtio_hdr.hdr);
- copy_virtio_net_hdr(dev, desc_addr, virtio_hdr);
- vhost_log_write(dev, buf_vec[vec_idx].buf_addr, dev->vhost_hlen);
- PRINT_PACKET(dev, (uintptr_t)desc_addr, dev->vhost_hlen, 0);
-
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;
@@ -456,6 +456,16 @@ copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq,
mbuf_avail = rte_pktmbuf_data_len(m);
}
+ if (hdr_addr) {
+ virtio_enqueue_offload(hdr_mbuf, &virtio_hdr.hdr);
+ copy_virtio_net_hdr(dev, hdr_addr, virtio_hdr);
+ vhost_log_write(dev, hdr_phys_addr, dev->vhost_hlen);
+ PRINT_PACKET(dev, (uintptr_t)hdr_addr,
+ dev->vhost_hlen, 0);
+
+ hdr_addr = 0;
+ }
+
cpy_len = RTE_MIN(desc_avail, mbuf_avail);
rte_memcpy((void *)((uintptr_t)(desc_addr + desc_offset)),
rte_pktmbuf_mtod_offset(m, void *, mbuf_offset),
--
1.9.0
^ permalink raw reply related
* [PATCH v7 1/7] vhost: remove useless volatile
From: Yuanhan Liu @ 2016-10-14 9:34 UTC (permalink / raw)
To: dev; +Cc: Maxime Coquelin, Zhihong Wang
In-Reply-To: <1476437678-7102-1-git-send-email-yuanhan.liu@linux.intel.com>
From: Zhihong Wang <zhihong.wang@intel.com>
last_used_idx is a local var, there is no need to decorate it
by "volatile".
Signed-off-by: Zhihong Wang <zhihong.wang@intel.com>
---
lib/librte_vhost/vhost.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
index 53dbf33..17c557f 100644
--- a/lib/librte_vhost/vhost.h
+++ b/lib/librte_vhost/vhost.h
@@ -85,7 +85,7 @@ struct vhost_virtqueue {
uint32_t size;
uint16_t last_avail_idx;
- volatile uint16_t last_used_idx;
+ uint16_t last_used_idx;
#define VIRTIO_INVALID_EVENTFD (-1)
#define VIRTIO_UNINITIALIZED_EVENTFD (-2)
--
1.9.0
^ permalink raw reply related
* [PATCH v7 0/7] vhost: optimize mergeable Rx path
From: Yuanhan Liu @ 2016-10-14 9:34 UTC (permalink / raw)
To: dev; +Cc: Maxime Coquelin, Yuanhan Liu, Jianbo Liu
In-Reply-To: <1474336817-22683-1-git-send-email-zhihong.wang@intel.com>
This is a new set of patches to optimize the mergeable Rx code path.
No refactoring (rewrite) was made this time. It just applies some
findings from Zhihong (kudos to him!) that could improve the mergeable
Rx path on the old code.
The two major factors that could improve the performance greatly are:
- copy virtio header together with packet data. This could remove
the buubbles between the two copy to optimize the cache access.
This is implemented in patch 2 "vhost: optimize cache access"
- shadow used ring update and update them at once
The basic idea is to update used ring in a local buffer and flush
them to the virtio used ring at once in the end. Again, this is
for optimizing the cache access.
This is implemented in patch 5 "vhost: shadow used ring update"
The two optimizations could yield 40+% performance in micro testing
and 20+% in PVP case testing with 64B packet size.
Besides that, there are some tiny optimizations, such as prefetch
avail ring (patch 6) and retrieve avail head once (patch 7).
Note: the shadow used ring tech could also be applied to the non-mrg
Rx path (and even the dequeu) path. I didn't do that for two reasons:
- we already update used ring in batch in both path: it's not shadowed
first though.
- it's a bit too late too make many changes at this stage: RC1 is out.
Please help testing.
Thanks.
--yliu
Cc: Jianbo Liu <jianbo.liu@linaro.org>
---
Yuanhan Liu (4):
vhost: simplify mergeable Rx vring reservation
vhost: use last avail idx for avail ring reservation
vhost: prefetch avail ring
vhost: retrieve avail head once
Zhihong Wang (3):
vhost: remove useless volatile
vhost: optimize cache access
vhost: shadow used ring update
lib/librte_vhost/vhost.c | 13 ++-
lib/librte_vhost/vhost.h | 5 +-
lib/librte_vhost/vhost_user.c | 23 +++--
lib/librte_vhost/virtio_net.c | 193 +++++++++++++++++++++++++-----------------
4 files changed, 149 insertions(+), 85 deletions(-)
--
1.9.0
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Jerin Jacob @ 2016-10-14 9:26 UTC (permalink / raw)
To: Bill Fischofer
Cc: dev, thomas.monjalon, bruce.richardson, narender.vangati,
Hemant Agrawal, gage.eads
In-Reply-To: <CAKb83kahuY-m52QEsTbL6aPAQxsQ1qPyWcphRienRQiaipVnnA@mail.gmail.com>
On Thu, Oct 13, 2016 at 11:14:38PM -0500, Bill Fischofer wrote:
> Hi Jerin,
Hi Bill,
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.
>
>
> > + /**< 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.
> > + /**< 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
* 16.07.1 stable patches review and test
From: Yuanhan Liu @ 2016-10-14 9:26 UTC (permalink / raw)
To: dpdk stable; +Cc: dev
Hi,
I have applied most of bug fixing patches (listed below) to the 16.07
stable branch at
http://dpdk.org/browse/dpdk-stable/
Please help reviewing and testing. The planned date for the final release
is 26th, Oct. Before that, please shout if anyone has objections with these
patches being applied.
Thanks.
--yliu
---
Alejandro Lucero (1):
net/nfp: fix copying MAC address
Aleksey Katargin (1):
table: fix symbol exports
Alex Zelezniak (1):
net/ixgbe: fix VF reset to apply to correct VF
Ali Volkan Atli (1):
net/e1000: fix returned number of available Rx descriptors
Arek Kusztal (1):
app/test: fix verification of digest for GCM
Beilei Xing (2):
net/i40e: fix dropping packets with ethertype 0x88A8
net/i40e: fix parsing QinQ packets type
Bruce Richardson (1):
net/mlx: fix debug build with gcc 6.1
Christian Ehrhardt (1):
examples/ip_pipeline: fix Python interpreter
Deepak Kumar Jain (2):
crypto/null: fix key size increment value
crypto/qat: fix FreeBSD build
Dror Birkman (1):
net/pcap: fix memory leak in jumbo frames
Ferruh Yigit (2):
app/testpmd: fix help of MTU set commmand
pmdinfogen: fix clang build
Gary Mussar (1):
tools: fix virtio interface name when binding
Gowrishankar Muthukrishnan (1):
examples/ip_pipeline: fix lcore mapping for ppc64
Hiroyuki Mikita (1):
sched: fix releasing enqueued packets
James Poole (1):
app/testpmd: fix timeout in Rx queue flushing
Jianfeng Tan (3):
net/virtio_user: fix first queue pair without multiqueue
net/virtio_user: fix wrong sequence of messages
net/virtio_user: fix error management during init
Jim Harris (1):
contigmem: zero all pages during mmap
John Daley (1):
net/enic: fix bad L4 checksum flag on ICMP packets
Karmarkar Suyash (1):
timer: fix lag delay
Maciej Czekaj (1):
mem: fix crash on hugepage mapping error
Nelson Escobar (1):
net/enic: fix freeing memory for descriptor ring
Olivier Matz (4):
app/testpmd: fix crash when mempool allocation fails
tools: fix json output of pmdinfo
mbuf: fix error handling on pool creation
mem: fix build with -O1
Pablo de Lara (3):
hash: fix ring size
hash: fix false zero signature key hit lookup
crypto: fix build with icc
Qi Zhang (1):
net/i40e/base: fix UDP packet header
Rich Lane (1):
net/i40e: fix null pointer dereferences when using VMDq+RSS
Weiliang Luo (1):
mempool: fix corruption due to invalid handler
Xiao Wang (5):
net/fm10k: fix MAC address removal from switch
net/ixgbe/base: fix pointer check
net/ixgbe/base: fix check for NACK
net/ixgbe/base: fix possible corruption of shadow RAM
net/ixgbe/base: fix skipping PHY config
Yangchao Zhou (1):
pci: fix memory leak when detaching device
Yury Kylulin (2):
net/ixgbe: fix mbuf leak during Rx queue release
net/i40e: fix mbuf leak during Rx queue release
Zhiyong Yang (1):
net/virtio: fix xstats name
^ permalink raw reply
* Re: [PATCH] mempool: Add sanity check when secondary link in less mempools than primary
From: Olivier Matz @ 2016-10-14 8:23 UTC (permalink / raw)
To: jean.tourrilhes, dev, Thomas Monjalon, David Marchand,
Sergio Gonzalez Monroy
In-Reply-To: <20161012200445.GA10029@labs.hpe.com>
Hi Jean,
On 10/12/2016 10:04 PM, Jean Tourrilhes wrote:
> mempool: Add sanity check when secondary link in less mempools than primary
>
> If the primary and secondary process were build using different build
> systems, the list of constructors included by the linker in each
> binary might be different. Mempools are registered via constructors, so
> the linker magic will directly impact which tailqs are registered with
> the primary and the secondary.
>
> DPDK currently assumes that the secondary has a superset of the
> mempools registered at the primary, and they are in the same order
> (same index in primary and secondary). In some build scenario, the
> secondary might not initialise any mempools at all. This would result
> in an obscure segfault when trying to use the mempool. Instead, fail
> early with a more explicit error message.
>
> Signed-off-by: Jean Tourrilhes <jt@labs.hpe.com>
> ---
> lib/librte_mempool/rte_mempool.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
> index 2e28e2e..4fe9158 100644
> --- a/lib/librte_mempool/rte_mempool.c
> +++ b/lib/librte_mempool/rte_mempool.c
> @@ -1275,6 +1275,16 @@ rte_mempool_lookup(const char *name)
> return NULL;
> }
>
> + /* Sanity check : secondary may have initialised less mempools
> + * than primary due to linker and constructor magic. Note that
> + * this does not address the case where the constructor order
> + * is different between primary and secondary and where the index
> + * points to the wrong ops. Jean II */
> + if(mp->ops_index >= (int32_t) rte_mempool_ops_table.num_ops) {
> + /* Do not dump mempool list, it will segfault. */
> + rte_panic("Cannot find ops for mempool, ops_index %d, num_ops %d - maybe due to build process or linker configuration\n", mp->ops_index, rte_mempool_ops_table.num_ops);
> + }
> +
> return mp;
> }
>
>
I'm not really fan of this. I think the configuration and build system
of primary and secondaries should be the same to avoid this kind of
issues. Some other issues may happen if the configuration is different,
for instance the size of structures may be different.
There is already a lot of mess due to primary/secondary at many places
in the code, I'm not sure adding more is really desirable.
Regards,
Olivier
^ permalink raw reply
* Re: [PATCH] net/mlx5: fix hash key size retrieval
From: Adrien Mazarguil @ 2016-10-14 8:20 UTC (permalink / raw)
To: Nelio Laranjeiro; +Cc: dev
In-Reply-To: <494dd0993d87719c80fc6caa9b4586bd3deaa016.1476430165.git.nelio.laranjeiro@6wind.com>
On Fri, Oct 14, 2016 at 09:30:14AM +0200, Nelio Laranjeiro wrote:
> Return RSS key size in struct rte_eth_dev_info.
>
> Fixes: 0f6f219e7919 ("app/testpmd: fix RSS hash key size")
>
> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> ---
> drivers/net/mlx5/mlx5_ethdev.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
> index c1c2d26..b8b3ea9 100644
> --- a/drivers/net/mlx5/mlx5_ethdev.c
> +++ b/drivers/net/mlx5/mlx5_ethdev.c
> @@ -601,6 +601,9 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *info)
> * size if it is not fixed.
> * The API should be updated to solve this problem. */
> info->reta_size = priv->ind_table_max_size;
> + info->hash_key_size = ((*priv->rss_conf) ?
> + (*priv->rss_conf)[0]->rss_key_len :
> + 0);
> info->speed_capa =
> ETH_LINK_SPEED_1G |
> ETH_LINK_SPEED_10G |
> --
> 2.1.4
>
--
Adrien Mazarguil
6WIND
^ permalink raw reply
* Re: [PATCH] app/test: add crypto continual tests
From: Jain, Deepak K @ 2016-10-14 8:18 UTC (permalink / raw)
To: Kusztal, ArkadiuszX, dev@dpdk.org
Cc: Trahe, Fiona, De Lara Guarch, Pablo, Griffin, John
In-Reply-To: <1476361061-7366-1-git-send-email-arkadiuszx.kusztal@intel.com>
> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Thursday, October 13, 2016 1:18 PM
> To: dev@dpdk.org
> Cc: Trahe, Fiona <fiona.trahe@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Griffin, John <john.griffin@intel.com>;
> Jain, Deepak K <deepak.k.jain@intel.com>; Kusztal, ArkadiuszX
> <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH] app/test: add crypto continual tests
>
> This commit adds continual performace tests to Intel(R) QuickAssist
> Technology tests suite. Performance tests are run continually with some
> number of repeating loops.
>
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
> app/test/test_cryptodev_perf.c | 133
> ++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 119 insertions(+), 14 deletions(-)
>
> diff --git a/app/test/test_cryptodev_perf.c
> b/app/test/test_cryptodev_perf.c index 43a7166..dd741fa 100644
> --- a/app/test/test_cryptodev_perf.c
> --
> 2.1.0
Acked-by: Deepak Kumar Jain <deepak.k.jain@intel.com>
^ permalink raw reply
* Re: [PATCH] app/test: add tests with corrupted data for QAT test suite
From: Jain, Deepak K @ 2016-10-14 8:13 UTC (permalink / raw)
To: Kusztal, ArkadiuszX, dev@dpdk.org
Cc: Trahe, Fiona, De Lara Guarch, Pablo, Griffin, John
In-Reply-To: <1476353026-26531-1-git-send-email-arkadiuszx.kusztal@intel.com>
> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Thursday, October 13, 2016 11:04 AM
> To: dev@dpdk.org
> Cc: Trahe, Fiona <fiona.trahe@intel.com>; Jain, Deepak K
> <deepak.k.jain@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Griffin, John <john.griffin@intel.com>;
> Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH] app/test: add tests with corrupted data for QAT test suite
>
> This commit adds tests with corrupted data to the Intel QuickAssist
> Technology tests suite in test_cryptodev.c
>
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
> app/test/test_cryptodev.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> };
> --
> 2.1.0
Acked-by: Deepak Kumar Jain <deepak.k.jain@intel.com>
^ permalink raw reply
* [PATCH v3] vhost: Only access header if offloading is supported in dequeue path
From: Maxime Coquelin @ 2016-10-14 8:07 UTC (permalink / raw)
To: yuanhan.liu, dev
Cc: mst, jianfeng.tan, olivier.matz, stephen, Maxime Coquelin
In-Reply-To: <1475773241-5714-1-git-send-email-maxime.coquelin@redhat.com>
If offloading features are not negotiated, parsing the virtio header
is not needed.
Micro-benchmark with testpmd shows that the gain is +4% with indirect
descriptors, +1% when using direct descriptors.
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
---
Changes since v2:
=================
- Simplify code by translating first desc address
unconditionnaly (Yuanhan)
- Instead of checking features again, check whether
hdr has been assign to call offload function.
Changes since v1:
=================
- Rebased
- Fix early out check in vhost_dequeue_offload
lib/librte_vhost/virtio_net.c | 33 +++++++++++++++++++++++++--------
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
index 812e5d3..15ef0b0 100644
--- a/lib/librte_vhost/virtio_net.c
+++ b/lib/librte_vhost/virtio_net.c
@@ -555,6 +555,18 @@ rte_vhost_enqueue_burst(int vid, uint16_t queue_id,
return virtio_dev_rx(dev, queue_id, pkts, count);
}
+static inline bool
+virtio_net_with_host_offload(struct virtio_net *dev)
+{
+ if (dev->features &
+ (VIRTIO_NET_F_CSUM | VIRTIO_NET_F_HOST_ECN |
+ VIRTIO_NET_F_HOST_TSO4 | VIRTIO_NET_F_HOST_TSO6 |
+ VIRTIO_NET_F_HOST_UFO))
+ return true;
+
+ return false;
+}
+
static void
parse_ethernet(struct rte_mbuf *m, uint16_t *l4_proto, void **l4_hdr)
{
@@ -607,6 +619,9 @@ vhost_dequeue_offload(struct virtio_net_hdr *hdr, struct rte_mbuf *m)
void *l4_hdr = NULL;
struct tcp_hdr *tcp_hdr = NULL;
+ if (hdr->flags == 0 && hdr->gso_type == VIRTIO_NET_HDR_GSO_NONE)
+ return;
+
parse_ethernet(m, &l4_proto, &l4_hdr);
if (hdr->flags == VIRTIO_NET_HDR_F_NEEDS_CSUM) {
if (hdr->csum_start == (m->l2_len + m->l3_len)) {
@@ -702,7 +717,7 @@ copy_desc_to_mbuf(struct virtio_net *dev, struct vring_desc *descs,
uint32_t mbuf_avail, mbuf_offset;
uint32_t cpy_len;
struct rte_mbuf *cur = m, *prev = m;
- struct virtio_net_hdr *hdr;
+ struct virtio_net_hdr *hdr = NULL;
/* A counter to avoid desc dead loop chain */
uint32_t nr_desc = 1;
@@ -715,8 +730,10 @@ copy_desc_to_mbuf(struct virtio_net *dev, struct vring_desc *descs,
if (unlikely(!desc_addr))
return -1;
- hdr = (struct virtio_net_hdr *)((uintptr_t)desc_addr);
- rte_prefetch0(hdr);
+ if (virtio_net_with_host_offload(dev)) {
+ hdr = (struct virtio_net_hdr *)((uintptr_t)desc_addr);
+ rte_prefetch0(hdr);
+ }
/*
* A virtio driver normally uses at least 2 desc buffers
@@ -733,18 +750,18 @@ copy_desc_to_mbuf(struct virtio_net *dev, struct vring_desc *descs,
if (unlikely(!desc_addr))
return -1;
- rte_prefetch0((void *)(uintptr_t)desc_addr);
-
desc_offset = 0;
desc_avail = desc->len;
nr_desc += 1;
-
- PRINT_PACKET(dev, (uintptr_t)desc_addr, desc->len, 0);
} else {
desc_avail = desc->len - dev->vhost_hlen;
desc_offset = dev->vhost_hlen;
}
+ rte_prefetch0((void *)(uintptr_t)(desc_addr + desc_offset));
+
+ PRINT_PACKET(dev, (uintptr_t)(desc_addr + desc_offset), desc_avail, 0);
+
mbuf_offset = 0;
mbuf_avail = m->buf_len - RTE_PKTMBUF_HEADROOM;
while (1) {
@@ -831,7 +848,7 @@ copy_desc_to_mbuf(struct virtio_net *dev, struct vring_desc *descs,
prev->data_len = mbuf_offset;
m->pkt_len += mbuf_offset;
- if (hdr->flags != 0 || hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE)
+ if (hdr)
vhost_dequeue_offload(hdr, m);
return 0;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Wang, Zhihong @ 2016-10-14 7:34 UTC (permalink / raw)
To: Wang, Zhihong, Maxime Coquelin, yuanhan.liu@linux.intel.com,
Xie, Huawei, dev@dpdk.org
Cc: vkaplans@redhat.com, mst@redhat.com, stephen@networkplumber.org
In-Reply-To: <8F6C2BD409508844A0EFC19955BE09414E7CE6D1@SHSMSX103.ccr.corp.intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wang, Zhihong
> Sent: Friday, October 14, 2016 3:25 PM
> To: Maxime Coquelin <maxime.coquelin@redhat.com>;
> yuanhan.liu@linux.intel.com; Xie, Huawei <huawei.xie@intel.com>;
> dev@dpdk.org
> Cc: vkaplans@redhat.com; mst@redhat.com;
> stephen@networkplumber.org
> Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support
> to the TX path
>
>
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Maxime Coquelin
> > Sent: Tuesday, September 27, 2016 4:43 PM
> > To: yuanhan.liu@linux.intel.com; Xie, Huawei <huawei.xie@intel.com>;
> > dev@dpdk.org
> > Cc: vkaplans@redhat.com; mst@redhat.com;
> > stephen@networkplumber.org; Maxime Coquelin
> > <maxime.coquelin@redhat.com>
> > Subject: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support to
> > the TX path
> >
> > Indirect descriptors are usually supported by virtio-net devices,
> > allowing to dispatch a larger number of requests.
> >
> > When the virtio device sends a packet using indirect descriptors,
> > only one slot is used in the ring, even for large packets.
> >
> > The main effect is to improve the 0% packet loss benchmark.
> > A PVP benchmark using Moongen (64 bytes) on the TE, and testpmd
> > (fwd io for host, macswap for VM) on DUT shows a +50% gain for
> > zero loss.
> >
> > On the downside, micro-benchmark using testpmd txonly in VM and
> > rxonly on host shows a loss between 1 and 4%.i But depending on
> > the needs, feature can be disabled at VM boot time by passing
> > indirect_desc=off argument to vhost-user device in Qemu.
> >
> > Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
>
>
> Hi Maxime,
>
> Seems this patch can't with Windows virtio guest in my test.
> Have you done similar tests before?
>
> The way I test:
>
> 1. Make sure https://patchwork.codeaurora.org/patch/84339/ is applied
>
> 2. Start testpmd with iofwd between 2 vhost ports
>
> 3. Start 2 Windows guests connected to the 2 vhost ports
The mrg_rxbuf feature is on.
>
> 4. Disable firewall and assign IP to each guest using ipconfig
>
> 5. Use ping to test connectivity
>
> When I disable this patch by setting:
>
> 0ULL << VIRTIO_RING_F_INDIRECT_DESC,
>
> the connection is fine, but when I restore:
>
> 1ULL << VIRTIO_RING_F_INDIRECT_DESC,
>
> the connection is broken.
>
>
> Thanks
> Zhihong
>
^ permalink raw reply
* Re: [PATCH 0/6] vhost: add Tx zero copy support
From: linhaifeng @ 2016-10-14 7:30 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: dev, Maxime Coquelin
In-Reply-To: <20161010080339.GC1597@yliu-dev.sh.intel.com>
在 2016/10/10 16:03, Yuanhan Liu 写道:
> On Sun, Oct 09, 2016 at 06:46:44PM +0800, linhaifeng wrote:
>> 在 2016/8/23 16:10, Yuanhan Liu 写道:
>>> The basic idea of Tx zero copy is, instead of copying data from the
>>> desc buf, here we let the mbuf reference the desc buf addr directly.
>>
>> Is there problem when push vlan to the mbuf which reference the desc buf addr directly?
>
> Yes, you can't do that when zero copy is enabled, due to following code
> piece:
>
> + if (unlikely(dev->dequeue_zero_copy && (hpa = gpa_to_hpa(dev,
> + desc->addr + desc_offset, cpy_len)))) {
> + cur->data_len = cpy_len;
> ==> + cur->data_off = 0;
> + cur->buf_addr = (void *)(uintptr_t)desc_addr;
> + cur->buf_physaddr = hpa;
>
> The marked line basically makes the mbuf has no headroom to use.
>
> --yliu
>
>> We know if guest use virtio_net(kernel) maybe skb has no headroom.
>
> .
>
It ok to set data_off zero.
But we also can use 128 bytes headromm when guest use virtio_net PMD but not for virtio_net kernel driver.
I think it's better to add headroom size to desc and kernel dirver support set headroom size.
^ permalink raw reply
* [PATCH] net/mlx5: fix hash key size retrieval
From: Nelio Laranjeiro @ 2016-10-14 7:30 UTC (permalink / raw)
To: dev; +Cc: Adrien Mazarguil
Return RSS key size in struct rte_eth_dev_info.
Fixes: 0f6f219e7919 ("app/testpmd: fix RSS hash key size")
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
---
drivers/net/mlx5/mlx5_ethdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index c1c2d26..b8b3ea9 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -601,6 +601,9 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *info)
* size if it is not fixed.
* The API should be updated to solve this problem. */
info->reta_size = priv->ind_table_max_size;
+ info->hash_key_size = ((*priv->rss_conf) ?
+ (*priv->rss_conf)[0]->rss_key_len :
+ 0);
info->speed_capa =
ETH_LINK_SPEED_1G |
ETH_LINK_SPEED_10G |
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Wang, Zhihong @ 2016-10-14 7:24 UTC (permalink / raw)
To: Maxime Coquelin, yuanhan.liu@linux.intel.com, Xie, Huawei,
dev@dpdk.org
Cc: vkaplans@redhat.com, mst@redhat.com, stephen@networkplumber.org
In-Reply-To: <1474965769-24782-1-git-send-email-maxime.coquelin@redhat.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Maxime Coquelin
> Sent: Tuesday, September 27, 2016 4:43 PM
> To: yuanhan.liu@linux.intel.com; Xie, Huawei <huawei.xie@intel.com>;
> dev@dpdk.org
> Cc: vkaplans@redhat.com; mst@redhat.com;
> stephen@networkplumber.org; Maxime Coquelin
> <maxime.coquelin@redhat.com>
> Subject: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support to
> the TX path
>
> Indirect descriptors are usually supported by virtio-net devices,
> allowing to dispatch a larger number of requests.
>
> When the virtio device sends a packet using indirect descriptors,
> only one slot is used in the ring, even for large packets.
>
> The main effect is to improve the 0% packet loss benchmark.
> A PVP benchmark using Moongen (64 bytes) on the TE, and testpmd
> (fwd io for host, macswap for VM) on DUT shows a +50% gain for
> zero loss.
>
> On the downside, micro-benchmark using testpmd txonly in VM and
> rxonly on host shows a loss between 1 and 4%.i But depending on
> the needs, feature can be disabled at VM boot time by passing
> indirect_desc=off argument to vhost-user device in Qemu.
>
> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Hi Maxime,
Seems this patch can't with Windows virtio guest in my test.
Have you done similar tests before?
The way I test:
1. Make sure https://patchwork.codeaurora.org/patch/84339/ is applied
2. Start testpmd with iofwd between 2 vhost ports
3. Start 2 Windows guests connected to the 2 vhost ports
4. Disable firewall and assign IP to each guest using ipconfig
5. Use ping to test connectivity
When I disable this patch by setting:
0ULL << VIRTIO_RING_F_INDIRECT_DESC,
the connection is fine, but when I restore:
1ULL << VIRTIO_RING_F_INDIRECT_DESC,
the connection is broken.
Thanks
Zhihong
^ permalink raw reply
* Re: [PATCH v2] vhost: Only access header if offloading is supported in dequeue path
From: Maxime Coquelin @ 2016-10-14 7:24 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: dev, mst, jianfeng.tan, olivier.matz, stephen
In-Reply-To: <20161011090146.GP1597@yliu-dev.sh.intel.com>
On 10/11/2016 11:01 AM, Yuanhan Liu wrote:
> On Tue, Oct 11, 2016 at 09:45:27AM +0200, Maxime Coquelin wrote:
>> @@ -684,12 +699,12 @@ copy_desc_to_mbuf(struct virtio_net *dev, struct vring_desc *descs,
>> struct rte_mempool *mbuf_pool)
>> {
>> struct vring_desc *desc;
>> - uint64_t desc_addr;
>> + uint64_t desc_addr = 0;
>> uint32_t desc_avail, desc_offset;
>> uint32_t mbuf_avail, mbuf_offset;
>> uint32_t cpy_len;
>> struct rte_mbuf *cur = m, *prev = m;
>> - struct virtio_net_hdr *hdr;
>> + struct virtio_net_hdr *hdr = NULL;
>> /* A counter to avoid desc dead loop chain */
>> uint32_t nr_desc = 1;
>>
>> @@ -698,12 +713,14 @@ copy_desc_to_mbuf(struct virtio_net *dev, struct vring_desc *descs,
>> (desc->flags & VRING_DESC_F_INDIRECT))
>> return -1;
>>
>> - desc_addr = gpa_to_vva(dev, desc->addr);
>> - if (unlikely(!desc_addr))
>> - return -1;
>> + if (virtio_net_with_host_offload(dev)) {
>> + desc_addr = gpa_to_vva(dev, desc->addr);
>> + if (unlikely(!desc_addr))
>> + return -1;
>>
>> - hdr = (struct virtio_net_hdr *)((uintptr_t)desc_addr);
>> - rte_prefetch0(hdr);
>> + hdr = (struct virtio_net_hdr *)((uintptr_t)desc_addr);
>> + rte_prefetch0(hdr);
>> + }
>>
>> /*
>> * A virtio driver normally uses at least 2 desc buffers
>> @@ -720,18 +737,24 @@ copy_desc_to_mbuf(struct virtio_net *dev, struct vring_desc *descs,
>> if (unlikely(!desc_addr))
>> return -1;
>>
>> - rte_prefetch0((void *)(uintptr_t)desc_addr);
>> -
>> desc_offset = 0;
>> desc_avail = desc->len;
>> nr_desc += 1;
>> -
>> - PRINT_PACKET(dev, (uintptr_t)desc_addr, desc->len, 0);
>> } else {
>> + if (!desc_addr) {
>> + desc_addr = gpa_to_vva(dev, desc->addr);
>> + if (unlikely(!desc_addr))
>> + return -1;
>> + }
>> +
>
> I think this piece of code make things a bit complex. I think what you
> want to achieve is, besides saving hdr prefetch, to save one call to
> gpa_to_vva() for the non-ANY_LAYOUT case. Does that matter too much?
>
> How about just saving the hdr prefetch?
>
> if (virtio_net_with_host_offload(dev)) {
> hdr = (struct virtio_net_hdr *)((uintptr_t)desc_addr);
> rte_prefetch0(hdr);
> }
Oops, you reply slipped through the cracks...
You're right, it doesn't matter too much, the thing to avoid id
definitely the hdr prefetch and access.
I'm sending a v3 now.
Thanks,
Maxime
^ permalink raw reply
* Re: [PATCH] doc: how to build KASUMI as shared library
From: Jain, Deepak K @ 2016-10-14 6:52 UTC (permalink / raw)
To: De Lara Guarch, Pablo, dev@dpdk.org; +Cc: De Lara Guarch, Pablo
In-Reply-To: <1476387252-238163-1-git-send-email-pablo.de.lara.guarch@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Pablo de Lara
> Sent: Thursday, October 13, 2016 8:34 PM
> To: dev@dpdk.org
> Cc: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Subject: [dpdk-dev] [PATCH] doc: how to build KASUMI as shared library
>
> Libsso KASUMI library has to be built with specific parameters to make the
> KASUMI PMD be built as a shared library, so a note has been added in its
> documentation.
>
> Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
> ---
> doc/guides/cryptodevs/kasumi.rst | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
> + make KASUMI_CFLAGS=-DKASUMI_C
> +
>
> Initialization
> --------------
> --
> 2.7.4
Acked-by: Deepak Kumar Jain <deepak.k.jain@intel.com>
^ permalink raw reply
* Re: [PATCH] doc: ZUC PMD cannot be built as a shared library
From: Jain, Deepak K @ 2016-10-14 6:51 UTC (permalink / raw)
To: De Lara Guarch, Pablo, dev@dpdk.org; +Cc: De Lara Guarch, Pablo
In-Reply-To: <1476387303-238224-1-git-send-email-pablo.de.lara.guarch@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Pablo de Lara
> Sent: Thursday, October 13, 2016 8:35 PM
> To: dev@dpdk.org
> Cc: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Subject: [dpdk-dev] [PATCH] doc: ZUC PMD cannot be built as a shared
> library
>
> ZUC PMD cannot be built as a shared library, due to the fact that some
> assembly code in the underlying libsso library is not relocatable.
> This will be fixed in the future, but for the moment, it is added as a limitation
> of the PMD.
>
> Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
> ---
> doc/guides/cryptodevs/zuc.rst | 3 +++
> 1 file changed, 3 insertions(+)
>
>
> Installation
> ------------
> --
> 2.7.4
Acked-by: Deepak Kumar Jain <deepak.k.jain@intel.com>
^ permalink raw reply
* Re: [PATCH] doc: fix libcrypto title
From: Jain, Deepak K @ 2016-10-14 6:50 UTC (permalink / raw)
To: De Lara Guarch, Pablo, dev@dpdk.org; +Cc: De Lara Guarch, Pablo
In-Reply-To: <1476387229-238098-1-git-send-email-pablo.de.lara.guarch@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Pablo de Lara
> Sent: Thursday, October 13, 2016 8:34 PM
> To: dev@dpdk.org
> Cc: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Subject: [dpdk-dev] [PATCH] doc: fix libcrypto title
>
> Libcrypto documentation was missing the equal signs ("="), in its title, so it
> was not present in the documentation generated.
>
> Fixes: d61f70b4c918 ("crypto/libcrypto: add driver for OpenSSL library")
>
> Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
> ---
> doc/guides/cryptodevs/libcrypto.rst | 1 +
> 1 file changed, 1 insertion(+)
> --
> 2.7.4
Acked-by: Deepak Kumar Jain <deepak.k.jain@intel.com>
^ permalink raw reply
* Re: [PATCH v9] drivers/net:new PMD using tun/tap host interface
From: Mcnamara, John @ 2016-10-14 6:41 UTC (permalink / raw)
To: Wiles, Keith, dev@dpdk.org
Cc: pmatilai@redhat.com, yuanhan.liu@linux.intel.com, Yigit, Ferruh
In-Reply-To: <1476396234-44694-1-git-send-email-keith.wiles@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Keith Wiles
> Sent: Thursday, October 13, 2016 11:04 PM
> To: dev@dpdk.org
> Cc: pmatilai@redhat.com; yuanhan.liu@linux.intel.com; Yigit, Ferruh
> <ferruh.yigit@intel.com>
> Subject: [dpdk-dev] [PATCH v9] drivers/net:new PMD using tun/tap host
> interface
>
> 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>
For the doc part of the patch:
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply
* [PATCHv3] examples/l3fwd: em: use hw accelerated crc hash function for arm64
From: Hemant Agrawal @ 2016-10-14 11:10 UTC (permalink / raw)
To: dev; +Cc: jerin.jacob, Hemant Agrawal
In-Reply-To: <1476384425-11787-1-git-send-email-hemant.agrawal@nxp.com>
if machine level CRC extension are available, offload the
hash to machine provide functions e.g. armv8-a CRC extensions
support it
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
Reviewed-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
---
examples/l3fwd/l3fwd_em.c | 24 ++++++++++++++----------
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index 89a68e6..9cc4460 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -57,13 +57,17 @@
#include "l3fwd.h"
-#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
+#if defined(RTE_MACHINE_CPUFLAG_SSE4_2) || defined(RTE_MACHINE_CPUFLAG_CRC32)
+#define EM_HASH_CRC 1
+#endif
+
+#ifdef EM_HASH_CRC
#include <rte_hash_crc.h>
#define DEFAULT_HASH_FUNC rte_hash_crc
#else
#include <rte_jhash.h>
#define DEFAULT_HASH_FUNC rte_jhash
-#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#endif
#define IPV6_ADDR_LEN 16
@@ -168,17 +172,17 @@ ipv4_hash_crc(const void *data, __rte_unused uint32_t data_len,
t = k->proto;
p = (const uint32_t *)&k->port_src;
-#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
+#ifdef EM_HASH_CRC
init_val = rte_hash_crc_4byte(t, init_val);
init_val = rte_hash_crc_4byte(k->ip_src, init_val);
init_val = rte_hash_crc_4byte(k->ip_dst, init_val);
init_val = rte_hash_crc_4byte(*p, init_val);
-#else /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#else
init_val = rte_jhash_1word(t, init_val);
init_val = rte_jhash_1word(k->ip_src, init_val);
init_val = rte_jhash_1word(k->ip_dst, init_val);
init_val = rte_jhash_1word(*p, init_val);
-#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#endif
return init_val;
}
@@ -190,16 +194,16 @@ ipv6_hash_crc(const void *data, __rte_unused uint32_t data_len,
const union ipv6_5tuple_host *k;
uint32_t t;
const uint32_t *p;
-#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
+#ifdef EM_HASH_CRC
const uint32_t *ip_src0, *ip_src1, *ip_src2, *ip_src3;
const uint32_t *ip_dst0, *ip_dst1, *ip_dst2, *ip_dst3;
-#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#endif
k = data;
t = k->proto;
p = (const uint32_t *)&k->port_src;
-#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
+#ifdef EM_HASH_CRC
ip_src0 = (const uint32_t *) k->ip_src;
ip_src1 = (const uint32_t *)(k->ip_src+4);
ip_src2 = (const uint32_t *)(k->ip_src+8);
@@ -218,14 +222,14 @@ ipv6_hash_crc(const void *data, __rte_unused uint32_t data_len,
init_val = rte_hash_crc_4byte(*ip_dst2, init_val);
init_val = rte_hash_crc_4byte(*ip_dst3, init_val);
init_val = rte_hash_crc_4byte(*p, init_val);
-#else /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#else
init_val = rte_jhash_1word(t, init_val);
init_val = rte_jhash(k->ip_src,
sizeof(uint8_t) * IPV6_ADDR_LEN, init_val);
init_val = rte_jhash(k->ip_dst,
sizeof(uint8_t) * IPV6_ADDR_LEN, init_val);
init_val = rte_jhash_1word(*p, init_val);
-#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#endif
return init_val;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2] examples/l3fwd: em: use hw accelerated crc hash function for arm64
From: Hemant Agrawal @ 2016-10-14 5:32 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev
In-Reply-To: <20161013133644.GA8096@localhost.localdomain>
On 10/13/2016 7:06 PM, Jerin Jacob wrote:
> On Fri, Oct 14, 2016 at 12:17:05AM +0530, Hemant Agrawal wrote:
>> if machine level CRC extension are available, offload the
>> hash to machine provide functions e.g. armv8-a CRC extensions
>> support it
>>
>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>> Reviewed-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
>> ---
>> examples/l3fwd/l3fwd_em.c | 24 ++++++++++++++----------
>> 1 file changed, 14 insertions(+), 10 deletions(-)
>>
>> diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
>> index 89a68e6..d92d0aa 100644
>> --- a/examples/l3fwd/l3fwd_em.c
>> +++ b/examples/l3fwd/l3fwd_em.c
>> @@ -57,13 +57,17 @@
>>
>> #include "l3fwd.h"
>>
>> -#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
>> +#if defined(RTE_MACHINE_CPUFLAG_SSE4_2) && defined(RTE_MACHINE_CPUFLAG_CRC32)
>
> The will evaluate as FALSE always.
>
> Please change to logical OR operation here. ie #if defined(RTE_MACHINE_CPUFLAG_SSE4_2) ||
> defined(RTE_MACHINE_CPUFLAG_CRC32)
>
Oops! Will fix it.
>> +#define EM_HASH_CRC 1
>> +#endif
>
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Bill Fischofer @ 2016-10-14 4:14 UTC (permalink / raw)
To: Jerin Jacob
Cc: dev, thomas.monjalon, bruce.richardson, narender.vangati,
Hemant Agrawal, gage.eads
In-Reply-To: <1476214216-31982-1-git-send-email-jerin.jacob@caviumnetworks.com>
Hi Jerin,
This looks reasonable and seems a welcome addition to DPDK. A few questions
noted inline:
On Tue, Oct 11, 2016 at 2:30 PM, Jerin Jacob <jerin.jacob@caviumnetworks.com
> wrote:
> 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.
>
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?
+ *
> + * 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;
>
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?
> + /**< 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?
> + 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 */
>
Same question as for queues. 256 seems a small number to be architecting
for this.
> + 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().
>
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.
> + */
> + 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);
>
Having this be a void function implies this function cannot fail. Is that
assumption always correct?
> +
> +/**
> + * 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
* [PATCH v2 5/5] maintainers: claim i40e vector PMD on ARM
From: Jianbo Liu @ 2016-10-14 4:00 UTC (permalink / raw)
To: helin.zhang, jingjing.wu, jerin.jacob, dev, qi.z.zhang; +Cc: Jianbo Liu
In-Reply-To: <1476417604-22400-1-git-send-email-jianbo.liu@linaro.org>
Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8f5fa82..621bda6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -151,6 +151,7 @@ F: lib/librte_acl/acl_run_neon.*
F: lib/librte_lpm/rte_lpm_neon.h
F: lib/librte_hash/rte*_arm64.h
F: drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
+F: drivers/net/i40e/i40e_rxtx_vec_neon.c
F: drivers/net/virtio/virtio_rxtx_simple_neon.c
EZchip TILE-Gx
--
2.4.11
^ permalink raw reply related
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