Re: [dpdk-dev] [PATCH] vhost: fix sprintf with snprintf

2019-02-04 Thread Maxime Coquelin
On 2/4/19 8:28 AM, Pallantla Poornima wrote: sprintf function is not secure as it doesn't check the length of string. More secure function snprintf is used. Fixes: d7280c9fff ("vhost: support selective datapath") Cc: sta...@dpdk.org Signed-off-by: Pallantla Poornima --- lib/librte_vhost/v

Re: [dpdk-dev] [PATCH v3 2/2] ci: Introduce travis builds for github repositories

2019-02-04 Thread Bruce Richardson
On Fri, Feb 01, 2019 at 11:48:14AM -0500, Michael Santana wrote: > GitHub is a service used by developers to store repositories. GitHub > provides service integrations that allow 3rd party services to access > developer repositories and perform actions. One of these services is > Travis-CI, a sim

Re: [dpdk-dev] [PATCH] build: add option to override max ethports

2019-02-04 Thread Bruce Richardson
On Thu, Jan 31, 2019 at 06:26:41PM -0500, Chas Williams wrote: > > > On 1/31/19 4:32 AM, Bruce Richardson wrote: > > On Wed, Jan 30, 2019 at 09:18:58PM -0500, Chas Williams wrote: > > > Allow users and packagers to override the default RTE_MAX_ETHPORTS. > > > This adds a new meson option, max_eth

Re: [dpdk-dev] [PATCH 1/2 v2] build: add option to override max ethports

2019-02-04 Thread Bruce Richardson
On Thu, Jan 31, 2019 at 06:53:25PM -0500, Chas Williams wrote: > Allow users and packagers to override the default RTE_MAX_ETHPORTS. > This adds a new meson option, max_ethports which defaults to the > current value. > Actually in this v2, you have changed it to 64 from 32. :-) Otherwise all fine

Re: [dpdk-dev] [PATCH 2/2,v2] build: fix option ordering

2019-02-04 Thread Bruce Richardson
On Thu, Jan 31, 2019 at 06:59:20PM -0500, Chas Williams wrote: > Sort the options alphabetically and make a note of the preferred > order at the top of the file. > > Signed-off-by: Chas Williams <3ch...@gmail.com> > --- > meson_options.txt | 14 -- > 1 file changed, 8 insertions(+), 6

Re: [dpdk-dev] [PATCH] maintainers: claim co-maintainership of LPM

2019-02-04 Thread Bruce Richardson
On Sun, Feb 03, 2019 at 04:34:45PM +, Vladimir Medvedkin wrote: > Signed-off-by: Vladimir Medvedkin > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 835d8a201..eef480ab5 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1133,6

Re: [dpdk-dev] A Question about the necessity of DPDK VF for Ethernet PMDs

2019-02-04 Thread Alejandro Lucero
Hi Rami, Your concern is related to this thread: http://mails.dpdk.org/archives/dev/2019-January/123466.html I'm working on solving the problem when PF needs to be bound to VFIO. My proposal is to use mediated devices. Although it is not strictly necessary to rely on current kernel WiP about VFI

Re: [dpdk-dev] A Question about the necessity of DPDK VF for Ethernet PMDs

2019-02-04 Thread Rami Rosen
Hi Alejandro, >Your concern is related to this thread Thanks for your reply, I was aware of this thread. Still, I am not sure, in current kernels and currently available Ethernet DPDK PMDs about the answer to my queries (I don't think this mail thread gives info about it), like about what are th

[dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison

2019-02-04 Thread Anoob Joseph
The string compare to the length of driver name might give false positives when there are drivers with similar names (one being the subset of another). Following is such a naming which could result in false positive. 1. crypto_driver 2. crypto_driver1 When strncmp with len = strlen("crypto_driver

Re: [dpdk-dev] A Question about the necessity of DPDK VF for Ethernet PMDs

2019-02-04 Thread Alejandro Lucero
On Mon, Feb 4, 2019 at 10:44 AM Rami Rosen wrote: > Hi Alejandro, > > >Your concern is related to this thread > > Thanks for your reply, I was aware of this thread. > OK > Still, I am not sure, in current kernels and currently available Ethernet > DPDK PMDs about the answer to my queries (I don

Re: [dpdk-dev] A Question about the necessity of DPDK VF for Ethernet PMDs

2019-02-04 Thread Rami Rosen
Hi, Alejandro, Thanks for you quick response. >When SRIOV is used by VMs, the slow path will always be faster (and >with lower latency) with DPDK. Yes, I am referring primarily to the SRIOV case in my question, when assigning PCI VF to a VM (most likely QEMU VM) Can you please explain what you m

Re: [dpdk-dev] A Question about the necessity of DPDK VF for Ethernet PMDs

2019-02-04 Thread Alejandro Lucero
On Mon, Feb 4, 2019 at 12:19 PM Rami Rosen wrote: > Hi, Alejandro, > > Thanks for you quick response. > > >When SRIOV is used by VMs, the slow path will always be faster (and > >with lower latency) with DPDK. > > Yes, I am referring primarily to the SRIOV case in my question, when > assigning PCI

Re: [dpdk-dev] [PATCH 1/1] eal: add 128-bit cmpset (x86-64 only)

2019-02-04 Thread Honnappa Nagarahalli
> > > > On Mon, 2019-01-28 at 11:29 -0600, Gage Eads wrote: > > > This operation can be used for non-blocking algorithms, such as a > > > non-blocking stack or ring. > > > > > > Signed-off-by: Gage Eads > > > --- > > >  .../common/include/arch/x86/rte_atomic_64.h| 31 +++ > > >  lib