[dpdk-dev] VFIO no-iommu
Hello, I am not involved in the vfio very much, however, I was watching some vfio-related code in last few weeks. It looks promising to me and IMHO it seems to the best way to bring a support of integrated Ethernet MACs into DPDK (related to many SoCs). Unfortunately, the ARMv7 SoCs (I know) lacks of an IOMMU... The only protection there is the TrustZone technology but I have no idea of its support in the kernel. It's also far from being a replacement of an IOMMU. When using FPGAs, it is possible to put an IOMMU engine there (I've got such a prototype somewhere in my VHDL library) but nobody will probably do use because of saving on-chip resources. The X-Gene SoC (ARM 64) contains 2x 10 Gbps EMACs on the chip. I have no idea about IOMMUs there. Thus, this platform can probably benefit of such driver as well. The question is whether there is some interest to have this kind of support in DPDK. Thus, I'd like to have the vfio/no-iommu to support the ARMv7 (otherwise it would be effectively dead in DPDK). Unfortunately, it's not my primary job at the moment. Regards Jan Note: as far as I know, it is discouraged to refer to lkml.org as it is often very slow - my case today :). On Fri, 11 Dec 2015 17:28:43 +0100 Thomas Monjalon wrote: > Recently there were some discussions to have an upstream replacement > for our igb_uio module. > Several solutions were discussed (new uio driver, uio_pci_generic, vfio): > https://lkml.org/lkml/2015/10/16/700 > > Alex Williamson (maintainer of VFIO driver), submitted a solution > and was waiting some feedback. Unfortunately, nobody caught it and > he has reverted his work: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ae5515d > > It is an important challenge to remove our out-of-tree modules and > especially igb_uio. It is a long way to have a standard solution integrated > in every distributions. > The current cooking Linux kernel is 4.4 and will have a long term maintenance: > https://kernel.org/releases.html > So it is a pity to miss this opportunity. > > Stephen has fixed a bug to use the IOMMU group zero: > http://dpdk.org/browse/dpdk/commit/?id=22215f141b1 > > Is there someone interested to work on VFIO no-iommu and provide > some feedbacks? > We also need to prepare a documentation patch to explain its usage > compared to the standard VFIO mode. > > Thanks
[dpdk-dev] [PATCH] mbuf_offload: mark experimental state
Cryptodev was marked experimental and mbuf_offload depends on it.
The mbuf_offload library is one of the crypto area which requires
some discussions before having a stable API.
The experimental mark is also added to rte_cryptodev_configure()
to be sure one cannot miss it.
Fixes: 66874e55f550 ("cryptodev: mark experimental state")
Signed-off-by: Thomas Monjalon
---
MAINTAINERS| 2 +-
config/common_bsdapp | 1 +
config/common_linuxapp | 1 +
lib/librte_cryptodev/rte_cryptodev.h | 2 ++
lib/librte_mbuf_offload/rte_mbuf_offload.h | 5 +
5 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a3ff3f2..3292e84 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -217,7 +217,7 @@ F: lib/librte_mbuf/
F: doc/guides/prog_guide/mbuf_lib.rst
F: app/test/test_mbuf.c
-Packet buffer offload
+Packet buffer offload - EXPERIMENTAL
M: Declan Doherty
F: lib/librte_mbuf_offload/
diff --git a/config/common_bsdapp b/config/common_bsdapp
index 07328d9..8a4d448 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -362,6 +362,7 @@ CONFIG_RTE_PKTMBUF_HEADROOM=128
#
# Compile librte_mbuf_offload
+# EXPERIMENTAL: API may change without prior notice
#
CONFIG_RTE_LIBRTE_MBUF_OFFLOAD=y
CONFIG_RTE_LIBRTE_MBUF_OFFLOAD_DEBUG=n
diff --git a/config/common_linuxapp b/config/common_linuxapp
index ba9e55d..dda309c 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -379,6 +379,7 @@ CONFIG_RTE_PKTMBUF_HEADROOM=128
#
# Compile librte_mbuf_offload
+# EXPERIMENTAL: API may change without prior notice
#
CONFIG_RTE_LIBRTE_MBUF_OFFLOAD=y
CONFIG_RTE_LIBRTE_MBUF_OFFLOAD_DEBUG=n
diff --git a/lib/librte_cryptodev/rte_cryptodev.h
b/lib/librte_cryptodev/rte_cryptodev.h
index aa9f785..892375d 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -243,6 +243,8 @@ struct rte_cryptodev_config {
/**
* Configure a device.
*
+ * EXPERIMENTAL: this API file may change without prior notice
+ *
* 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.
diff --git a/lib/librte_mbuf_offload/rte_mbuf_offload.h
b/lib/librte_mbuf_offload/rte_mbuf_offload.h
index f52f163..4345f06 100644
--- a/lib/librte_mbuf_offload/rte_mbuf_offload.h
+++ b/lib/librte_mbuf_offload/rte_mbuf_offload.h
@@ -51,6 +51,9 @@
* operations, with supporting allocate and free functions. It also provides
* APIs for attaching an offload to a mbuf, as well as an API to retrieve a
* specified offload type from an mbuf offload chain.
+ *
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
*/
#include
@@ -92,6 +95,8 @@ struct rte_pktmbuf_offload_pool_private {
/**
* Creates a mempool of rte_mbuf_offload objects
*
+ * EXPERIMENTAL: this API file may change without prior notice
+ *
* @param namemempool name
* @param sizenumber of objects in mempool
* @param cache_size cache size of objects for each core
--
2.5.2
[dpdk-dev] [PATCH] mbuf_offload: mark experimental state
2015-12-12 00:34, Thomas Monjalon:
> Cryptodev was marked experimental and mbuf_offload depends on it.
> The mbuf_offload library is one of the crypto area which requires
> some discussions before having a stable API.
>
> The experimental mark is also added to rte_cryptodev_configure()
> to be sure one cannot miss it.
>
> Fixes: 66874e55f550 ("cryptodev: mark experimental state")
>
> Signed-off-by: Thomas Monjalon
Applied shortly
[dpdk-dev] [dpdk-announce] new mailing list for the website git tree
Hi, As discussed recently at Dublin, the git tree for the website is now public: http://dpdk.org/browse/tools/dpdk-web And a dedicated mailing-list has been created: http://dpdk.org/ml http://dpdk.org/ml/archives/web/2015-December/00.html The short-term goal is to train this new workflow for some time with some small updates, i.e. related to 2.2 release and future roadmap. Please let's try with few minor patches/contributions until end of January. Then we will check how to progress. Thanks and welcome to web contributors
[dpdk-dev] [PATCH] xenvirt: fix compilation issues
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Huawei at dpdk.org
> Sent: Thursday, December 10, 2015 11:16 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] xenvirt: fix compilation issues
>
> Reported-by: Christian Ehrhardt
> Signed-off-by: Huawei Xie
> ---
> drivers/net/xenvirt/rte_mempool_gntalloc.c | 6 +++---
> drivers/net/xenvirt/rte_xen_lib.c | 4 ++--
> drivers/net/xenvirt/virtqueue.h| 4 ++--
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/xenvirt/rte_mempool_gntalloc.c
> b/drivers/net/xenvirt/rte_mempool_gntalloc.c
> index 3a650e8..0585f08 100644
> --- a/drivers/net/xenvirt/rte_mempool_gntalloc.c
> +++ b/drivers/net/xenvirt/rte_mempool_gntalloc.c
> @@ -184,10 +184,10 @@ _create_mempool(const char *name, unsigned
> elt_num, unsigned elt_size,
> rv = ioctl(gntalloc_fd,
> IOCTL_GNTALLOC_DEALLOC_GREF, &arg);
> if (rv) {
> /* shouldn't fail here */
> - RTE_LOG(ERR, PMD, "va=%p pa=%p
> index=%p %s\n",
> + RTE_LOG(ERR, PMD, "va=%p
> pa=%"PRIu64"x index=%"PRIu64" %s\n",
> gnt_arr[i].va,
> - (void *)gnt_arr[i].pa,
> - (void *)arg.index,
> strerror(errno));
> + gnt_arr[i].pa,
> + arg.index, strerror(errno));
> rte_panic("gntdealloc failed when
> freeing pages\n");
> }
> }
> diff --git a/drivers/net/xenvirt/rte_xen_lib.c
> b/drivers/net/xenvirt/rte_xen_lib.c
> index 3e97c1a..de63cd3 100644
> --- a/drivers/net/xenvirt/rte_xen_lib.c
> +++ b/drivers/net/xenvirt/rte_xen_lib.c
> @@ -115,8 +115,8 @@ get_phys_map(void *va, phys_addr_t pa[], uint32_t
> pg_num, uint32_t pg_sz)
> (rc = pread(fd, pa, nb, ofs)) < 0 ||
> (rc -= nb) != 0) {
> RTE_LOG(ERR, PMD, "%s: failed read of %u bytes from \'%s\'
> "
> - "at offset %zu, error code: %d\n",
> - __func__, nb, PAGEMAP_FNAME, ofs, errno);
> + "at offset %lu, error code: %d\n",
> + __func__, nb, PAGEMAP_FNAME, (unsigned
> long)ofs, errno);
> rc = ENOENT;
> }
>
> diff --git a/drivers/net/xenvirt/virtqueue.h
> b/drivers/net/xenvirt/virtqueue.h
> index 6dcb0ef..5312347 100644
> --- a/drivers/net/xenvirt/virtqueue.h
> +++ b/drivers/net/xenvirt/virtqueue.h
> @@ -55,7 +55,7 @@ struct rte_mbuf;
> * rather than gpa<->hva in virito spec.
> */
> #define RTE_MBUF_DATA_DMA_ADDR(mb) \
> - rte_pktmbuf_mtod(mb, uint64_t)
> + ((uint64_t)(uintptr_t)rte_pktmbuf_mtod(mb, void *))
>
> enum { VTNET_RQ = 0, VTNET_TQ = 1, VTNET_CQ = 2 };
>
> @@ -198,7 +198,7 @@ virtqueue_enqueue_recv_refill(struct virtqueue
> *rxvq, struct rte_mbuf *cookie)
> dxp->ndescs = needed;
>
> start_dp[head_idx].addr =
> - (uint64_t) ((uint64_t)cookie->buf_addr +
> RTE_PKTMBUF_HEADROOM - sizeof(struct virtio_net_hdr));
> + (uint64_t) ((uintptr_t)cookie->buf_addr +
> RTE_PKTMBUF_HEADROOM - sizeof(struct virtio_net_hdr));
> start_dp[head_idx].len = cookie->buf_len -
> RTE_PKTMBUF_HEADROOM + sizeof(struct virtio_net_hdr);
> start_dp[head_idx].flags = VRING_DESC_F_WRITE;
> rxvq->vq_desc_head_idx = start_dp[head_idx].next;
> --
> 1.8.1.4
Looks good to me. Just one thing, shall we keep unified on printing out either
errno, or strerror(errno)?
Acked-by: Jianfeng Tan
Thanks,
Jianfeng
[dpdk-dev] [PATCH] virtio: fix virtio_net_hdr desc pointing to the same buffer
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Huawei at dpdk.org > Sent: Friday, December 11, 2015 12:08 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] virtio: fix virtio_net_hdr desc pointing to the > same buffer > > The virtio_net_hdr desc all pointed to the same buffer. It doesn't cause > issue because in the simple TX mode we don't use the header. This patch > makes the header desc point to different buffer. > > Signed-off-by: Huawei Xie > --- > drivers/net/virtio/virtio_rxtx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/virtio/virtio_rxtx.c > b/drivers/net/virtio/virtio_rxtx.c > index 74b39ef..6cfd315 100644 > --- a/drivers/net/virtio/virtio_rxtx.c > +++ b/drivers/net/virtio/virtio_rxtx.c > @@ -352,7 +352,7 @@ virtio_dev_vring_start(struct virtqueue *vq, int > queue_type) > vq->vq_ring.desc[i + mid_idx].next = i; > vq->vq_ring.desc[i + mid_idx].addr = > vq->virtio_net_hdr_mem + > - mid_idx * vq->hw- > >vtnet_hdr_size; > + i * vq->hw->vtnet_hdr_size; > vq->vq_ring.desc[i + mid_idx].len = > vq->hw->vtnet_hdr_size; > vq->vq_ring.desc[i + mid_idx].flags = > -- > 1.8.1.4 So in the case when header is not used, shall the way of pointing to all header bufs to one buf help improve the performance? At least, it saves some of cache lines. Thanks, Jianfeng
[dpdk-dev] [PATCH] examples/performance-thread: fix - cleanup before exit
Fixes: 433ba6228f9a77a9b5f4 ("add pthread_shim app")
The patch fixes an inverted return value in the
cond_destroy and cond_init APIs of the pthread shim
example.
These APIs are now demonstrated in the sample app by
having the mutexes and condition variables
explicitly destroyed before the appplication terminates.
Signed-off-by: Ian Betts
---
examples/performance-thread/pthread_shim/main.c | 4
examples/performance-thread/pthread_shim/pthread_shim.c | 11 +--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/examples/performance-thread/pthread_shim/main.c
b/examples/performance-thread/pthread_shim/main.c
index 2f67c1b..dab379a 100644
--- a/examples/performance-thread/pthread_shim/main.c
+++ b/examples/performance-thread/pthread_shim/main.c
@@ -211,6 +211,10 @@ static void initial_lthread(void *args
__attribute__((unused)))
printf("error on thread exit\n");
}
+ pthread_cond_destroy(&exit_cond);
+ pthread_mutex_destroy(&print_lock);
+ pthread_mutex_destroy(&exit_lock);
+
/* shutdown the lthread scheduler */
lthread_scheduler_shutdown(rte_lcore_id());
lthread_detach();
diff --git a/examples/performance-thread/pthread_shim/pthread_shim.c
b/examples/performance-thread/pthread_shim/pthread_shim.c
index 30cd68a..eda9d55 100644
--- a/examples/performance-thread/pthread_shim/pthread_shim.c
+++ b/examples/performance-thread/pthread_shim/pthread_shim.c
@@ -327,17 +327,24 @@ int pthread_cond_broadcast(pthread_cond_t *cond)
return _sys_pthread_funcs.f_pthread_cond_broadcast(cond);
}
+int pthread_mutex_destroy(pthread_mutex_t *mutex)
+{
+ if (override)
+ return lthread_mutex_destroy(*(struct lthread_mutex **)mutex);
+ return _sys_pthread_funcs.f_pthread_mutex_destroy(mutex);
+}
+
int pthread_cond_destroy(pthread_cond_t *cond)
{
if (override)
- return -lthread_cond_destroy(*(struct lthread_cond **)cond);
+ return lthread_cond_destroy(*(struct lthread_cond **)cond);
return _sys_pthread_funcs.f_pthread_cond_destroy(cond);
}
int pthread_cond_init(pthread_cond_t *cond, const pthread_condattr_t *attr)
{
if (override)
- return -lthread_cond_init(NULL,
+ return lthread_cond_init(NULL,
(struct lthread_cond **)cond,
(const struct lthread_condattr *) attr);
return _sys_pthread_funcs.f_pthread_cond_init(cond, attr);
--
2.1.4
[dpdk-dev] [PATCH] mlx4: update documentation
-Split "Features" and "Limitations" sections. -Update limitations with missing information. -Update prerequisites with supported MLNX_OFED release, firmware and CPU architectures. -Enhance usage example with openibd script. Signed-off-by: Olga Shern Signed-off-by: Adrien Mazarguil --- doc/guides/nics/mlx4.rst | 24 +++- 1 files changed, 19 insertions(+), 5 deletions(-) diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst index 562db06..62f0c31 100644 --- a/doc/guides/nics/mlx4.rst +++ b/doc/guides/nics/mlx4.rst @@ -78,8 +78,8 @@ long as they share the same MAC address. Compiling librte_pmd_mlx4 causes DPDK to be linked against libibverbs. -Features and limitations - +Features +- - RSS, also known as RCA, is supported. In this mode the number of configured RX queues must be a power of two. @@ -91,11 +91,17 @@ Features and limitations - Scattered packets are supported for TX and RX. - Inner L3/L4 (IP, TCP and UDP) TX/RX checksum offloading and validation. - Outer L3 (IP) TX/RX checksum offloading and validation for VXLAN frames. +- Secondary process TX is supported. -.. break +Limitations +--- - RSS hash key cannot be modified. +- RSS RETA cannot be configured +- RSS always includes L3 (IPv4/IPv6) and L4 (UDP/TCP). They cannot be + dissociated. - Hardware counters are not implemented (they are software counters). +- Secondary process RX is not supported Configuration - @@ -237,8 +243,9 @@ DPDK and must be installed separately: Currently supported by DPDK: -- Mellanox OFED **3.0**. -- Firmware version **2.34.5000** and higher. +- Mellanox OFED **3.1**. +- Firmware version **2.35.5100** and higher. +- Supported architectures: **x86_64** and **POWER8**. Getting Mellanox OFED ~ @@ -272,6 +279,13 @@ devices managed by librte_pmd_mlx4. modprobe -a ib_uverbs mlx4_en mlx4_core mlx4_ib + Alternatively if MLNX_OFED is fully installed, the follwoing script can + be run: + + .. code-block:: console + + /etc/init.d/openibd restart + .. note:: User space I/O kernel modules (uio and igb_uio) are not used and do -- 1.7.8.2
[dpdk-dev] [PATCH] mlx5: update documentation
- Update features, limitations, configuration and prerequisites sections. - Add a note to describe RSS behavior differences with librte_pmd_mlx4 in testpmd. Signed-off-by: Olga Shern Signed-off-by: Adrien Mazarguil --- doc/guides/nics/mlx5.rst | 67 +++-- 1 files changed, 58 insertions(+), 9 deletions(-) diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index eb8c042..1f700fc 100644 --- a/doc/guides/nics/mlx5.rst +++ b/doc/guides/nics/mlx5.rst @@ -78,19 +78,23 @@ Features - Multiple TX and RX queues. - Support for scattered TX and RX frames. -- IPv4, TCPv4 and UDPv4 RSS on any number of queues. +- IPv4, IPv6, TCPv4, TCPv6, UDPv4 and UDPv6 RSS on any number of queues. - Several RSS hash keys, one for each flow type. +- Configurable RETA table. - Support for multiple MAC addresses. - VLAN filtering. - Promiscuous mode. +- Multicast promiscuous mode. +- Hardware checksum offloads. Limitations --- -- IPv6 and inner VXLAN RSS are not supported yet. +- KVM and VMware ESX SR-IOV modes are not supported yet. +- Inner RSS for VXLAN frames is not supported yet. - Port statistics through software counters only. -- No allmulticast mode. -- Hardware checksum offloads are not supported yet. +- Hardware checksum offloads for VXLAN inner header are not supported yet. +- Secondary processes are not supported yet. Configuration - @@ -119,8 +123,13 @@ These options can be modified in the ``.config`` file. - ``CONFIG_RTE_LIBRTE_MLX5_MAX_INLINE`` (default **0**) - Amount of data to be inlined during TX operations. Improves latency but - lowers throughput. + Amount of data to be inlined during TX operations. Improves latency. + Can improve PPS performance when PCI backpressure is detected and may be + useful for scenarios involving heavy traffic on many queues. + + Since the additional software logic necessary to handle this mode can + lower performance when there is no backpressure, it is not enabled by + default. - ``CONFIG_RTE_LIBRTE_MLX5_TX_MP_CACHE`` (default **8**) @@ -205,10 +214,26 @@ DPDK and must be installed separately: Currently supported by DPDK: -- Mellanox OFED **3.1**. +- Mellanox OFED **3.1-1.0.3** or **3.1-1.5.7.1** depending on usage. + +The following features are supported with version **3.1-1.5.7.1** and +above only: + +- IPv6, UPDv6, TCPv6 RSS. +- RX checksum offloads. +- IBM POWER8. + - Minimum firmware version: - - ConnectX-4: **12.12.0780**. - - ConnectX-4 Lx: **14.12.0780**. + + With MLNX_OFED **3.1-1.0.3**: + + - ConnectX-4: **12.12.1240** + - ConnectX-4 Lx: **14.12.1100** + + With MLNX_OFED **3.1-1.5.7.1**: + + - ConnectX-4: **12.13.0144** + - ConnectX-4 Lx: **14.13.0144** Getting Mellanox OFED ~ @@ -230,6 +255,23 @@ required from that distribution. this DPDK release was developed and tested against is strongly recommended. Please check the `prerequisites`_. +Notes for testpmd +- + +Compared to librte_pmd_mlx4 that implements a single RSS configuration per +port, librte_pmd_mlx5 supports per-protocol RSS configuration. + +Since ``testpmd`` defaults to IP RSS mode and there is currently no +command-line parameter to enable additional protocols (UDP and TCP as well +as IP), the following commands must be entered from its CLI to get the same +behavior as librte_pmd_mlx4: + +.. code-block:: console + + > port stop all + > port config all rss all + > port start all + Usage example - @@ -242,6 +284,13 @@ devices managed by librte_pmd_mlx5. modprobe -a ib_uverbs mlx5_core mlx5_ib + Alternatively if MLNX_OFED is fully installed, the follwoing script can + be run: + + .. code-block:: console + + /etc/init.d/openibd restart + .. note:: User space I/O kernel modules (uio and igb_uio) are not used and do -- 1.7.8.2
[dpdk-dev] [PATCH] examples/performance-thread: fix - cleanup before exit
2015-12-12 08:12, Ian Betts:
> Fixes: 433ba6228f9a77a9b5f4 ("add pthread_shim app")
>
> The patch fixes an inverted return value in the
> cond_destroy and cond_init APIs of the pthread shim
> example.
>
> These APIs are now demonstrated in the sample app by
> having the mutexes and condition variables
> explicitly destroyed before the appplication terminates.
>
> Signed-off-by: Ian Betts
Applied, thanks
[dpdk-dev] [PATCH] examples/netmap_compat: Fix compile issue with POLLRDNORM
2015-12-11 14:36, Michael Qiu: > examples/netmap_compat/bridge/../lib/compat_netmap.c:880:41: > error: ?POLLRDNORM? undeclared (first use in this function) > > The root casue is POLLRDNORM is more-or-less nonstandard, and it > depends on macro "__USE_XOPEN". > > Fixes: 06371afe394d (examples/netmap_compat: import netmap compatibility > example) > > In suse11 sp3, POLLRDNORM will not be defined because "__USE_XOPEN" > issue. > > This patch add check if it is not defined, define it. > > Signed-off-by: Michael Qiu Applied, thanks
[dpdk-dev] [PATCH v1] eal: fix negative value incorrectly being used defect
2015-12-11 15:54, David Marchand:
> Hello Cunming,
>
> On Fri, Dec 11, 2015 at 2:48 AM, Cunming Liang
> wrote:
>
> > In eal_intr_proc_rxtx_intr, negative value may be used as argument to a
> > function expecting a positive value. If 'read' returns EAGAIN as example,
> > the bytes_read updates to a negative value which continue be passed as
> > argument for the next 'read'.
> >
> > Coverity issue: 107115
> >
> > 927do {
> > 3. negative_return_fn: Function read(fd, &buf, bytes_read) returns a
> > negative number.
> > 4. var_assign: Assigning: signed variable bytes_read = read.
> > CID 107115 (#1 of 1): Argument cannot be negative
> > (NEGATIVE_RETURNS)9. negative_returns: bytes_read is passed to a
> > parameter
> > that cannot be negative.
> > 928bytes_read = read(fd, &buf, bytes_read);
> >
> > Fixes: c9f3ec1a0f3f ("eal/linux: add Rx interrupt control function")
> >
> > Signed-off-by: Cunming Liang
> >
>
> Acked-by: David Marchand
Applied, thanks
[dpdk-dev] [PATCH] xenvirt: fix compilation issues
> > Reported-by: Christian Ehrhardt > > Signed-off-by: Huawei Xie > > Looks good to me. Just one thing, shall we keep unified on printing out > either errno, or strerror(errno)? > > Acked-by: Jianfeng Tan Applied, thanks
[dpdk-dev] [PATCH] example/ip_pipeline: fix buffer size warning
> > Coverity issue: 107102
> > Fixes: 7f64b9c004aa ("examples/ip_pipeline: rework config file syntax")
> >
> > Signed-off-by: Fan Zhang
> > Acked-by: Cristian Dumitrescu
>
> Acked-by: John McNamara
Series applied, thanks
(Not really a series but threaded like it)
