Re: [dpdk-dev] [RFC v2 00/23] Dynamic memory allocation for DPDK

[Nélio Laranjeiro]

On Mon, Feb 05, 2018 at 10:36:58AM +, Burakov, Anatoly wrote:
> On 05-Feb-18 10:18 AM, Nélio Laranjeiro wrote:
> > On Mon, Feb 05, 2018 at 10:03:35AM +, Burakov, Anatoly wrote:
> > > On 02-Feb-18 7:28 PM, Yongseok Koh wrote:
> > > > On Tue, Dec 26, 2017 at 05:19:25PM +, Walker, Benjamin wrote:
> > > > > On Fri, 2017-12-22 at 09:13 +, Burakov, Anatoly wrote:
> > > > > > On 21-Dec-17 9:38 PM, Walker, Benjamin wrote:
> > > > > > > SPDK will need some way to register for a notification when pages 
> > > > > > > are
> > > > > > > allocated
> > > > > > > or freed. For storage, the number of requests per second is 
> > > > > > > (relative to
> > > > > > > networking) fairly small (hundreds of thousands per second in a 
> > > > > > > traditional
> > > > > > > block storage stack, or a few million per second with SPDK). 
> > > > > > > Given that, we
> > > > > > > can
> > > > > > > afford to do a dynamic lookup from va to pa/iova on each request 
> > > > > > > in order to
> > > > > > > greatly simplify our APIs (users can just pass pointers around 
> > > > > > > instead of
> > > > > > > mbufs). DPDK has a way to lookup the pa from a given va, but it 
> > > > > > > does so by
> > > > > > > scanning /proc/self/pagemap and is very slow. SPDK instead 
> > > > > > > handles this by
> > > > > > > implementing a lookup table of va to pa/iova which we populate by 
> > > > > > > scanning
> > > > > > > through the DPDK memory segments at start up, so the lookup in 
> > > > > > > our table is
> > > > > > > sufficiently fast for storage use cases. If the list of memory 
> > > > > > > segments
> > > > > > > changes,
> > > > > > > we need to know about it in order to update our map.
> > > > > > 
> > > > > > Hi Benjamin,
> > > > > > 
> > > > > > So, in other words, we need callbacks on alloa/free. What 
> > > > > > information
> > > > > > would SPDK need when receiving this notification? Since we can't 
> > > > > > really
> > > > > > know in advance how many pages we allocate (it may be one, it may 
> > > > > > be a
> > > > > > thousand) and they no longer are guaranteed to be contiguous, would 
> > > > > > a
> > > > > > per-page callback be OK? Alternatively, we could have one callback 
> > > > > > per
> > > > > > operation, but only provide VA and size of allocated memory, while
> > > > > > leaving everything else to the user. I do add a virt2memseg() 
> > > > > > function
> > > > > > which would allow you to look up segment physical addresses easier, 
> > > > > > so
> > > > > > you won't have to manually scan memseg lists to get IOVA for a 
> > > > > > given VA.
> > > > > > 
> > > > > > Thanks for your feedback and suggestions!
> > > > > 
> > > > > Yes - callbacks on alloc/free would be perfect. Ideally for us we 
> > > > > want one
> > > > > callback per virtual memory region allocated, plus a function we can 
> > > > > call to
> > > > > find the physical addresses/page break points on that virtual region. 
> > > > > The
> > > > > function that finds the physical addresses does not have to be 
> > > > > efficient - we'll
> > > > > just call that once when the new region is allocated and store the 
> > > > > results in a
> > > > > fast lookup table. One call per virtual region is better for us than 
> > > > > one call
> > > > > per physical page because we're actually keeping multiple different 
> > > > > types of
> > > > > memory address translation tables in SPDK. One translates from va to 
> > > > > pa/iova, so
> > > > > for this one we need to break this up into physical pages and it 
> > > > > doesn't matter
> > > > > if you do one call per virtual region or one per physical page. 
> > > > > However another
> > > > > one translates from va to RDMA lkey, so it is much more efficient if 
> > > > > we can
> > > > > register large virtual regions in a single call.
> > > > 
> > > > Another yes to callbacks. Like Benjamin mentioned about RDMA, MLX PMD 
> > > > has to
> > > > look up LKEY per each packet DMA. Let me briefly explain about this for 
> > > > your
> > > > understanding. For security reason, we don't allow application 
> > > > initiates a DMA
> > > > transaction with unknown random physical addresses. Instead, va-to-pa 
> > > > mapping
> > > > (we call it Memory Region) should be pre-registered and LKEY is the 
> > > > index of the
> > > > translation entry registered in device. With the current static memory 
> > > > model, it
> > > > is easy to manage because v-p mapping is unchanged over time. But if it 
> > > > becomes
> > > > dynamic, MLX PMD should get notified with the event to 
> > > > register/un-regsiter
> > > > Memory Region.
> > > > 
> > > > For MLX PMD, it is also enough to get one notification per 
> > > > allocation/free of a
> > > > virutal memory region. It shouldn't necessarily be a per-page call like 
> > > > Benjamin
> > > > mentioned because PA of region doesn't need to be contiguous for 
> > > > registration.
> > > > But it doesn't need to know about physical address of the region

Re: [dpdk-dev] [PATCH 1/7] cxgbe: fix secondary process initialization

[Rahul Lakkireddy]

On Monday, February 02/05/18, 2018 at 22:53:36 +0530, Ferruh Yigit wrote:
> On 2/4/2018 6:06 AM, Rahul Lakkireddy wrote:
> > From: Kumar Sanghvi 
> > 
> > rte_eth_dev_allocate already assigns the eth_dev_data. So,
> > don't allocate it separately as part of probe function. And we
> > save this eth_dev_data as part of txq structure.
> > 
> > Attach to rte_eth_dev devices allocated by Primary process for
> > Ports other than Port-0 in the secondary process.
> > 
> > Fixes: 8318984927ff ("cxgbe: add pmd skeleton")
> > Signed-off-by: Kumar Sanghvi 
> > Signed-off-by: Rahul Lakkireddy 
> > ---
> >  doc/guides/nics/features/cxgbe.ini |  1 +
> >  drivers/net/cxgbe/base/adapter.h   |  1 +
> >  drivers/net/cxgbe/cxgbe_ethdev.c   | 28 +++-
> >  drivers/net/cxgbe/cxgbe_main.c | 11 ++-
> >  drivers/net/cxgbe/sge.c|  5 +++--
> >  5 files changed, 30 insertions(+), 16 deletions(-)
> > 
> > diff --git a/doc/guides/nics/features/cxgbe.ini 
> > b/doc/guides/nics/features/cxgbe.ini
> > index 3d0fde2fd..1b9d81ffb 100644
> > --- a/doc/guides/nics/features/cxgbe.ini
> > +++ b/doc/guides/nics/features/cxgbe.ini
> > @@ -24,6 +24,7 @@ Basic stats  = Y
> >  Stats per queue  = Y
> >  EEPROM dump  = Y
> >  Registers dump   = Y
> > +Multiprocess aware   = Y
> >  BSD nic_uio  = Y
> >  Linux UIO= Y
> >  Linux VFIO   = Y
> > diff --git a/drivers/net/cxgbe/base/adapter.h 
> > b/drivers/net/cxgbe/base/adapter.h
> > index f2057af14..0c1a1be25 100644
> > --- a/drivers/net/cxgbe/base/adapter.h
> > +++ b/drivers/net/cxgbe/base/adapter.h
> > @@ -267,6 +267,7 @@ struct sge_eth_tx_stats {   /* Ethernet tx queue 
> > statistics */
> >  struct sge_eth_txq {   /* state for an SGE Ethernet Tx 
> > queue */
> > struct sge_txq q;
> > struct rte_eth_dev *eth_dev;   /* port that this queue belongs to */
> > +   struct rte_eth_dev_data *data;
> 
> Why you need to store a local copy of data? You have to store/know eth_dev, 
> and
> I believe it is always better idea to access data through eth_dev. Perhaps we
> even should hide this access with macro etc. Not sure about motivation of 
> this.
> 

Considering an example of Multiprocess Server and Client app, with
command-line like:
# mp_server -l 1-2 -n 4 -- -p 3 -n 2
# mp_client -l 3 -n 4 --proc-type=auto -- -n 0
# mp_client -l 4 -n 4 --proc-type=auto -- -n 1

Below is the flow...

For Primary process:
- For Port-0, eth_dev comes from stack.
- For Port-1 and onwards, we allocate eth_dev via
  rte_eth_dev_allocate().
Both will have its own eth_dev_data.
Also, in primary, we allocate TxQ, RxQ and associate them with
respective eth_dev available in Primary.

   
For Secondary process:
New Port-0 ethdev would be allocated. However, it will attach to
eth_dev_data of Primary's Port-0.
New Port-1 ethdev would be allocated. However, it will now attach
to eth_dev_data of Primary's Port-1.

When Secondary process transmits on Port-1, it transmits over Port-1
ethdev allocated in Secondary process.
Since this ethdev has same eth_dev_data of Primary's Port-1 - it
transmits over TxQ allocated in Primary process.
 
Now, when we are in t4_eth_xmit (via cxgbe_xmit_pkts), all we have is a
TxQ. And in Primary process, we always associate TxQ with respective
ethdev i.e. in this case, it would be Port-1 ethdev of Primary. So, for
retrieving max_rx_pkt_len in t4_eth_xmit, when we access txq->eth_dev -
it is NULL ---> because secondary process can't access eth_dev of
Primary.

And thats why, we need a pointer for directly accessing the eth_dev_data
from t4_eth_xmit.

> > struct sge_eth_tx_stats stats; /* queue statistics */
> > rte_spinlock_t txq_lock;
> >  
> > diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c 
> > b/drivers/net/cxgbe/cxgbe_ethdev.c
> > index 5cd260f48..6d56f3c1b 100644
> > --- a/drivers/net/cxgbe/cxgbe_ethdev.c
> > +++ b/drivers/net/cxgbe/cxgbe_ethdev.c
> > @@ -1004,14 +1004,32 @@ static int eth_cxgbe_dev_init(struct rte_eth_dev 
> > *eth_dev)
> > eth_dev->dev_ops = &cxgbe_eth_dev_ops;
> > eth_dev->rx_pkt_burst = &cxgbe_recv_pkts;
> > eth_dev->tx_pkt_burst = &cxgbe_xmit_pkts;
> > +   pci_dev = RTE_ETH_DEV_TO_PCI(eth_dev);
> >  
> > -   /* for secondary processes, we don't initialise any further as primary
> > -* has already done this work.
> > +   /* for secondary processes, we attach to ethdevs allocated by primary
> > +* and do minimal initialization.
> >  */
> > -   if (rte_eal_process_type() != RTE_PROC_PRIMARY)
> > +   if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
> > +   int i;
> > +
> > +   for (i = 1; i < MAX_NPORTS; i++) {
> > +   struct rte_eth_dev *rest_eth_dev;
> > +   char namei[RTE_ETH_NAME_MAX_LEN];
> > +
> > +   snprintf(namei, sizeof(namei), "cxgbe%d", i);
> > +   rest_eth_dev = rte_eth_dev_attach_secondary(namei);
> > +   if (rest_et

[dpdk-dev] [PATCH] net/mlx5: fix flow RSS configuration

[Nelio Laranjeiro]

An RSS configuration without a key is valid according to the
rte_eth_rss_conf API definition.

Fixes: 8086cf08b2f0 ("net/mlx5: handle RSS hash configuration in RSS flow")

Cc: sta...@dpdk.org
Reported-by: Yuanhan Liu 
Signed-off-by: Nelio Laranjeiro 
---
 drivers/net/mlx5/mlx5_flow.c | 29 +
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index ea90556d0..fd6f96083 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -514,7 +514,8 @@ mlx5_flow_item_validate(const struct rte_flow_item *item,
 }
 
 /**
- * Copy the RSS configuration from the user ones.
+ * Copy the RSS configuration from the user ones, of the rss_conf is null,
+ * uses the driver one.
  *
  * @param priv
  *   Pointer to private structure.
@@ -531,21 +532,25 @@ priv_flow_convert_rss_conf(struct priv *priv,
   struct mlx5_flow_parse *parser,
   const struct rte_eth_rss_conf *rss_conf)
 {
-   const struct rte_eth_rss_conf *rss;
-
+   /*
+* This function is also called at the beginning of
+* priv_flow_convert_actions() to initialise the parser with the
+* device default RSS configuration.
+*/
+   (void)priv;
if (rss_conf) {
if (rss_conf->rss_hf & MLX5_RSS_HF_MASK)
return EINVAL;
-   rss = rss_conf;
-   } else {
-   rss = &priv->rss_conf;
+   if (rss_conf->rss_key_len != 40)
+   return EINVAL;
+   if (rss_conf->rss_key_len && rss_conf->rss_key) {
+   parser->rss_conf.rss_key_len = rss_conf->rss_key_len;
+   memcpy(parser->rss_key, rss_conf->rss_key,
+  rss_conf->rss_key_len);
+   parser->rss_conf.rss_key = parser->rss_key;
+   }
+   parser->rss_conf.rss_hf = rss_conf->rss_hf;
}
-   if (rss->rss_key_len > 40)
-   return EINVAL;
-   parser->rss_conf.rss_key_len = rss->rss_key_len;
-   parser->rss_conf.rss_hf = rss->rss_hf;
-   memcpy(parser->rss_key, rss->rss_key, rss->rss_key_len);
-   parser->rss_conf.rss_key = parser->rss_key;
return 0;
 }
 
-- 
2.11.0

Re: [dpdk-dev] [PATCH 3/7] cxgbe: add support to update RSS hash configuration and key

[Rahul Lakkireddy]

On Monday, February 02/05/18, 2018 at 22:39:55 +0530, Ferruh Yigit wrote:
> On 2/4/2018 6:06 AM, Rahul Lakkireddy wrote:
> > From: Kumar Sanghvi 
> > 
> > Add firmware API for updating RSS hash configuration and key.  Move
> > RSS hash configuration from cxgb4_write_rss() to a separate function
> > cxgbe_write_rss_conf().
> > 
> > Also, rename cxgb4_write_rss() to cxgbe_write_rss() for consistency.
> > 
> > Original work by Surendra Mobiya 
> > 
> > Signed-off-by: Kumar Sanghvi 
> > Signed-off-by: Rahul Lakkireddy 
> > ---
> >  doc/guides/nics/cxgbe.rst   |  2 +
> >  doc/guides/nics/features/cxgbe.ini  |  1 +
> >  doc/guides/rel_notes/release_18_02.rst  |  3 ++
> >  drivers/net/cxgbe/base/adapter.h|  4 +-
> >  drivers/net/cxgbe/base/common.h |  3 ++
> >  drivers/net/cxgbe/base/t4_hw.c  | 73 +++
> >  drivers/net/cxgbe/base/t4_regs.h| 25 +
> >  drivers/net/cxgbe/base/t4fw_interface.h | 89 
> > +
> >  drivers/net/cxgbe/cxgbe.h   |  2 +
> >  drivers/net/cxgbe/cxgbe_ethdev.c| 32 
> >  drivers/net/cxgbe/cxgbe_main.c  | 79 ++---
> >  11 files changed, 295 insertions(+), 18 deletions(-)
> 
> I tend to get driver patches even after integration deadline, mainly because 
> of
> their limited scope.
> But since these are new features, submitted just before rc3, adding with
> questions in first patch, I am for postponing this patchset to next release 
> and
> do more review, what do you think?

Does dpdk-next-net tree work similar to linux "next" trees?  I mean does
it represent the next release (DPDK 18.05-rc1) merge window?  Can we
explicitly mention in Patch title which tree it is targeted for viz.
dpdk or dpdk-next-net?

Thanks,
Rahul

[dpdk-dev] [PATCH] net/mlx5: fix UAR remapping on non configured queues

[Nelio Laranjeiro]

priv_tx_uar_remap() is wrongly considering the queue is already configured
and thus present in the queue array of the device.

Fixes: f8b9a3bad467 ("net/mlx5: install a socket to exchange a file descriptor")
Cc: xuemi...@mellanox.com

Cc: sta...@dpdk.org
Signed-off-by: Nelio Laranjeiro 
---
 drivers/net/mlx5/mlx5_txq.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_txq.c b/drivers/net/mlx5/mlx5_txq.c
index 23002cf86..ed1c713ea 100644
--- a/drivers/net/mlx5/mlx5_txq.c
+++ b/drivers/net/mlx5/mlx5_txq.c
@@ -296,6 +296,8 @@ priv_tx_uar_remap(struct priv *priv, int fd)
 * Ref to libmlx5 function: mlx5_init_context()
 */
for (i = 0; i != priv->txqs_n; ++i) {
+   if (!(*priv->txqs)[i])
+   continue;
txq = (*priv->txqs)[i];
txq_ctrl = container_of(txq, struct mlx5_txq_ctrl, txq);
/* UAR addr form verbs used to find dup and offset in page. */
-- 
2.11.0

Re: [dpdk-dev] [PATCH v3] eal: add function to return number of detected sockets

[Burakov, Anatoly]

On 05-Feb-18 10:45 PM, Thomas Monjalon wrote:

05/02/2018 18:39, Burakov, Anatoly:

On 05-Feb-18 4:37 PM, Anatoly Burakov wrote:

During lcore scan, find maximum socket ID and store it.

Signed-off-by: Anatoly Burakov 
---

Notes:
  v3:
  - Added ABI backwards compatibility
  
  v2:

  - checkpatch changes
  - check socket before deciding if the core is not to be used

   lib/librte_eal/common/eal_common_lcore.c  | 37 
+--
   lib/librte_eal/common/include/rte_eal.h   | 25 +
   lib/librte_eal/common/include/rte_lcore.h |  8 +++
   lib/librte_eal/linuxapp/eal/eal.c | 27 +-
   lib/librte_eal/rte_eal_version.map|  9 +++-
   5 files changed, 92 insertions(+), 14 deletions(-)



This patch does not break ABI, but does it in a very ugly way. Is it
worth it?


I think we agreed to not get this patch in 18.02.
Did you change your mind?



Sorry, how do i mark this patch as for 18.05? Is it a patch header?

--
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH 0/8] vhost: input validation enhancements

[Maxime Coquelin]

Hi Stefan,

On 02/05/2018 01:16 PM, Stefan Hajnoczi wrote:

This patch series addresses missing input validation that I came across when
reviewing vhost_user.c.

The first patch explains the security model and the rest fixes places with
missing checks.

Now is a good time to discuss the security model if anyone disagrees or has
questions about what Patch 1 says.


Thanks for the series, I agree validating vhost-user inputs is
necessary.

I'll go through the series, but it will be only for v18.05, as we are
close now to v18.02 release.

Maxime


Stefan Hajnoczi (8):
   vhost: add security model documentation to vhost_user.c
   vhost: avoid enum fields in VhostUserMsg
   vhost: validate untrusted memory.nregions field
   vhost: clear out unused SCM_RIGHTS file descriptors
   vhost: reject invalid log base mmap_offset values
   vhost: fix msg->payload union typo in vhost_user_set_vring_addr()
   vhost: validate virtqueue size
   vhost: check for memory_size + mmap_offset overflow

  lib/librte_vhost/vhost_user.h |  4 +--
  lib/librte_vhost/socket.c |  8 +-
  lib/librte_vhost/vhost_user.c | 57 +--
  3 files changed, 64 insertions(+), 5 deletions(-)

Re: [dpdk-dev] [PATCH v3] eal: add function to return number of detected sockets

[Thomas Monjalon]

06/02/2018 10:28, Burakov, Anatoly:
> On 05-Feb-18 10:45 PM, Thomas Monjalon wrote:
> > 05/02/2018 18:39, Burakov, Anatoly:
> >> On 05-Feb-18 4:37 PM, Anatoly Burakov wrote:
> >>> During lcore scan, find maximum socket ID and store it.
> >>>
> >>> Signed-off-by: Anatoly Burakov 
> >>> ---
> >>>
> >>> Notes:
> >>>   v3:
> >>>   - Added ABI backwards compatibility
> >>>   
> >>>   v2:
> >>>   - checkpatch changes
> >>>   - check socket before deciding if the core is not to be used
> >>>
> >>>lib/librte_eal/common/eal_common_lcore.c  | 37 
> >>> +--
> >>>lib/librte_eal/common/include/rte_eal.h   | 25 +
> >>>lib/librte_eal/common/include/rte_lcore.h |  8 +++
> >>>lib/librte_eal/linuxapp/eal/eal.c | 27 +-
> >>>lib/librte_eal/rte_eal_version.map|  9 +++-
> >>>5 files changed, 92 insertions(+), 14 deletions(-)
> >>>
> >>
> >> This patch does not break ABI, but does it in a very ugly way. Is it
> >> worth it?
> > 
> > I think we agreed to not get this patch in 18.02.
> > Did you change your mind?
> > 
> 
> Sorry, how do i mark this patch as for 18.05? Is it a patch header?

So your answer is "yes, it is for 18.05" :)

Next time, you could add 18.05 near "PATCH v3", or say it in annotations.

Re: [dpdk-dev] [PATCH 2/8] vhost: avoid enum fields in VhostUserMsg

[Maxime Coquelin]

On 02/05/2018 01:16 PM, Stefan Hajnoczi wrote:

The VhostUserMsg struct binary representation must match the vhost-user
protocol specification since this struct is read from and written to the
socket.

The VhostUserMsg.request union contains enum fields.  Enum binary
representation is implementation-defined according to the C standard and
it is unportable to make assumptions about the representation:

   6.7.2.2 Enumeration specifiers
   ...
   Each enumerated type shall be compatible with char, a signed integer
   type, or an unsigned integer type. The choice of type is
   implementation-defined, but shall be capable of representing the
   values of all the members of the enumeration.

Additionally, librte_vhost relies on the enum type being unsigned when
validating untrusted inputs:

   if (ret <= 0 || msg.request.master >= VHOST_USER_MAX) {

If msg.request.master is signed then negative values pass this check!

Even if we assume gcc on x86_64 (SysV amd64 ABI) and don't care about
portability, the actual enum constants still affect the final type.  For
example, if we add a negative constant then its type changes to signed
int:

   typedef enum VhostUserRequest {
   ...
   VHOST_USER_INVALID = -1,
   };

This is very fragile and it's unlikely that anyone changing the code
would remember this.  A security hole can be introduced accidentally.

This patch switches VhostUserMsg.request fields to uint32_t to avoid the
portability and potential security issues.

Signed-off-by: Stefan Hajnoczi 
---
  lib/librte_vhost/vhost_user.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_vhost/vhost_user.h b/lib/librte_vhost/vhost_user.h
index d4bd604b9..0fafbe6e0 100644
--- a/lib/librte_vhost/vhost_user.h
+++ b/lib/librte_vhost/vhost_user.h
@@ -81,8 +81,8 @@ typedef struct VhostUserLog {
  
  typedef struct VhostUserMsg {

union {
-   VhostUserRequest master;
-   VhostUserSlaveRequest slave;
+   uint32_t master; /* a VhostUserRequest value */
+   uint32_t slave;  /* a VhostUserSlaveRequest value*/
} request;
  
  #define VHOST_USER_VERSION_MASK 0x3




Maybe we could simplify to:

typedef struct VhostUserMsg {
uint32_t request; /* a VhostUserRequest or VhostUserSlaveRequest value 
*/
...

Also, it seems QEMU's vhost-user master implementation uses an enum for
the request in its VhostUserMsg struct. Should it be fixed too?

Thanks,
Maxime

Re: [dpdk-dev] [PATCH 0/8] vhost: input validation enhancements

[Maxime Coquelin]

On 02/05/2018 01:16 PM, Stefan Hajnoczi wrote:

This patch series addresses missing input validation that I came across when
reviewing vhost_user.c.

The first patch explains the security model and the rest fixes places with
missing checks.

Now is a good time to discuss the security model if anyone disagrees or has
questions about what Patch 1 says.

Stefan Hajnoczi (8):
   vhost: add security model documentation to vhost_user.c
   vhost: avoid enum fields in VhostUserMsg
   vhost: validate untrusted memory.nregions field
   vhost: clear out unused SCM_RIGHTS file descriptors
   vhost: reject invalid log base mmap_offset values
   vhost: fix msg->payload union typo in vhost_user_set_vring_addr()
   vhost: validate virtqueue size
   vhost: check for memory_size + mmap_offset overflow

  lib/librte_vhost/vhost_user.h |  4 +--
  lib/librte_vhost/socket.c |  8 +-
  lib/librte_vhost/vhost_user.c | 57 +--
  3 files changed, 64 insertions(+), 5 deletions(-)



For the series:

Reviewed-by: Maxime Coquelin 

For patch 2, my suggestion can be handled separately.

Thanks,
Maxime

Re: [dpdk-dev] [PATCH 3/7] cxgbe: add support to update RSS hash configuration and key

[Ferruh Yigit]

On 2/6/2018 9:22 AM, Rahul Lakkireddy wrote:
> On Monday, February 02/05/18, 2018 at 22:39:55 +0530, Ferruh Yigit wrote:
>> On 2/4/2018 6:06 AM, Rahul Lakkireddy wrote:
>>> From: Kumar Sanghvi 
>>>
>>> Add firmware API for updating RSS hash configuration and key.  Move
>>> RSS hash configuration from cxgb4_write_rss() to a separate function
>>> cxgbe_write_rss_conf().
>>>
>>> Also, rename cxgb4_write_rss() to cxgbe_write_rss() for consistency.
>>>
>>> Original work by Surendra Mobiya 
>>>
>>> Signed-off-by: Kumar Sanghvi 
>>> Signed-off-by: Rahul Lakkireddy 
>>> ---
>>>  doc/guides/nics/cxgbe.rst   |  2 +
>>>  doc/guides/nics/features/cxgbe.ini  |  1 +
>>>  doc/guides/rel_notes/release_18_02.rst  |  3 ++
>>>  drivers/net/cxgbe/base/adapter.h|  4 +-
>>>  drivers/net/cxgbe/base/common.h |  3 ++
>>>  drivers/net/cxgbe/base/t4_hw.c  | 73 +++
>>>  drivers/net/cxgbe/base/t4_regs.h| 25 +
>>>  drivers/net/cxgbe/base/t4fw_interface.h | 89 
>>> +
>>>  drivers/net/cxgbe/cxgbe.h   |  2 +
>>>  drivers/net/cxgbe/cxgbe_ethdev.c| 32 
>>>  drivers/net/cxgbe/cxgbe_main.c  | 79 ++---
>>>  11 files changed, 295 insertions(+), 18 deletions(-)
>>
>> I tend to get driver patches even after integration deadline, mainly because 
>> of
>> their limited scope.
>> But since these are new features, submitted just before rc3, adding with
>> questions in first patch, I am for postponing this patchset to next release 
>> and
>> do more review, what do you think?
> 
> Does dpdk-next-net tree work similar to linux "next" trees?  I mean does
> it represent the next release (DPDK 18.05-rc1) merge window?  Can we
> explicitly mention in Patch title which tree it is targeted for viz.
> dpdk or dpdk-next-net?

Hi Rahul,

It is not like Linux next trees, this is more like Dave's net tree.
In dpdk responsibilities split into sub-trees, and all target current release,
patches merged into sub-trees and pulled by main tree in integration deadline.

All network drivers and ethdev abstraction layer patches goes into next-net
sub-tree.


Briefly overall process is [1]:
- A new feature needs to be sent before proposal deadline, this can be a full
version of the set or RFC. Proposal deadline for the release announced in
https://dpdk.org/dev/roadmap

- After that point code reviews done and new versions sent till integration
deadline. Accepted patches are integrated to release candidate 1 (rc1).
Of course patch can be reviewed and merged without waiting integration deadline.
If a patch not get an approval and merge into tree in integration deadline,
most probably it won't go into release.

- Fixes can be sent from beginning of release to rcX. Only latest rcX mostly for
the fixes on features introduced in that release.

- After rc1, code tested and fixes sent for found defects. No new feature
expected after rc1.

- We go mostly to rc3 or rc4 before release.


[1]
Thomas, please correct me if I missed something. And this needs to be documented
indeed.

> 
> Thanks,
> Rahul
> 

Re: [dpdk-dev] [PATCH 1/7] vhost: make capabilities configurable

[Maxime Coquelin]

Hi Zhihong,

On 02/03/2018 12:28 AM, Zhihong Wang wrote:

This patch makes vhost device capabilities configurable to adopt new
devices, since different devices may have different capabilities, like
different combinations of supported features, or different number of
queues. APIs are introduced to let app configure these capabilities.

Signed-off-by: Zhihong Wang 
---
  lib/librte_vhost/rte_vhost.h  | 50 
  lib/librte_vhost/socket.c | 77 +++
  lib/librte_vhost/vhost_user.c | 48 ---
  3 files changed, 164 insertions(+), 11 deletions(-)


...


diff --git a/lib/librte_vhost/socket.c b/lib/librte_vhost/socket.c
index 6e3857e..e1d0036 100644
--- a/lib/librte_vhost/socket.c
+++ b/lib/librte_vhost/socket.c
@@ -49,7 +49,10 @@ struct vhost_user_socket {
 * features negotiation.
 */
uint64_t supported_features;
+   uint64_t supported_protocol_features;
uint64_t features;
+   uint64_t protocol_features;
+   uint16_t queue_num;
  
  	struct vhost_device_ops const *notify_ops;

  };
@@ -593,6 +596,75 @@ rte_vhost_driver_get_features(const char *path, uint64_t 
*features)
}
  }
  
+int rte_vhost_driver_set_protocol_features(const char *path,

+   uint64_t protocol_features)
+{
+   struct vhost_user_socket *vsocket;
+
+   pthread_mutex_lock(&vhost_user.mutex);
+   vsocket = find_vhost_user_socket(path);
+   if (vsocket) {
+   vsocket->supported_protocol_features = protocol_features;
+   vsocket->protocol_features = protocol_features;
+   }
+   pthread_mutex_unlock(&vhost_user.mutex);
+
+   return vsocket ? 0 : -1;
+}
+
+int
+rte_vhost_driver_get_protocol_features(const char *path,
+   uint64_t *protocol_features)
+{
+   struct vhost_user_socket *vsocket;
+
+   pthread_mutex_lock(&vhost_user.mutex);
+   vsocket = find_vhost_user_socket(path);
+   if (vsocket)
+   *protocol_features = vsocket->protocol_features;
+   pthread_mutex_unlock(&vhost_user.mutex);
+
+   if (!vsocket) {
+   RTE_LOG(ERR, VHOST_CONFIG,
+   "socket file %s is not registered yet.\n", path);
+   return -1;
+   } else {
+   return 0;
+   }
+}
+
+int rte_vhost_driver_set_queue_num(const char *path, uint16_t queue_num)
+{
+   struct vhost_user_socket *vsocket;
+
+   pthread_mutex_lock(&vhost_user.mutex);
+   vsocket = find_vhost_user_socket(path);
+   if (vsocket)
+   vsocket->queue_num = queue_num;


Shouldn't be MIN(queue_num, VHOST_MAX_QUEUE_PAIRS) to be sure you can
switch from HW offload to SW processing?


+   pthread_mutex_unlock(&vhost_user.mutex);
+
+   return vsocket ? 0 : -1;
+}
+
+int rte_vhost_driver_get_queue_num(const char *path, uint16_t *queue_num)
+{
+   struct vhost_user_socket *vsocket;
+
+   pthread_mutex_lock(&vhost_user.mutex);
+   vsocket = find_vhost_user_socket(path);
+   if (vsocket)
+   *queue_num = vsocket->queue_num;
+   pthread_mutex_unlock(&vhost_user.mutex);
+
+   if (!vsocket) {
+   RTE_LOG(ERR, VHOST_CONFIG,
+   "socket file %s is not registered yet.\n", path);
+   return -1;
+   } else {
+   return 0;
+   }
+}
+
  /*
   * Register a new vhost-user socket; here we could act as server
   * (the default case), or client (when RTE_VHOST_USER_CLIENT) flag
@@ -655,6 +727,11 @@ rte_vhost_driver_register(const char *path, uint64_t flags)
vsocket->features &= ~(1ULL << VIRTIO_F_IOMMU_PLATFORM);
}
  
+	vsocket->supported_protocol_features = VHOST_USER_PROTOCOL_FEATURES;

+   vsocket->protocol_features   = VHOST_USER_PROTOCOL_FEATURES;
+
+   vsocket->queue_num = VHOST_MAX_QUEUE_PAIRS;
+
if ((flags & RTE_VHOST_USER_CLIENT) != 0) {
vsocket->reconnect = !(flags & RTE_VHOST_USER_NO_RECONNECT);
if (vsocket->reconnect && reconn_tid == 0) {
diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
index 1dd1a61..87ba267 100644
--- a/lib/librte_vhost/vhost_user.c
+++ b/lib/librte_vhost/vhost_user.c
@@ -127,6 +127,18 @@ vhost_user_reset_owner(struct virtio_net *dev)
  }
  
  /*

+ * The supported queue num.
+ */
+static uint16_t
+vhost_user_get_queue_num(struct virtio_net *dev)
+{
+   uint16_t queue_num = 0;
+
+   rte_vhost_driver_get_queue_num(dev->ifname, &queue_num);
+   return queue_num;
+}
+
+/*
   * The features that we support are requested.
   */
  static uint64_t
@@ -930,13 +942,17 @@ vhost_user_set_vring_enable(struct virtio_net *dev,
return 0;
  }
  
-static void

-vhost_user_get_protocol_features(struct virtio_net *dev,
-struct VhostUserMsg *msg)
+/*
+ * The protocol features that we support are requested.
+ */
+
+static uint64_t

[dpdk-dev] [PATCH] kni: optimize the kni release speed

[zhouyangchao]

Physical addresses in the fifo named alloc_q need to be traversed to release
in user space. The physical address to the virtual address conversion in
kernel space is much better.

Signed-off-by: Yangchao Zhou 
---
 lib/librte_eal/linuxapp/kni/kni_dev.h  |  1 +
 lib/librte_eal/linuxapp/kni/kni_misc.c |  1 +
 lib/librte_eal/linuxapp/kni/kni_net.c  | 15 +++
 lib/librte_kni/rte_kni.c   | 26 +-
 4 files changed, 18 insertions(+), 25 deletions(-)

diff --git a/lib/librte_eal/linuxapp/kni/kni_dev.h 
b/lib/librte_eal/linuxapp/kni/kni_dev.h
index c9393d8..7cd9bf8 100644
--- a/lib/librte_eal/linuxapp/kni/kni_dev.h
+++ b/lib/librte_eal/linuxapp/kni/kni_dev.h
@@ -92,6 +92,7 @@ struct kni_dev {
void *alloc_va[MBUF_BURST_SZ];
 };
 
+void kni_net_fifo_pa2va(struct kni_dev *kni);
 void kni_net_rx(struct kni_dev *kni);
 void kni_net_init(struct net_device *dev);
 void kni_net_config_lo_mode(char *lo_str);
diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c 
b/lib/librte_eal/linuxapp/kni/kni_misc.c
index 01574ec..668488b 100644
--- a/lib/librte_eal/linuxapp/kni/kni_misc.c
+++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
@@ -507,6 +507,7 @@ kni_ioctl_release(struct net *net, uint32_t ioctl_num,
dev->pthread = NULL;
}
 
+   kni_net_fifo_pa2va(dev);
kni_dev_remove(dev);
list_del(&dev->list);
ret = 0;
diff --git a/lib/librte_eal/linuxapp/kni/kni_net.c 
b/lib/librte_eal/linuxapp/kni/kni_net.c
index 9f9b798..662a527 100644
--- a/lib/librte_eal/linuxapp/kni/kni_net.c
+++ b/lib/librte_eal/linuxapp/kni/kni_net.c
@@ -73,6 +73,21 @@ va2pa(void *va, struct rte_kni_mbuf *m)
return pa;
 }
 
+/* convert physical addresses to virtual addresses in fifo for kni release */
+void
+kni_net_fifo_pa2va(struct kni_dev *kni)
+{
+   void *fifo = kni->alloc_q;
+   int i, count = kni_fifo_count(fifo);
+   void *pa = NULL, *kva, *va;
+   for (i = 0; i < count; ++i) {
+   (void)kni_fifo_get(fifo, &pa, 1);
+   kva = pa2kva(pa);
+   va = pa2va(pa, kva);
+   (void)kni_fifo_put(fifo, &va, 1);
+   }
+}
+
 /*
  * It can be called to process the request.
  */
diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
index 2867411..f8398a9 100644
--- a/lib/librte_kni/rte_kni.c
+++ b/lib/librte_kni/rte_kni.c
@@ -435,30 +435,6 @@ va2pa(struct rte_mbuf *m)
 (unsigned long)m->buf_iova));
 }
 
-static void
-obj_free(struct rte_mempool *mp __rte_unused, void *opaque, void *obj,
-   unsigned obj_idx __rte_unused)
-{
-   struct rte_mbuf *m = obj;
-   void *mbuf_phys = opaque;
-
-   if (va2pa(m) == mbuf_phys)
-   rte_pktmbuf_free(m);
-}
-
-static void
-kni_free_fifo_phy(struct rte_mempool *mp, struct rte_kni_fifo *fifo)
-{
-   void *mbuf_phys;
-   int ret;
-
-   do {
-   ret = kni_fifo_get(fifo, &mbuf_phys, 1);
-   if (ret)
-   rte_mempool_obj_iter(mp, obj_free, mbuf_phys);
-   } while (ret);
-}
-
 int
 rte_kni_release(struct rte_kni *kni)
 {
@@ -484,7 +460,7 @@ rte_kni_release(struct rte_kni *kni)
if (kni_fifo_count(kni->rx_q))
RTE_LOG(ERR, KNI, "Fail to free all Rx-q items\n");
 
-   kni_free_fifo_phy(kni->pktmbuf_pool, kni->alloc_q);
+   kni_free_fifo(kni->alloc_q);
kni_free_fifo(kni->tx_q);
kni_free_fifo(kni->free_q);
 
-- 
2.9.0.windows.1

[dpdk-dev] [PATCH] kni: optimize the kni release speed

[zhouyangchao]

Physical addresses in the fifo named alloc_q need to be traversed to
release in user space. The physical address to the virtual address
conversion in kernel space is much better.

Signed-off-by: Yangchao Zhou 
---
 lib/librte_eal/linuxapp/kni/kni_dev.h  |  1 +
 lib/librte_eal/linuxapp/kni/kni_misc.c |  1 +
 lib/librte_eal/linuxapp/kni/kni_net.c  | 15 +++
 lib/librte_kni/rte_kni.c   | 26 +-
 4 files changed, 18 insertions(+), 25 deletions(-)

diff --git a/lib/librte_eal/linuxapp/kni/kni_dev.h 
b/lib/librte_eal/linuxapp/kni/kni_dev.h
index c9393d8..7cd9bf8 100644
--- a/lib/librte_eal/linuxapp/kni/kni_dev.h
+++ b/lib/librte_eal/linuxapp/kni/kni_dev.h
@@ -92,6 +92,7 @@ struct kni_dev {
void *alloc_va[MBUF_BURST_SZ];
 };
 
+void kni_net_fifo_pa2va(struct kni_dev *kni);
 void kni_net_rx(struct kni_dev *kni);
 void kni_net_init(struct net_device *dev);
 void kni_net_config_lo_mode(char *lo_str);
diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c 
b/lib/librte_eal/linuxapp/kni/kni_misc.c
index 01574ec..668488b 100644
--- a/lib/librte_eal/linuxapp/kni/kni_misc.c
+++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
@@ -507,6 +507,7 @@ kni_ioctl_release(struct net *net, uint32_t ioctl_num,
dev->pthread = NULL;
}
 
+   kni_net_fifo_pa2va(dev);
kni_dev_remove(dev);
list_del(&dev->list);
ret = 0;
diff --git a/lib/librte_eal/linuxapp/kni/kni_net.c 
b/lib/librte_eal/linuxapp/kni/kni_net.c
index 9f9b798..662a527 100644
--- a/lib/librte_eal/linuxapp/kni/kni_net.c
+++ b/lib/librte_eal/linuxapp/kni/kni_net.c
@@ -73,6 +73,21 @@ va2pa(void *va, struct rte_kni_mbuf *m)
return pa;
 }
 
+/* convert physical addresses to virtual addresses in fifo for kni release */
+void
+kni_net_fifo_pa2va(struct kni_dev *kni)
+{
+   void *fifo = kni->alloc_q;
+   int i, count = kni_fifo_count(fifo);
+   void *pa = NULL, *kva, *va;
+   for (i = 0; i < count; ++i) {
+   (void)kni_fifo_get(fifo, &pa, 1);
+   kva = pa2kva(pa);
+   va = pa2va(pa, kva);
+   (void)kni_fifo_put(fifo, &va, 1);
+   }
+}
+
 /*
  * It can be called to process the request.
  */
diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
index 2867411..f8398a9 100644
--- a/lib/librte_kni/rte_kni.c
+++ b/lib/librte_kni/rte_kni.c
@@ -435,30 +435,6 @@ va2pa(struct rte_mbuf *m)
 (unsigned long)m->buf_iova));
 }
 
-static void
-obj_free(struct rte_mempool *mp __rte_unused, void *opaque, void *obj,
-   unsigned obj_idx __rte_unused)
-{
-   struct rte_mbuf *m = obj;
-   void *mbuf_phys = opaque;
-
-   if (va2pa(m) == mbuf_phys)
-   rte_pktmbuf_free(m);
-}
-
-static void
-kni_free_fifo_phy(struct rte_mempool *mp, struct rte_kni_fifo *fifo)
-{
-   void *mbuf_phys;
-   int ret;
-
-   do {
-   ret = kni_fifo_get(fifo, &mbuf_phys, 1);
-   if (ret)
-   rte_mempool_obj_iter(mp, obj_free, mbuf_phys);
-   } while (ret);
-}
-
 int
 rte_kni_release(struct rte_kni *kni)
 {
@@ -484,7 +460,7 @@ rte_kni_release(struct rte_kni *kni)
if (kni_fifo_count(kni->rx_q))
RTE_LOG(ERR, KNI, "Fail to free all Rx-q items\n");
 
-   kni_free_fifo_phy(kni->pktmbuf_pool, kni->alloc_q);
+   kni_free_fifo(kni->alloc_q);
kni_free_fifo(kni->tx_q);
kni_free_fifo(kni->free_q);
 
-- 
2.9.0.windows.1

Re: [dpdk-dev] [PATCH 3/7] cxgbe: add support to update RSS hash configuration and key

[Thomas Monjalon]

06/02/2018 11:11, Ferruh Yigit:
> On 2/6/2018 9:22 AM, Rahul Lakkireddy wrote:
> > On Monday, February 02/05/18, 2018 at 22:39:55 +0530, Ferruh Yigit wrote:
> >> I tend to get driver patches even after integration deadline, mainly 
> >> because of
> >> their limited scope.
> >> But since these are new features, submitted just before rc3, adding with
> >> questions in first patch, I am for postponing this patchset to next 
> >> release and
> >> do more review, what do you think?
> > 
> > Does dpdk-next-net tree work similar to linux "next" trees?  I mean does
> > it represent the next release (DPDK 18.05-rc1) merge window?  Can we
> > explicitly mention in Patch title which tree it is targeted for viz.
> > dpdk or dpdk-next-net?
> 
> Hi Rahul,
> 
> It is not like Linux next trees, this is more like Dave's net tree.
> In dpdk responsibilities split into sub-trees, and all target current release,
> patches merged into sub-trees and pulled by main tree in integration deadline.
> 
> All network drivers and ethdev abstraction layer patches goes into next-net
> sub-tree.
> 
> 
> Briefly overall process is [1]:
> - A new feature needs to be sent before proposal deadline, this can be a full
> version of the set or RFC. Proposal deadline for the release announced in
> https://dpdk.org/dev/roadmap
> 
> - After that point code reviews done and new versions sent till integration
> deadline. Accepted patches are integrated to release candidate 1 (rc1).
> Of course patch can be reviewed and merged without waiting integration 
> deadline.
> If a patch not get an approval and merge into tree in integration deadline,
> most probably it won't go into release.
> 
> - Fixes can be sent from beginning of release to rcX. Only latest rcX mostly 
> for
> the fixes on features introduced in that release.
> 
> - After rc1, code tested and fixes sent for found defects. No new feature
> expected after rc1.
> 
> - We go mostly to rc3 or rc4 before release.
> 
> 
> [1]
> Thomas, please correct me if I missed something. And this needs to be 
> documented
> indeed.

If the patchset targets 18.05, it should be notified.
I suggest --subject-prefix='PATCH 18.05'.
Then it will be marked as Deferred in patchwork until the start of
the 18.05 release cycle.
We can review it but we do not apply it before the start of the cycle,
because we don't see a real need for such "in advance" branch.

[dpdk-dev] Q: uio_generic_pci

[Ran Shalit]

Hello,

I would please like to ask about uio_generic_pci :

1. how to set irq from userspace.
Is there anything similar to
echo "3" > /sys/bus/pci/drivers/uio_pci_generic/irq
in all documentation which talk about it, it is not mentioned (or I
don't find it):
https://github.com/rumpkernel/wiki/wiki/Howto:-Accessing-PCI-devices-from-userspace
http://www.hep.by/gnu/kernel/uio-howto/uio_pci_generic.html

2. Is there a way to use dma from userspace with this driver ?

Best Regards,
Ran

Re: [dpdk-dev] [PATCH v2 3/4] net/mlx: version rdma-core glue libraries

[Adrien Mazarguil]

On Mon, Feb 05, 2018 at 03:06:19PM -0200, Marcelo Ricardo Leitner wrote:
> On Mon, Feb 05, 2018 at 04:54:55PM +0100, Adrien Mazarguil wrote:
> > On Mon, Feb 05, 2018 at 01:29:42PM -0200, Marcelo Ricardo Leitner wrote:
> > > On Mon, Feb 05, 2018 at 03:59:18PM +0100, Adrien Mazarguil wrote:
> > > > On Mon, Feb 05, 2018 at 12:37:34PM -0200, Marcelo Ricardo Leitner wrote:
> > > > > On Mon, Feb 05, 2018 at 03:16:21PM +0100, Thomas Monjalon wrote:
> > > > > > 05/02/2018 14:44, Adrien Mazarguil:
> ...
> > > > > > > Using a weak one like CRC32 for a shorter name poses a risk of
> > > > > > > collision. Moreover the next time someone decides to update all 
> > > > > > > version
> > > > > > > notices or modify a comment will impact that hash. We'd need to 
> > > > > > > isolate the
> > > > > > > symbol definition itself, ignore parameter names in function 
> > > > > > > prototypes and
> > > > > > > only then we may get a somewhat meaningful hash describing a 
> > > > > > > given ABI.
> > > > > 
> > > > > That's what I meant with stricter. Yes it would catch such
> > > > > situations, but you tell me on how much we want to protect/restrict
> > > > > here.  Do you see a reason for building only the dpdk/pmd side and not
> > > > > the glue library at a time?
> > > > 
> > > > No, they're always built together. We're only adding this versioning to
> > > > avoid issues when users somehow end up with several DPDK versions 
> > > > installed
> > > > on their system, or with leftovers of previous releases lying around. 
> > > > That's
> > > > all we need to solve here. dlopen()'ing the proper file takes care of 
> > > > that,
> > > > the symbol version number check afterward is performed just in case.
> > > 
> > > Interesting. These leftovers probably wouldn't be there if it wasn't
> > > versioned in the first place. :-)
> > 
> > Seriously, we can't assume users will do everything using neat packages and
> > may run an unfortunate "make install" from the DPDK source tree without
> > noticing they wrecked their system. Someone will have to mop the ensuing but
> > preventable bug reports.
> > 
> > > > > > > Given the added complexity, is there really a problem with simple 
> > > > > > > version
> > > > > > > numbers we increment every time something gets modified? (Note 
> > > > > > > this is
> > > > > > > already how our .map files work, they're not generated 
> > > > > > > automatically)
> > > > > > 
> > > > > > Our map files show the major version where a symbol was introduced.
> > > > > > It is simple because no symbol can be introduced in a minor version.
> > > > > > 
> > > > > > > How about keeping things as is?
> > > > > 
> > > > > I don't really see the need of unique filenames. The next patch is
> > > > > already leveraging RTE_EAL_PMD_PATH, which if versioned should be
> > > > > enough for this, no?
> > > > 
> > > > As you said, "if" versioned. As an undocumented empty string by default,
> > > > there's no way to be sure. Leaving the PMD version its internal but
> > > > (unfortunately) exposed bits will certainly prevent mistakes.
> > > > 
> > > > > > You are using 18.02.1 while it is introduced in 18.02.0.
> > > > > > If you don't want to correlate the .so version number with DPDK 
> > > > > > version
> > > > > > number, maybe that 1, 2, 3 would be a simpler choice (less 
> > > > > > confusing).
> > > > > 
> > > > > +1
> > > > 
> > > > Then are you fine with the "18.02.0" suffix?
> > > 
> > > Not really, sorry. It was more for the "1, 2, 3" sequence or tying it
> > > to dpdk version.
> > > 
> > > With the latest replies, I don't think the reasoning is enough to
> > > justify these extra checks, but I won't oppose to including it.
> > 
> > 18.02.0 makes it tied to the current release number, so I guess we agree.
> 
> It makes them equal, but not tied. If nobody patches it, when 18.02.1
> is out, the glue lib will still be 18.02.0.

Well this must be understood as "this plug-in implements 18.02.0's mlx4 glue
ABI", which remains true (and compatible) with subsequent DPDK releases as
long as the glue code is not updated.

Note this is no different from a single-digit suffix, which wouldn't be
updated either if the ABI isn't. Again, these initial digits are needed
because otherwise there is already a confusion with stable branches that
implement different ABIs and are therefore incompatible:

 librte_pmd_mlx4_glue.so.17.02.1
 librte_pmd_mlx4_glue.so.17.11.1
 librte_pmd_mlx4_glue.so.18.02.0

With a single digit, all of them would be named "librte_pmd_mlx4_glue.so.1",
rendering versioning basically useless.

> > The idea for now is this part remains tied to the DPDK release.
> > 
> > If a new ABI version is needed in a subsequent commit, the initial part gets
> > bumped to the current WIP DPDK release (say, 42.02.0). If subsequent
> > intermediate commits break the glue ABI, a fourth digit is added
> > (e.g. 42.02.0.1).
> 
> I'll defer this to other project developers. This is more about a
> project standard than anything 

Re: [dpdk-dev] [PATCH v3] net/bnxt: Fix to set timestamp flag

[Ferruh Yigit]

On 2/6/2018 2:52 AM, Somnath Kotur wrote:
> The timestamp flag needs to be set in the offload flags
> for the received pkt in case of PTP offload.
> 
> Fixes: b11cceb83a34 ("net/bnxt: support timesync")
> Cc: somnath.ko...@broadcom.com
> 
> Signed-off-by: Somnath Kotur 

Applied to dpdk-next-net/master, thanks.

[dpdk-dev] [PATCH] net/bnx2x: reserve enough headroom for mbuf prepend

[zhouyangchao]

Signed-off-by: Yangchao Zhou 
---
 drivers/net/bnx2x/bnx2x_rxtx.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x_rxtx.c b/drivers/net/bnx2x/bnx2x_rxtx.c
index a0d4ac9..d8a3225 100644
--- a/drivers/net/bnx2x/bnx2x_rxtx.c
+++ b/drivers/net/bnx2x/bnx2x_rxtx.c
@@ -140,7 +140,8 @@ bnx2x_dev_rx_queue_setup(struct rte_eth_dev *dev,
return -ENOMEM;
}
rxq->sw_ring[idx] = mbuf;
-   rxq->rx_ring[idx] = mbuf->buf_iova;
+   rxq->rx_ring[idx] = 
+   rte_cpu_to_le_64(rte_mbuf_data_iova_default(mbuf));
}
rxq->pkt_first_seg = NULL;
rxq->pkt_last_seg = NULL;
@@ -400,7 +401,8 @@ bnx2x_recv_pkts(void *p_rxq, struct rte_mbuf **rx_pkts, 
uint16_t nb_pkts)
 
rx_mb = rxq->sw_ring[bd_cons];
rxq->sw_ring[bd_cons] = new_mb;
-   rxq->rx_ring[bd_prod] = new_mb->buf_iova;
+   rxq->rx_ring[bd_prod] = 
+   rte_cpu_to_le_64(rte_mbuf_data_iova_default(new_mb));
 
rx_pref = NEXT_RX_BD(bd_cons) & MAX_RX_BD(rxq);
rte_prefetch0(rxq->sw_ring[rx_pref]);
@@ -409,7 +411,7 @@ bnx2x_recv_pkts(void *p_rxq, struct rte_mbuf **rx_pkts, 
uint16_t nb_pkts)
rte_prefetch0(&rxq->sw_ring[rx_pref]);
}
 
-   rx_mb->data_off = pad;
+   rx_mb->data_off = pad + RTE_PKTMBUF_HEADROOM;
rx_mb->nb_segs = 1;
rx_mb->next = NULL;
rx_mb->pkt_len = rx_mb->data_len = len;
-- 
2.9.0.windows.1

[dpdk-dev] [PATCH] net/bnx2x: reserve enough headroom for mbuf prepend

[zhouyangchao]

Signed-off-by: Yangchao Zhou 
---
 drivers/net/bnx2x/bnx2x_rxtx.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x_rxtx.c b/drivers/net/bnx2x/bnx2x_rxtx.c
index a0d4ac9..d8a3225 100644
--- a/drivers/net/bnx2x/bnx2x_rxtx.c
+++ b/drivers/net/bnx2x/bnx2x_rxtx.c
@@ -140,7 +140,8 @@ bnx2x_dev_rx_queue_setup(struct rte_eth_dev *dev,
return -ENOMEM;
}
rxq->sw_ring[idx] = mbuf;
-   rxq->rx_ring[idx] = mbuf->buf_iova;
+   rxq->rx_ring[idx] = 
+   rte_cpu_to_le_64(rte_mbuf_data_iova_default(mbuf));
}
rxq->pkt_first_seg = NULL;
rxq->pkt_last_seg = NULL;
@@ -400,7 +401,8 @@ bnx2x_recv_pkts(void *p_rxq, struct rte_mbuf **rx_pkts, 
uint16_t nb_pkts)
 
rx_mb = rxq->sw_ring[bd_cons];
rxq->sw_ring[bd_cons] = new_mb;
-   rxq->rx_ring[bd_prod] = new_mb->buf_iova;
+   rxq->rx_ring[bd_prod] = 
+   rte_cpu_to_le_64(rte_mbuf_data_iova_default(new_mb));
 
rx_pref = NEXT_RX_BD(bd_cons) & MAX_RX_BD(rxq);
rte_prefetch0(rxq->sw_ring[rx_pref]);
@@ -409,7 +411,7 @@ bnx2x_recv_pkts(void *p_rxq, struct rte_mbuf **rx_pkts, 
uint16_t nb_pkts)
rte_prefetch0(&rxq->sw_ring[rx_pref]);
}
 
-   rx_mb->data_off = pad;
+   rx_mb->data_off = pad + RTE_PKTMBUF_HEADROOM;
rx_mb->nb_segs = 1;
rx_mb->next = NULL;
rx_mb->pkt_len = rx_mb->data_len = len;
-- 
2.9.0.windows.1

[dpdk-dev] [PATCH] net/bnx2x: reserve enough headroom for mbuf prepend

[zhouyangchao]

Signed-off-by: Yangchao Zhou 
---
 drivers/net/bnx2x/bnx2x_rxtx.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x_rxtx.c b/drivers/net/bnx2x/bnx2x_rxtx.c
index a0d4ac9..d8a3225 100644
--- a/drivers/net/bnx2x/bnx2x_rxtx.c
+++ b/drivers/net/bnx2x/bnx2x_rxtx.c
@@ -140,7 +140,8 @@ bnx2x_dev_rx_queue_setup(struct rte_eth_dev *dev,
return -ENOMEM;
}
rxq->sw_ring[idx] = mbuf;
-   rxq->rx_ring[idx] = mbuf->buf_iova;
+   rxq->rx_ring[idx] = 
+   rte_cpu_to_le_64(rte_mbuf_data_iova_default(mbuf));
}
rxq->pkt_first_seg = NULL;
rxq->pkt_last_seg = NULL;
@@ -400,7 +401,8 @@ bnx2x_recv_pkts(void *p_rxq, struct rte_mbuf **rx_pkts, 
uint16_t nb_pkts)
 
rx_mb = rxq->sw_ring[bd_cons];
rxq->sw_ring[bd_cons] = new_mb;
-   rxq->rx_ring[bd_prod] = new_mb->buf_iova;
+   rxq->rx_ring[bd_prod] = 
+   rte_cpu_to_le_64(rte_mbuf_data_iova_default(new_mb));
 
rx_pref = NEXT_RX_BD(bd_cons) & MAX_RX_BD(rxq);
rte_prefetch0(rxq->sw_ring[rx_pref]);
@@ -409,7 +411,7 @@ bnx2x_recv_pkts(void *p_rxq, struct rte_mbuf **rx_pkts, 
uint16_t nb_pkts)
rte_prefetch0(&rxq->sw_ring[rx_pref]);
}
 
-   rx_mb->data_off = pad;
+   rx_mb->data_off = pad + RTE_PKTMBUF_HEADROOM;
rx_mb->nb_segs = 1;
rx_mb->next = NULL;
rx_mb->pkt_len = rx_mb->data_len = len;
-- 
2.9.0.windows.1

[dpdk-dev] [PATCH] net/bnx2x: reserve enough headroom for mbuf prepend

[zhouyangchao]

Signed-off-by: Yangchao Zhou 
---
 drivers/net/bnx2x/bnx2x_rxtx.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x_rxtx.c b/drivers/net/bnx2x/bnx2x_rxtx.c
index a0d4ac9..d8a3225 100644
--- a/drivers/net/bnx2x/bnx2x_rxtx.c
+++ b/drivers/net/bnx2x/bnx2x_rxtx.c
@@ -140,7 +140,8 @@ bnx2x_dev_rx_queue_setup(struct rte_eth_dev *dev,
return -ENOMEM;
}
rxq->sw_ring[idx] = mbuf;
-   rxq->rx_ring[idx] = mbuf->buf_iova;
+   rxq->rx_ring[idx] = 
+   rte_cpu_to_le_64(rte_mbuf_data_iova_default(mbuf));
}
rxq->pkt_first_seg = NULL;
rxq->pkt_last_seg = NULL;
@@ -400,7 +401,8 @@ bnx2x_recv_pkts(void *p_rxq, struct rte_mbuf **rx_pkts, 
uint16_t nb_pkts)
 
rx_mb = rxq->sw_ring[bd_cons];
rxq->sw_ring[bd_cons] = new_mb;
-   rxq->rx_ring[bd_prod] = new_mb->buf_iova;
+   rxq->rx_ring[bd_prod] = 
+   rte_cpu_to_le_64(rte_mbuf_data_iova_default(new_mb));
 
rx_pref = NEXT_RX_BD(bd_cons) & MAX_RX_BD(rxq);
rte_prefetch0(rxq->sw_ring[rx_pref]);
@@ -409,7 +411,7 @@ bnx2x_recv_pkts(void *p_rxq, struct rte_mbuf **rx_pkts, 
uint16_t nb_pkts)
rte_prefetch0(&rxq->sw_ring[rx_pref]);
}
 
-   rx_mb->data_off = pad;
+   rx_mb->data_off = pad + RTE_PKTMBUF_HEADROOM;
rx_mb->nb_segs = 1;
rx_mb->next = NULL;
rx_mb->pkt_len = rx_mb->data_len = len;
-- 
2.9.0.windows.1

[dpdk-dev] [PATCH] net/bnx2x: reserve enough headroom for mbuf prepend

[zhouyangchao]

Signed-off-by: Yangchao Zhou 
---
 drivers/net/bnx2x/bnx2x_rxtx.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x_rxtx.c b/drivers/net/bnx2x/bnx2x_rxtx.c
index a0d4ac9..d8a3225 100644
--- a/drivers/net/bnx2x/bnx2x_rxtx.c
+++ b/drivers/net/bnx2x/bnx2x_rxtx.c
@@ -140,7 +140,8 @@ bnx2x_dev_rx_queue_setup(struct rte_eth_dev *dev,
return -ENOMEM;
}
rxq->sw_ring[idx] = mbuf;
-   rxq->rx_ring[idx] = mbuf->buf_iova;
+   rxq->rx_ring[idx] = 
+   rte_cpu_to_le_64(rte_mbuf_data_iova_default(mbuf));
}
rxq->pkt_first_seg = NULL;
rxq->pkt_last_seg = NULL;
@@ -400,7 +401,8 @@ bnx2x_recv_pkts(void *p_rxq, struct rte_mbuf **rx_pkts, 
uint16_t nb_pkts)
 
rx_mb = rxq->sw_ring[bd_cons];
rxq->sw_ring[bd_cons] = new_mb;
-   rxq->rx_ring[bd_prod] = new_mb->buf_iova;
+   rxq->rx_ring[bd_prod] = 
+   rte_cpu_to_le_64(rte_mbuf_data_iova_default(new_mb));
 
rx_pref = NEXT_RX_BD(bd_cons) & MAX_RX_BD(rxq);
rte_prefetch0(rxq->sw_ring[rx_pref]);
@@ -409,7 +411,7 @@ bnx2x_recv_pkts(void *p_rxq, struct rte_mbuf **rx_pkts, 
uint16_t nb_pkts)
rte_prefetch0(&rxq->sw_ring[rx_pref]);
}
 
-   rx_mb->data_off = pad;
+   rx_mb->data_off = pad + RTE_PKTMBUF_HEADROOM;
rx_mb->nb_segs = 1;
rx_mb->next = NULL;
rx_mb->pkt_len = rx_mb->data_len = len;
-- 
2.9.0.windows.1

[dpdk-dev] [PATCH] net/bnx2x: reserve enough headroom for mbuf prepend

[zhouyangchao]

Signed-off-by: Yangchao Zhou 
---
 drivers/net/bnx2x/bnx2x_rxtx.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x_rxtx.c b/drivers/net/bnx2x/bnx2x_rxtx.c
index a0d4ac9..d8a3225 100644
--- a/drivers/net/bnx2x/bnx2x_rxtx.c
+++ b/drivers/net/bnx2x/bnx2x_rxtx.c
@@ -140,7 +140,8 @@ bnx2x_dev_rx_queue_setup(struct rte_eth_dev *dev,
return -ENOMEM;
}
rxq->sw_ring[idx] = mbuf;
-   rxq->rx_ring[idx] = mbuf->buf_iova;
+   rxq->rx_ring[idx] = 
+   rte_cpu_to_le_64(rte_mbuf_data_iova_default(mbuf));
}
rxq->pkt_first_seg = NULL;
rxq->pkt_last_seg = NULL;
@@ -400,7 +401,8 @@ bnx2x_recv_pkts(void *p_rxq, struct rte_mbuf **rx_pkts, 
uint16_t nb_pkts)
 
rx_mb = rxq->sw_ring[bd_cons];
rxq->sw_ring[bd_cons] = new_mb;
-   rxq->rx_ring[bd_prod] = new_mb->buf_iova;
+   rxq->rx_ring[bd_prod] = 
+   rte_cpu_to_le_64(rte_mbuf_data_iova_default(new_mb));
 
rx_pref = NEXT_RX_BD(bd_cons) & MAX_RX_BD(rxq);
rte_prefetch0(rxq->sw_ring[rx_pref]);
@@ -409,7 +411,7 @@ bnx2x_recv_pkts(void *p_rxq, struct rte_mbuf **rx_pkts, 
uint16_t nb_pkts)
rte_prefetch0(&rxq->sw_ring[rx_pref]);
}
 
-   rx_mb->data_off = pad;
+   rx_mb->data_off = pad + RTE_PKTMBUF_HEADROOM;
rx_mb->nb_segs = 1;
rx_mb->next = NULL;
rx_mb->pkt_len = rx_mb->data_len = len;
-- 
2.9.0.windows.1

Re: [dpdk-dev] [PATCH v2 0/4] net/mlx: enhance rdma-core glue configuration

[Shahaf Shuler]

Friday, February 2, 2018 6:46 PM, Adrien Mazarguil:
> The decision to deliver mlx4/mlx5 rdma-core glue plug-ins separately instead
> of generating them at run time due to security concerns [1] led to a few
> issues:
> 
> - They must be present on the file system before running DPDK.
> - Their location must be known to the dynamic linker.
> - Their names overlap and ABI compatibility is not guaranteed, which may
>   lead to crashes.
> 
> This series addresses the above by adding version information to plug-ins
> and taking CONFIG_RTE_EAL_PMD_PATH into account to locate them on the
> file system.

Series applied to next-net-mlx, with the following diff in patch 3/4:
diff --git a/drivers/net/mlx4/Makefile b/drivers/net/mlx4/Makefile
index cc9db9977..cc800493b 100644 
--- a/drivers/net/mlx4/Makefile   
+++ b/drivers/net/mlx4/Makefile   
@@ -35,7 +35,7 @@ include $(RTE_SDK)/mk/rte.vars.mk   
 LIB = librte_pmd_mlx4.a  
 LIB_GLUE = $(LIB_GLUE_BASE).$(LIB_GLUE_VERSION)  
 LIB_GLUE_BASE = librte_pmd_mlx4_glue.so  
-LIB_GLUE_VERSION = 18.02.1   
+LIB_GLUE_VERSION = 18.02.0   
  
 # Sources.   
 SRCS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4.c 
diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile
index 4086f2039..3bc9736c9 100644 
--- a/drivers/net/mlx5/Makefile   
+++ b/drivers/net/mlx5/Makefile   
@@ -35,7 +35,7 @@ include $(RTE_SDK)/mk/rte.vars.mk   
 LIB = librte_pmd_mlx5.a  
 LIB_GLUE = $(LIB_GLUE_BASE).$(LIB_GLUE_VERSION)  
 LIB_GLUE_BASE = librte_pmd_mlx5_glue.so  
-LIB_GLUE_VERSION = 18.02.1   
+LIB_GLUE_VERSION = 18.02.0 

Thanks. 


> 
> [1]
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdpd
> k.org%2Fml%2Farchives%2Fdev%2F2018-
> January%2F089617.html&data=02%7C01%7Cshahafs%40mellanox.com%7C6d
> 6d87b37a574c15f41808d56a5c7eae%7Ca652971c7d2e4d9ba6a4d149256f461b
> %7C0%7C0%7C636531867854846685&sdata=9Bc7lEnU%2Fq4E5PxgOkEvgwDN
> zc46%2BZ1B5boHyxg1Cuo%3D&reserved=0
> 
> v2 changes:
> 
> - Fixed extra "\n" in glue file name generation (although it didn't break
>   functionality).
> 
> Adrien Mazarguil (4):
>   net/mlx: add debug checks to glue structure
>   net/mlx: fix missing includes for rdma-core glue
>   net/mlx: version rdma-core glue libraries
>   net/mlx: make rdma-core glue path configurable
> 
>  doc/guides/nics/mlx4.rst | 17 
>  doc/guides/nics/mlx5.rst | 14 ++
>  drivers/net/mlx4/Makefile|  8 --
>  drivers/net/mlx4/mlx4.c  | 57
> ++-
>  drivers/net/mlx4/mlx4_glue.c |  4 +++
>  drivers/net/mlx4/mlx4_glue.h |  9 +++
>  drivers/net/mlx5/Makefile|  8 --
>  drivers/net/mlx5/mlx5.c  | 57
> ++-
>  drivers/net/mlx5/mlx5_glue.c |  1 +
>  drivers/net/mlx5/mlx5_glue.h |  7 +
>  10 files changed, 176 insertions(+), 6 deletions(-)
> 
> --
> 2.11.0

Re: [dpdk-dev] [PATCH] net/mlx5: fix flow RSS configuration

[Shahaf Shuler]

Tuesday, February 6, 2018 11:22 AM, Nelio Laranjeiro:
> An RSS configuration without a key is valid according to the rte_eth_rss_conf
> API definition.
> 
> Fixes: 8086cf08b2f0 ("net/mlx5: handle RSS hash configuration in RSS flow")
> 
> Cc: sta...@dpdk.org
> Reported-by: Yuanhan Liu 
> Signed-off-by: Nelio Laranjeiro 
> ---
>  drivers/net/mlx5/mlx5_flow.c | 29 +
>  1 file changed, 17 insertions(+), 12 deletions(-)

Applied to next-net-mlx, thanks.

Re: [dpdk-dev] [PATCH] net/mlx5: fix UAR remapping on non configured queues

[Shahaf Shuler]

Tuesday, February 6, 2018 11:26 AM, Nelio Laranjeiro:
> priv_tx_uar_remap() is wrongly considering the queue is already configured
> and thus present in the queue array of the device.
> 
> Fixes: f8b9a3bad467 ("net/mlx5: install a socket to exchange a file
> descriptor")
> Cc: xuemi...@mellanox.com
> 
> Cc: sta...@dpdk.org
> Signed-off-by: Nelio Laranjeiro 
> ---

Applied to next-net-mlx, thanks. 

Re: [dpdk-dev] [PATCH v2] doc: update application minimum requirement info

[Mcnamara, John]

> -Original Message-
> From: Varghese, Vipin
> Sent: Monday, February 5, 2018 5:32 PM
> To: dev@dpdk.org; Kovacevic, Marko ; De Lara
> Guarch, Pablo 
> Cc: Mcnamara, John ; Varghese, Vipin
> 
> Subject: [PATCH v2] doc: update application minimum requirement info
> 
> Added note section to update information for use cases working with
> multiple crypto devices.
> 


Acked-by: John McNamara 

Re: [dpdk-dev] [PATCH] doc: update info on multi crypto instances

[Mcnamara, John]

> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Monday, February 5, 2018 3:58 PM
> To: Varghese, Vipin ; dev@dpdk.org; Kovacevic,
> Marko 
> Cc: Mcnamara, John ; Varghese, Vipin
> 
> Subject: RE: [dpdk-dev] [PATCH] doc: update info on multi crypto instances
> 
> 
> 
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Vipin Varghese
> > Sent: Monday, February 5, 2018 2:36 PM
> > To: dev@dpdk.org; Kovacevic, Marko 
> > Cc: Mcnamara, John ; Varghese, Vipin
> > 
> > Subject: [dpdk-dev] [PATCH] doc: update info on multi crypto instances
> >
> > Added note section to update information for use cases working with
> > multiple crypto devices.
> 
> I would change the title to something more generic, since you are adding
> other info and not just the multi crypto device issue.
> 
> >
> > Signed-off-by: Vipin Varghese 
> > ---
> >  doc/guides/sample_app_ug/l2_forward_crypto.rst | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/doc/guides/sample_app_ug/l2_forward_crypto.rst
> > b/doc/guides/sample_app_ug/l2_forward_crypto.rst
> > index 1e85b4a..c2e6128 100644
> > --- a/doc/guides/sample_app_ug/l2_forward_crypto.rst
> > +++ b/doc/guides/sample_app_ug/l2_forward_crypto.rst
> > @@ -199,6 +199,14 @@ To run the application in linuxapp environment
> > with 2 lcores, 2 ports and 2 cryp  Refer to the *DPDK Getting Started
> > Guide* for general information on running applications  and the
> > Environment Abstraction Layer (EAL) options.
> >
> > +.. Note::
> > +
> > +* The ``l2fwd-crypto`` sample application requires IPv4 packets
> > + for
> > crypto operation.
> > +
> > +* If multiple Ethernet ports is passed, then equal number of
> > +  crypto devices are to be passed.

Probably better as:

   If multiple Ethernet ports are passed then an equal number of
   crypto devices must be passed.

Re: [dpdk-dev] [PATCH] doc: update the usage for shared library

[Mcnamara, John]

> -Original Message-
> From: Varghese, Vipin
> Sent: Monday, February 5, 2018 2:17 PM
> To: dev@dpdk.org; Kovacevic, Marko 
> Cc: Mcnamara, John ; Varghese, Vipin
> 
> Subject: [PATCH] doc: update the usage for shared library
> 
> Add note information to intimate about use of option '-d' for shared
> ...
> +
> +   .. note::
> +
> +   When dpdk-testpmd is built with shared library, use option ``-d`` to
> +   load the dynamic PMD for ``rte_eal_init``.

I think the text of the note needs to be indented at least 3 spaces.

Also, the app name is testpmd, not dpdk-testpmd, right? That is what is in
the previous section of the doc.

Also, quote the application name like this: ``testpmd``.


John

Re: [dpdk-dev] [PATCH v3] doc: update definition of lcore id and lcore index

[Mcnamara, John]

> -Original Message-
> From: Kovacevic, Marko
> Sent: Friday, February 2, 2018 3:03 PM
> To: dev@dpdk.org
> Cc: Mcnamara, John ; Varghese, Vipin
> ; Richardson, Bruce
> ; sta...@dpdk.org; Kovacevic, Marko
> 
> Subject: [PATCH v3] doc: update definition of lcore id and lcore index
> 
> Added examples in lcore index for better explanation on various examples,
> Sited examples for lcore id.

Acked-by: John McNamara 

Re: [dpdk-dev] [PATCH v2 4/4] doc/power: add information on per-core turbo APIs

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of David Hunt
> Sent: Wednesday, September 13, 2017 11:44 AM
> To: dev@dpdk.org
> Cc: Hunt, David 
> Subject: [dpdk-dev] [PATCH v2 4/4] doc/power: add information on per-core
> turbo APIs
> 
> Signed-off-by: David Hunt 

Acked-by: John McNamara 

[dpdk-dev] [PATCH] net/mlx5: dump flow create error message

[Xueming Li]

Add error message dump when flow create error happened.

Signed-off-by: Xueming Li 
---
 drivers/net/mlx5/mlx5_flow.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index e38452ef3..ea90556d0 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -1890,6 +1890,7 @@ priv_flow_create(struct priv *priv,
DEBUG("Flow created %p", (void *)flow);
return flow;
 exit:
+   ERROR("Flow create error: %s", error->message);
for (i = 0; i != hash_rxq_init_n; ++i) {
if (parser.queue[i].ibv_attr)
rte_free(parser.queue[i].ibv_attr);
-- 
2.13.3

[dpdk-dev] [PATCH] net/mlx5: fix socket assertion error during dev close

[Xueming Li]

This patch fixed primary socket assertion error during close on a device
that failed to start.

Fixes: f8b9a3bad467 ("net/mlx5: install a socket to exchange a file descriptor")
Signed-off-by: Xueming Li 
---
 drivers/net/mlx5/mlx5.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index b66303d29..fb4463c2b 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -201,7 +201,8 @@ mlx5_dev_close(struct rte_eth_dev *dev)
rte_free(priv->rss_conf.rss_key);
if (priv->reta_idx != NULL)
rte_free(priv->reta_idx);
-   priv_socket_uninit(priv);
+   if (priv->primary_socket)
+   priv_socket_uninit(priv);
ret = mlx5_priv_hrxq_ibv_verify(priv);
if (ret)
WARN("%p: some Hash Rx queue still remain", (void *)priv);
-- 
2.13.3

Re: [dpdk-dev] [PATCH] net/mlx5: dump flow create error message

[Nélio Laranjeiro]

On Tue, Feb 06, 2018 at 08:52:53PM +0800, Xueming Li wrote:
> Add error message dump when flow create error happened.
> 
> Signed-off-by: Xueming Li 
> ---
>  drivers/net/mlx5/mlx5_flow.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
> index e38452ef3..ea90556d0 100644
> --- a/drivers/net/mlx5/mlx5_flow.c
> +++ b/drivers/net/mlx5/mlx5_flow.c
> @@ -1890,6 +1890,7 @@ priv_flow_create(struct priv *priv,
>   DEBUG("Flow created %p", (void *)flow);
>   return flow;
>  exit:
> + ERROR("Flow create error: %s", error->message);
>   for (i = 0; i != hash_rxq_init_n; ++i) {
>   if (parser.queue[i].ibv_attr)
>   rte_free(parser.queue[i].ibv_attr);
> -- 
> 2.13.3
 
Hi Xueming,

Can you move this debug message to mlx5_flow_create().

Thanks,

-- 
Nélio Laranjeiro
6WIND

Re: [dpdk-dev] [PATCH] net/mlx5: fix socket assertion error during dev close

[Nélio Laranjeiro]

On Tue, Feb 06, 2018 at 08:54:22PM +0800, Xueming Li wrote:
> This patch fixed primary socket assertion error during close on a device
> that failed to start.
> 
> Fixes: f8b9a3bad467 ("net/mlx5: install a socket to exchange a file 
> descriptor")
> Signed-off-by: Xueming Li 
> ---
>  drivers/net/mlx5/mlx5.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
> index b66303d29..fb4463c2b 100644
> --- a/drivers/net/mlx5/mlx5.c
> +++ b/drivers/net/mlx5/mlx5.c
> @@ -201,7 +201,8 @@ mlx5_dev_close(struct rte_eth_dev *dev)
>   rte_free(priv->rss_conf.rss_key);
>   if (priv->reta_idx != NULL)
>   rte_free(priv->reta_idx);
> - priv_socket_uninit(priv);
> + if (priv->primary_socket)
> + priv_socket_uninit(priv);
>   ret = mlx5_priv_hrxq_ibv_verify(priv);
>   if (ret)
>   WARN("%p: some Hash Rx queue still remain", (void *)priv);
> -- 
> 2.13.3
 
Acked-by: Nelio Laranjeiro 

-- 
Nélio Laranjeiro
6WIND

Re: [dpdk-dev] [PATCH 1/8] vhost: add security model documentation to vhost_user.c

[Kovacevic, Marko]

> Input validation is not applied consistently in vhost_user.c.  This suggests 
> that
> not everyone has the same security model in mind when working on the
> code.
> 
> Make the security model explicit so that everyone can understand and follow
> the same model when modifying the code.
> 
> Signed-off-by: Stefan Hajnoczi 
> ---
>  lib/librte_vhost/vhost_user.c | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c

<...>

This is a useful comment but I don't know if it makes sense to include it in 
the vhost_user.c file. 

Particularly at the top where it looks like a general descriptive comment for 
the file.

It would probably be better in the vhost-user section of the programmer's guide:

http://dpdk.org/doc/guides/prog_guide/vhost_lib.html

Also, the subject line shouldn't include an underscore.

Marko

Re: [dpdk-dev] [PATCH] doc: add info on hyperthreading to power library

[Kovacevic, Marko]

> Signed-off-by: David Hunt 
> ---
>  doc/guides/prog_guide/power_man.rst | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/doc/guides/prog_guide/power_man.rst
> b/doc/guides/prog_guide/power_man.rst

<...>

Acked-by: Marko Kovacevic 

[dpdk-dev] [Bug 15] Kernel crash after "Detected Tx Unit Hang" report

[bugzilla]

https://dpdk.org/tracker/show_bug.cgi?id=15

Bug ID: 15
   Summary: Kernel crash after "Detected Tx Unit Hang" report
   Product: DPDK
   Version: 17.11
  Hardware: x86
OS: Linux
Status: CONFIRMED
  Severity: critical
  Priority: Normal
 Component: core
  Assignee: dev@dpdk.org
  Reporter: batmanu...@gmail.com
  Target Milestone: ---

How to produce: same step as bug(https://dpdk.org/tracker/show_bug.cgi?id=14)

kernel log:
Feb 06 19:01:40 yf-mos-test-net20 kernel: Detected Tx Unit Hang
Tx Queue <0>
TDH, TDT <0>, <6>
next_to_use  <6>
next_to_clean<0>
  tx_buffer_info[next_to_clean]
next_to_watch  

eop_desc->wb.status  <128280>
time_stamp   <13079e940>
jiffies  <13079ee06>
Feb 06 19:01:40 yf-mos-test-net20 ovs-vswitchdm[13237]: PMD: VF 0: disabling
multicast promiscuous

-- 
You are receiving this mail because:
You are the assignee for the bug.

[dpdk-dev] [PATCH v2] bbdev: fix exported dynamic log type

[Amr Mokhtar]

This patch fixes shared library compilation due to undefined
reference to an exported variable 'bbdev_logtype'.

v2:
* In this fix,
* - The logtype has become static and owned individually by each
*component.
* - Helper logging macros are removed from bbdev lib header files
*and replaced with macros defined by each driver at its ease.
* - 'bbdev_logtype' removed from .map

v1:
* This patch fixes shared library compilation due to undefined
* reference to an exported variable 'bbdev_logtype'.
* In this fix, the logtype is converted to static in the bbdev lib,
* in bbdev null pmd and turbo sw pmd.


Fixes: 4935e1e9f76e ("bbdev: introduce wireless base band device lib")
Fixes: b8cfe2c9aed2 ("bb/turbo_sw: add software turbo driver")
Fixes: 7dc2b1589440 ("bb/null: add null base band device driver")
Cc: tho...@monjalon.net

Signed-off-by: Amr Mokhtar 
---
 drivers/bbdev/null/bbdev_null.c   | 18 +--
 drivers/bbdev/turbo_sw/bbdev_turbo_software.c | 19 ++--
 lib/librte_bbdev/rte_bbdev.c  | 14 --
 lib/librte_bbdev/rte_bbdev.h  | 28 ++-
 lib/librte_bbdev/rte_bbdev_op.h   | 68 +--
 lib/librte_bbdev/rte_bbdev_version.map|  1 -
 6 files changed, 46 insertions(+), 102 deletions(-)

diff --git a/drivers/bbdev/null/bbdev_null.c b/drivers/bbdev/null/bbdev_null.c
index 1a66de1..6bc8491 100644
--- a/drivers/bbdev/null/bbdev_null.c
+++ b/drivers/bbdev/null/bbdev_null.c
@@ -15,6 +15,17 @@
 
 #define DRIVER_NAME bbdev_null
 
+/* NULL BBDev logging ID */
+static int bbdev_null_logtype;
+
+/* Helper macro for logging */
+#define rte_bbdev_log(level, fmt, ...) \
+   rte_log(RTE_LOG_ ## level, bbdev_null_logtype, fmt "\n", ##__VA_ARGS__)
+
+#define rte_bbdev_log_debug(fmt, ...) \
+   rte_bbdev_log(DEBUG, RTE_STR(__LINE__) ":%s() " fmt, __func__, \
+   ##__VA_ARGS__)
+
 /*  Initialisation params structure that can be used by null BBDEV driver */
 struct bbdev_null_params {
int socket_id;  /*< Null BBDEV socket */
@@ -335,12 +346,11 @@ RTE_PMD_REGISTER_PARAM_STRING(DRIVER_NAME,
BBDEV_NULL_MAX_NB_QUEUES_ARG"= "
BBDEV_NULL_SOCKET_ID_ARG"=");
 
-int bbdev_logtype;
 RTE_INIT(null_bbdev_init_log);
 static void
 null_bbdev_init_log(void)
 {
-   bbdev_logtype = rte_log_register("pmd.bb.null");
-   if (bbdev_logtype >= 0)
-   rte_log_set_level(bbdev_logtype, RTE_LOG_NOTICE);
+   bbdev_null_logtype = rte_log_register("pmd.bb.null");
+   if (bbdev_null_logtype >= 0)
+   rte_log_set_level(bbdev_null_logtype, RTE_LOG_NOTICE);
 }
diff --git a/drivers/bbdev/turbo_sw/bbdev_turbo_software.c 
b/drivers/bbdev/turbo_sw/bbdev_turbo_software.c
index 33f7135..302abf5 100644
--- a/drivers/bbdev/turbo_sw/bbdev_turbo_software.c
+++ b/drivers/bbdev/turbo_sw/bbdev_turbo_software.c
@@ -20,6 +20,18 @@
 
 #define DRIVER_NAME turbo_sw
 
+/* Turbo SW PMD logging ID */
+static int bbdev_turbo_sw_logtype;
+
+/* Helper macro for logging */
+#define rte_bbdev_log(level, fmt, ...) \
+   rte_log(RTE_LOG_ ## level, bbdev_turbo_sw_logtype, fmt "\n", \
+   ##__VA_ARGS__)
+
+#define rte_bbdev_log_debug(fmt, ...) \
+   rte_bbdev_log(DEBUG, RTE_STR(__LINE__) ":%s() " fmt, __func__, \
+   ##__VA_ARGS__)
+
 /* Number of columns in sub-block interleaver (36.212, section 5.1.4.1.1) */
 #define C_SUBBLOCK (32)
 #define MAX_TB_SIZE (391656)
@@ -1195,12 +1207,11 @@ RTE_PMD_REGISTER_PARAM_STRING(DRIVER_NAME,
TURBO_SW_MAX_NB_QUEUES_ARG"= "
TURBO_SW_SOCKET_ID_ARG"=");
 
-int bbdev_logtype;
 RTE_INIT(null_bbdev_init_log);
 static void
 null_bbdev_init_log(void)
 {
-   bbdev_logtype = rte_log_register("pmd.bb.turbo_sw");
-   if (bbdev_logtype >= 0)
-   rte_log_set_level(bbdev_logtype, RTE_LOG_NOTICE);
+   bbdev_turbo_sw_logtype = rte_log_register("pmd.bb.turbo_sw");
+   if (bbdev_turbo_sw_logtype >= 0)
+   rte_log_set_level(bbdev_turbo_sw_logtype, RTE_LOG_NOTICE);
 }
diff --git a/lib/librte_bbdev/rte_bbdev.c b/lib/librte_bbdev/rte_bbdev.c
index db1c00a..74ecc49 100644
--- a/lib/librte_bbdev/rte_bbdev.c
+++ b/lib/librte_bbdev/rte_bbdev.c
@@ -28,6 +28,17 @@
 #define DEV_NAME "BBDEV"
 
 
+/* BBDev library logging ID */
+static int bbdev_logtype;
+
+/* Helper macro for logging */
+#define rte_bbdev_log(level, fmt, ...) \
+   rte_log(RTE_LOG_ ## level, bbdev_logtype, fmt "\n", ##__VA_ARGS__)
+
+#define rte_bbdev_log_debug(fmt, ...) \
+   rte_bbdev_log(DEBUG, RTE_STR(__LINE__) ":%s() " fmt, __func__, \
+   ##__VA_ARGS__)
+
 /* Helper macro to check dev_id is valid */
 #define VALID_DEV_OR_RET_ERR(dev, dev_id) do { \
if (dev == NULL) { \
@@ -1105,9 +1116,6 @@ rte_bbdev_op_type_str(enum rte_bbdev_op_type op_type)
return NULL;
 }
 
-
-int bbdev_logtype;
-
 RTE_INIT(rte_bbdev_init_log);
 static void
 rte_bbdev_init_log(void)
diff --git a/lib/librte_bbdev/rte_bbdev.h b/lib/librte_bbd

[dpdk-dev] [PATCH v5 5/6] test: fix memory leak in table autotest

[Anatoly Burakov]

Always deallocate allocated resources after the test is done.

Acked-by: Cristian Dumitrescu 

Fixes: 5205954791cb ("app/test: packet framework unit tests")
Cc: cristian.dumitre...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Anatoly Burakov 
---

Notes:
v4: put ack after signoff

 test/test/test_table.c | 44 
 1 file changed, 28 insertions(+), 16 deletions(-)

diff --git a/test/test/test_table.c b/test/test/test_table.c
index c9268a3..f01652d 100644
--- a/test/test/test_table.c
+++ b/test/test/test_table.c
@@ -55,6 +55,14 @@ uint64_t pipeline_test_hash(void *key,
 }
 
 static void
+app_free_resources(void) {
+   int i;
+   for (i = 0; i < N_PORTS; i++)
+   rte_ring_free(rings_rx[i]);
+   rte_mempool_free(pool);
+}
+
+static void
 app_init_mbuf_pools(void)
 {
/* Init the buffer pool */
@@ -113,18 +121,20 @@ app_init_rings(void)
 static int
 test_table(void)
 {
-   int status, failures;
+   int status, ret;
unsigned i;
 
-   failures = 0;
+   ret = TEST_SUCCESS;
 
app_init_rings();
app_init_mbuf_pools();
 
printf("\n\n\n\nPipeline tests\n");
 
-   if (test_table_pipeline() < 0)
-   return -1;
+   if (test_table_pipeline() < 0) {
+   ret = TEST_FAILED;
+   goto end;
+   }
 
printf("\n\n\n\nPort tests\n");
for (i = 0; i < n_port_tests; i++) {
@@ -132,8 +142,8 @@ test_table(void)
if (status < 0) {
printf("\nPort test number %d failed (%d).\n", i,
status);
-   failures++;
-   return -1;
+   ret = TEST_FAILED;
+   goto end;
}
}
 
@@ -143,8 +153,8 @@ test_table(void)
if (status < 0) {
printf("\nTable test number %d failed (%d).\n", i,
status);
-   failures++;
-   return -1;
+   ret = TEST_FAILED;
+   goto end;
}
}
 
@@ -154,21 +164,23 @@ test_table(void)
if (status < 0) {
printf("\nCombined table test number %d failed with "
"reason number %d.\n", i, status);
-   failures++;
-   return -1;
+   ret = TEST_FAILED;
+   goto end;
}
}
 
-   if (failures)
-   return -1;
-
 #ifdef RTE_LIBRTE_ACL
printf("\n\n\n\nACL tests\n");
-   if (test_table_acl() < 0)
-   return -1;
+   if (test_table_acl() < 0) {
+   ret = TEST_FAILED;
+   goto end;
+   }
 #endif
 
-   return 0;
+end:
+   app_free_resources();
+
+   return ret;
 }
 
 REGISTER_TEST_COMMAND(table_autotest, test_table);
-- 
2.7.4

[dpdk-dev] [PATCH v5 4/6] test: fix memory leak in ring perf autotest

[Anatoly Burakov]

Acked-by: Olivier Matz 

Fixes: ac3fb3019c52 ("app: rework ring tests")
Cc: sta...@dpdk.org
Signed-off-by: Anatoly Burakov 
---

Notes:
v2: remove static ring variable

 test/test/test_ring_perf.c | 36 
 1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/test/test/test_ring_perf.c b/test/test/test_ring_perf.c
index 4363e4d..ebb3939 100644
--- a/test/test/test_ring_perf.c
+++ b/test/test/test_ring_perf.c
@@ -32,9 +32,6 @@
  */
 static const volatile unsigned bulk_sizes[] = { 8, 32 };
 
-/* The ring structure used for tests */
-static struct rte_ring *r;
-
 struct lcore_pair {
unsigned c1, c2;
 };
@@ -115,7 +112,7 @@ get_two_sockets(struct lcore_pair *lcp)
 
 /* Get cycle counts for dequeuing from an empty ring. Should be 2 or 3 cycles 
*/
 static void
-test_empty_dequeue(void)
+test_empty_dequeue(struct rte_ring *r)
 {
const unsigned iter_shift = 26;
const unsigned iterations = 1size;
unsigned i;
void *burst[MAX_BURST] = {0};
@@ -192,6 +191,7 @@ dequeue_bulk(void *p)
const unsigned iter_shift = 23;
const unsigned iterations = 1size;
unsigned i;
void *burst[MAX_BURST] = {0};
@@ -222,7 +222,7 @@ dequeue_bulk(void *p)
  * used to measure ring perf between hyperthreads, cores and sockets.
  */
 static void
-run_on_core_pair(struct lcore_pair *cores,
+run_on_core_pair(struct lcore_pair *cores, struct rte_ring *r,
lcore_function_t f1, lcore_function_t f2)
 {
struct thread_params param1 = {0}, param2 = {0};
@@ -230,6 +230,7 @@ run_on_core_pair(struct lcore_pair *cores,
for (i = 0; i < sizeof(bulk_sizes)/sizeof(bulk_sizes[0]); i++) {
lcore_count = 0;
param1.size = param2.size = bulk_sizes[i];
+   param1.r = param2.r = r;
if (cores->c1 == rte_get_master_lcore()) {
rte_eal_remote_launch(f2, ¶m2, cores->c2);
f1(¶m1);
@@ -252,7 +253,7 @@ run_on_core_pair(struct lcore_pair *cores,
  * takes on a single lcore. Result is for comparison with the bulk enq+deq.
  */
 static void
-test_single_enqueue_dequeue(void)
+test_single_enqueue_dequeue(struct rte_ring *r)
 {
const unsigned iter_shift = 24;
const unsigned iterations = 1<

[dpdk-dev] [PATCH v5 2/6] test: fix memory leak in reorder autotest

[Anatoly Burakov]

Add a teardown function that frees allocated resources.

Fixes: d0c9b58d7156 ("app/test: new reorder unit test")
Cc: sergio.gonzalez.mon...@intel.com
Cc: reshma.pat...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Anatoly Burakov 
---

Notes:
v4: fix Reshma Pattan's email address

 test/test/test_reorder.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/test/test/test_reorder.c b/test/test/test_reorder.c
index e834bac..65e4f38 100644
--- a/test/test/test_reorder.c
+++ b/test/test/test_reorder.c
@@ -331,9 +331,20 @@ test_setup(void)
return 0;
 }
 
+static void
+test_teardown(void)
+{
+   rte_reorder_free(test_params->b);
+   test_params->b = NULL;
+   rte_mempool_free(test_params->p);
+   test_params->p = NULL;
+}
+
+
 static struct unit_test_suite reorder_test_suite  = {
 
.setup = test_setup,
+   .teardown = test_teardown,
.suite_name = "Reorder Unit Test Suite",
.unit_test_cases = {
TEST_CASE(test_reorder_create),
-- 
2.7.4

[dpdk-dev] [PATCH v5 1/6] test: fix memory leak in bitmap test

[Anatoly Burakov]

Acked-by: Cristian Dumitrescu 

Fixes: c7e4a134e769 ("test: verify bitmap operations")
Cc: pbhagavat...@caviumnetworks.com
Signed-off-by: Anatoly Burakov 
---

Notes:
v4: put ack after signoff

 test/test/test_bitmap.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/test/test/test_bitmap.c b/test/test/test_bitmap.c
index 05d547e..c3169e9 100644
--- a/test/test/test_bitmap.c
+++ b/test/test/test_bitmap.c
@@ -158,6 +158,9 @@ test_bitmap(void)
if (test_bitmap_scan_operations(bmp) < 0)
return TEST_FAILED;
 
+   rte_bitmap_free(bmp);
+   rte_free(mem);
+
return TEST_SUCCESS;
 }
 
-- 
2.7.4

[dpdk-dev] [PATCH v5 3/6] test: fix memory leak in ring autotest

[Anatoly Burakov]

Get rid of global static ring variable and don't reuse rings
between test runs.

Acked-by: Olivier Matz 

Fixes: 4e32101f9b01 ("ring: support freeing")
Cc: pablo.de.lara.gua...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Anatoly Burakov 
---

Notes:
v5: fix use of uninitialized pointer
v3: fix commit message to point to approriate commit being fixed
v2: remove static ring variable

 test/test/test_ring.c | 63 +++
 1 file changed, 34 insertions(+), 29 deletions(-)

diff --git a/test/test/test_ring.c b/test/test/test_ring.c
index 19d497a..aaf1e70 100644
--- a/test/test/test_ring.c
+++ b/test/test/test_ring.c
@@ -57,8 +57,6 @@
 
 static rte_atomic32_t synchro;
 
-static struct rte_ring *r;
-
 #defineTEST_RING_VERIFY(exp)   
\
if (!(exp)) {   \
printf("error at %s:%d\tcondition " #exp " failed\n",   \
@@ -73,7 +71,7 @@ static struct rte_ring *r;
  * helper routine for test_ring_basic
  */
 static int
-test_ring_basic_full_empty(void * const src[], void *dst[])
+test_ring_basic_full_empty(struct rte_ring *r, void * const src[], void *dst[])
 {
unsigned i, rand;
const unsigned rsz = RING_SIZE - 1;
@@ -114,7 +112,7 @@ test_ring_basic_full_empty(void * const src[], void *dst[])
 }
 
 static int
-test_ring_basic(void)
+test_ring_basic(struct rte_ring *r)
 {
void **src = NULL, **cur_src = NULL, **dst = NULL, **cur_dst = NULL;
int ret;
@@ -250,7 +248,7 @@ test_ring_basic(void)
goto fail;
}
 
-   if (test_ring_basic_full_empty(src, dst) != 0)
+   if (test_ring_basic_full_empty(r, src, dst) != 0)
goto fail;
 
cur_src = src;
@@ -317,7 +315,7 @@ test_ring_basic(void)
 }
 
 static int
-test_ring_burst_basic(void)
+test_ring_burst_basic(struct rte_ring *r)
 {
void **src = NULL, **cur_src = NULL, **dst = NULL, **cur_dst = NULL;
int ret;
@@ -671,7 +669,7 @@ test_ring_basic_ex(void)
 {
int ret = -1;
unsigned i;
-   struct rte_ring * rp;
+   struct rte_ring *rp = NULL;
void **obj = NULL;
 
obj = rte_calloc("test_ring_basic_ex_malloc", RING_SIZE, sizeof(void 
*), 0);
@@ -731,6 +729,7 @@ test_ring_basic_ex(void)
 
ret = 0;
 fail_test:
+   rte_ring_free(rp);
if (obj != NULL)
rte_free(obj);
 
@@ -811,61 +810,67 @@ test_ring_with_exact_size(void)
 static int
 test_ring(void)
 {
+   struct rte_ring *r = NULL;
+
/* some more basic operations */
if (test_ring_basic_ex() < 0)
-   return -1;
+   goto test_fail;
 
rte_atomic32_init(&synchro);
 
+   r = rte_ring_create("test", RING_SIZE, SOCKET_ID_ANY, 0);
if (r == NULL)
-   r = rte_ring_create("test", RING_SIZE, SOCKET_ID_ANY, 0);
-   if (r == NULL)
-   return -1;
+   goto test_fail;
 
/* retrieve the ring from its name */
if (rte_ring_lookup("test") != r) {
printf("Cannot lookup ring from its name\n");
-   return -1;
+   goto test_fail;
}
 
/* burst operations */
-   if (test_ring_burst_basic() < 0)
-   return -1;
+   if (test_ring_burst_basic(r) < 0)
+   goto test_fail;
 
/* basic operations */
-   if (test_ring_basic() < 0)
-   return -1;
+   if (test_ring_basic(r) < 0)
+   goto test_fail;
 
/* basic operations */
if ( test_create_count_odd() < 0){
-   printf ("Test failed to detect odd count\n");
-   return -1;
-   }
-   else
-   printf ( "Test detected odd count\n");
+   printf("Test failed to detect odd count\n");
+   goto test_fail;
+   } else
+   printf("Test detected odd count\n");
 
if ( test_lookup_null() < 0){
-   printf ("Test failed to detect NULL ring 
lookup\n");
-   return -1;
-   }
-   else
-   printf ( "Test detected NULL ring lookup \n");
+   printf("Test failed to detect NULL ring lookup\n");
+   goto test_fail;
+   } else
+   printf("Test detected NULL ring lookup\n");
 
/* test of creating ring with wrong size */
if (test_ring_creation_with_wrong_size() < 0)
-   return -1;
+   goto test_fail;
 
/* test of creation ring with an used name */
if (test_ring_creation_with_an_used_name() < 0)
-   return -1;
+   goto test_fail;
 
if (test_ring_with_exact_size() < 0)
-   return -1;
+   goto test_fail;
 
/* dump the ring status */
rte_ring_list_

[dpdk-dev] [PATCH v5 6/6] test: fix memory leak in timer perf autotest

[Anatoly Burakov]

Fixes: 277afaf3dbcb ("app/test: add timer_perf")
Cc: sta...@dpdk.org
Signed-off-by: Anatoly Burakov 
---
 test/test/test_timer_perf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/test/test/test_timer_perf.c b/test/test/test_timer_perf.c
index afa3a06..0fe2b74 100644
--- a/test/test/test_timer_perf.c
+++ b/test/test/test_timer_perf.c
@@ -127,6 +127,7 @@ test_timer_perf(void)
printf("Time per rte_timer_manage with zero callbacks: %"PRIu64" 
cycles\n",
(end_tsc - start_tsc + iterations/2) / iterations);
 
+   rte_free(tms);
return 0;
 }
 
-- 
2.7.4

[dpdk-dev] [PATCH] net/bnxt: fix Rx checksum flags

[Olivier Matz]

Fix the Rx offload flags when the IP or L4 checksum is seen as incorrect
by the hardware. In this case, the proper value is PKT_RX_IP_CKSUM_BAD.

PKT_RX_IP_CKSUM_NONE means that the checksum may be incorrect in the
packet headers, but the integrity of the IP header is verified. This is
mostly useful for virtual drivers.

Fixes: 7ec39d8c524b ("net/bnxt: update status of Rx IP/L4 CKSUM")
Cc: sta...@dpdk.org

Signed-off-by: Olivier Matz 
---

Hi Ajit,

PKT_RX_IP_CKSUM_UNKNOWN is also a good candidate instead of
PKT_RX_IP_CKSUM_BAD. Please can you check?

Thanks
Olivier



 drivers/net/bnxt/bnxt_rxr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/bnxt/bnxt_rxr.c b/drivers/net/bnxt/bnxt_rxr.c
index 9e70c8604..9b88a64bf 100644
--- a/drivers/net/bnxt/bnxt_rxr.c
+++ b/drivers/net/bnxt/bnxt_rxr.c
@@ -475,12 +475,12 @@ static int bnxt_rx_pkt(struct rte_mbuf **rx_pkt,
if (likely(RX_CMP_IP_CS_OK(rxcmp1)))
mbuf->ol_flags |= PKT_RX_IP_CKSUM_GOOD;
else
-   mbuf->ol_flags |= PKT_RX_IP_CKSUM_NONE;
+   mbuf->ol_flags |= PKT_RX_IP_CKSUM_BAD;
 
if (likely(RX_CMP_L4_CS_OK(rxcmp1)))
mbuf->ol_flags |= PKT_RX_L4_CKSUM_GOOD;
else
-   mbuf->ol_flags |= PKT_RX_L4_CKSUM_NONE;
+   mbuf->ol_flags |= PKT_RX_L4_CKSUM_BAD;
 
mbuf->packet_type = bnxt_parse_pkt_type(rxcmp, rxcmp1);
 
-- 
2.11.0

Re: [dpdk-dev] [PATCH] doc: update i40e guide

[Kovacevic, Marko]

> This patch updates the i40e guide with new device parameter support-multi-
> driver.
> 
> Signed-off-by: Beilei Xing 
> Cc: sta...@dpdk.org
> 
>  doc/guides/nics/i40e.rst | 11 +++
>  1 file changed, 11 insertions(+)
> 

Acked-by: Marko Kovacevic 

[dpdk-dev] [PATCH v2] doc: update multiple instance info for NULL crypto

[Vipin Varghese]

Add foot note & example to inform user how to use multiple instance.

Signed-off-by: Vipin Varghese 
---

V2 Changes:
 - Updated Note for better wording - Pablo
 - Multiple instance information to Crypto Device Lib - Pablo
---
 doc/guides/cryptodevs/null.rst | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/doc/guides/cryptodevs/null.rst b/doc/guides/cryptodevs/null.rst
index 03a3ddc..f476e9d 100644
--- a/doc/guides/cryptodevs/null.rst
+++ b/doc/guides/cryptodevs/null.rst
@@ -41,6 +41,10 @@ each mbuf in the burst will be enqueued in an internal 
buffer for collection on
 a dequeue call as long as the mbuf has a valid rte_mbuf_offload operation with
 a valid rte_cryptodev_session or rte_crypto_xform chain of operations.
 
+.. Note::
+
+In case of multiple NULL cryptos PMD instances, each should have unique id.
+
 Features
 
 
@@ -91,7 +95,9 @@ The following parameters (all optional) can be provided in 
the previous two call
 
 Example:
 
-.. code-block:: console
+-.. code-block:: console
+
+   ./l2fwd-crypto -l 1 -n 4 \
+   --vdev="crypto_null,socket_id=0,max_nb_sessions=128" \
+   -- -p 1 --cdev SW --chain CIPHER_ONLY --cipher_algo "null"
 
-./l2fwd-crypto -l 1 -n 4 
--vdev="crypto_null,socket_id=0,max_nb_sessions=128" \
--- -p 1 --cdev SW --chain CIPHER_ONLY --cipher_algo "null"
-- 
1.9.1

Re: [dpdk-dev] [PATCH] net/bnx2x: reserve enough headroom for mbuf prepend

[Ferruh Yigit]

On 2/6/2018 11:21 AM, zhouyangchao wrote:
> Signed-off-by: Yangchao Zhou 

Hi Yangchao,

There are multiple version of this patch and all seems marked as rejected in
patchwork, intentionally?

If not can you please update the correct one as new in patchwork?

Re: [dpdk-dev] [PATCH 00/14] implement packed virtqueues

[Jens Freimann]

On Tue, Feb 06, 2018 at 02:20:02PM +0800, Jason Wang wrote:



On 2018???01???29??? 22:11, Jens Freimann wrote:
May I ask how do you test the patch? I believe you need some basic 
packed ring support in both qemu and vhost-user protocol.


Yes, I have a small patch for qemu here:
https://github.com/jensfr/qemu/commit/71b4013e3a183b1d5ab6d8ad2bb4829951425d33

Also you need another patch for dpdk to disable ctrl virtqueue
(a workaround) which is on my dpdk branch:

https://github.com/jensfr/dpdk/commit/305f4b2453448402c1994caef8d8e01923660ff3

I will add them to v2 when I send it out.

regards,
Jens 

[dpdk-dev] [PATCH v2] doc: update the usage for shared library

[Vipin Varghese]

Add note information to intimate about use of option '-d' for shared
library in DPDK application.

Signed-off-by: Vipin Varghese 
---

V2 Changes:
 - updated the space - John
 - updated testpmd to dpdk-testpmd - John
---
 doc/guides/nics/build_and_test.rst | 5 +
 1 file changed, 5 insertions(+)

diff --git a/doc/guides/nics/build_and_test.rst 
b/doc/guides/nics/build_and_test.rst
index 62ac52c..9c4e7b2 100644
--- a/doc/guides/nics/build_and_test.rst
+++ b/doc/guides/nics/build_and_test.rst
@@ -151,3 +151,8 @@ This section demonstrates how to setup and run ``testpmd`` 
in Linux.
 
Refer to the :ref:`testpmd runtime functions ` for a list
of available commands.
+
+   .. note::
+
+  When ``dpdk-testpmd`` is built with shared library, use option ``-d`` to
+  load the dynamic PMD for ``rte_eal_init``.
-- 
1.9.1

Re: [dpdk-dev] [PATCH v3] doc: update flow filtering document

[Ferruh Yigit]

On 2/5/2018 3:31 PM, Mcnamara, John wrote:
> 
>> -Original Message-
>> From: Yigit, Ferruh
>> Sent: Wednesday, January 31, 2018 5:24 PM
>> To: Zhao1, Wei ; dev@dpdk.org
>> Cc: Mcnamara, John ; sta...@dpdk.org;
>> or...@mellanox.com
>> Subject: Re: [dpdk-dev] [PATCH v3] doc: update flow filtering document
>>
>> On 1/31/2018 2:12 AM, Wei Zhao wrote:
>>> This patch will update example application of flow_filtering document.
>>> It add Tx queues configuration related comment.
>>>
>>> Signed-off-by: Wei Zhao 
>>> Reviewed-by: Ori Kam 
>>
>> Hi Wei,
>>
>> This patch is causing documentation warning:
>> ...dpdk/doc/guides/sample_app_ug/flow_filtering.rst:161: WARNING: Could
>> not lex literal_block as "c". Highlighting skipped.
> 
> Hi,
> 
> The reason for the warning was due to 2 instances like the following:
> 
> +rte_exit(EXIT_FAILURE,
> +":: Rx queue setup failed: err=%d,
> +port=%u\n",
> +ret, port_id);
> 
> 
> Here the error string extends over 2 lines so the error message will print 
> out a newline and a lot of whitespace in the middle of the string. It should 
> probably
> be something like the following:
> 
> +rte_exit(EXIT_FAILURE,
> +":: Rx queue setup failed: err=%d, "
> +"port=%u\n",
> +ret, port_id);
> 
> or just:
> 
> +rte_exit(EXIT_FAILURE,
> +":: Rx queue setup failed: err=%d, 
> port=%u\n",
> +ret, port_id);

Thanks for clarifying this John.

Patch pulled from next-net-intel to next-net and suggested fix applied on 
next-net.

Re: [dpdk-dev] [PATCH] net/mlx5: dump flow create error message

[Xueming(Steven) Li]

Hi Nelio,

> -Original Message-
> From: Nélio Laranjeiro [mailto:nelio.laranje...@6wind.com]
> Sent: Tuesday, February 6, 2018 9:22 PM
> To: Xueming(Steven) Li 
> Cc: Nelio Laranjeiro ; dev@dpdk.org; Shahaf
> Shuler 
> Subject: Re: [dpdk-dev] [PATCH] net/mlx5: dump flow create error message
> 
> On Tue, Feb 06, 2018 at 08:52:53PM +0800, Xueming Li wrote:
> > Add error message dump when flow create error happened.
> >
> > Signed-off-by: Xueming Li 
> > ---
> >  drivers/net/mlx5/mlx5_flow.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/net/mlx5/mlx5_flow.c
> > b/drivers/net/mlx5/mlx5_flow.c index e38452ef3..ea90556d0 100644
> > --- a/drivers/net/mlx5/mlx5_flow.c
> > +++ b/drivers/net/mlx5/mlx5_flow.c
> > @@ -1890,6 +1890,7 @@ priv_flow_create(struct priv *priv,
> > DEBUG("Flow created %p", (void *)flow);
> > return flow;
> >  exit:
> > +   ERROR("Flow create error: %s", error->message);
> > for (i = 0; i != hash_rxq_init_n; ++i) {
> > if (parser.queue[i].ibv_attr)
> > rte_free(parser.queue[i].ibv_attr);
> > --
> > 2.13.3
> 
> Hi Xueming,
> 
> Can you move this debug message to mlx5_flow_create().

This function also called by control flow and fdir functions, 
here should be the best place.

> 
> Thanks,
> 
> --
> Nélio Laranjeiro
> 6WIND

Re: [dpdk-dev] [PATCH 2/3] net/vdpa_virtio_pci: introduce vdpa sample driver

[Maxime Coquelin]

Hi Xiao,

On 02/04/2018 03:55 PM, Xiao Wang wrote:

This driver is a reference sample of making vDPA device driver based
on vhost lib, this driver uses a standard virtio-net PCI device as
vDPA device, it can serve as a backend for a virtio-net pci device
in nested VM.

The key driver ops implemented are:

* vdpa_virtio_eng_init
Mapping virtio pci device with VFIO into userspace, and read device
capability and intialize internal data.

* vdpa_virtio_eng_uninit
Release the mapped device.

* vdpa_virtio_info_query
Device capability reporting, e.g. queue number, features.

* vdpa_virtio_dev_config
With the guest virtio information provideed by vhost lib, this
function configures device and IOMMU to set up vhost datapath,
which includes: Rx/Tx vring, VFIO interrupt, kick relay.

* vdpa_virtio_dev_close
Unset the stuff that are configured previously by dev_conf.

This driver requires the virtio device supports VIRTIO_F_IOMMU_PLATFORM
, because the buffer address written in desc is IOVA.

Because vDPA driver needs to set up MSI-X vector to interrupt the guest,
only vfio-pci is supported currently.

Signed-off-by: Xiao Wang
---
  config/common_base |6 +
  config/common_linuxapp |1 +
  drivers/net/Makefile   |1 +
  drivers/net/vdpa_virtio_pci/Makefile   |   31 +
  .../net/vdpa_virtio_pci/rte_eth_vdpa_virtio_pci.c  | 1527 
  .../rte_vdpa_virtio_pci_version.map|4 +
  mk/rte.app.mk  |1 +
  7 files changed, 1571 insertions(+)
  create mode 100644 drivers/net/vdpa_virtio_pci/Makefile
  create mode 100644 drivers/net/vdpa_virtio_pci/rte_eth_vdpa_virtio_pci.c
  create mode 100644 drivers/net/vdpa_virtio_pci/rte_vdpa_virtio_pci_version.map


Is there a specific constraint that makes you expose PCI functions and
duplicate a lot of vfio code into the driver?

Wouldn't it be better (if possible) to use RTE_PMD_REGISTER_PCI() & co. 
to benefit from all the existing infrastructure?


Maxime

Re: [dpdk-dev] [PATCH v4] app/testpmd: fix port DCB configuration

[Zhang, Helin]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yanglong Wu
> Sent: Monday, February 5, 2018 5:56 PM
> To: dev@dpdk.org
> Cc: shah...@mellanox.com; Lu, Wenzhuo; Wu, Yanglong
> Subject: [dpdk-dev] [PATCH v4] app/testpmd: fix port DCB configuration
> 
> The port_conf for the DCB configuration should inherit the same configuration
> of the port.
> 
> Fixes: 0074d02fca21("app/testpmd: convert to new Rx offloads API")
> Signed-off-by: Yanglong Wu 
> 
> Acked-by: Shahaf Shuler 
Applied to dpdk-next-net-intel, thanks!

/Helin

Re: [dpdk-dev] [PATCH v1] build: add more implementers' IDs and PNs for Arm platforms

[Bruce Richardson]

On Tue, Feb 06, 2018 at 11:32:59AM +0530, Pavan Nikhilesh wrote:
> On Tue, Feb 06, 2018 at 05:51:29AM +, Herbert Guan wrote:
> > Hi Pavan,
> >
> > > -Original Message-
> > > From: Pavan Nikhilesh [mailto:pbhagavat...@caviumnetworks.com]
> > > Sent: Monday, February 5, 2018 17:23
> > > To: Herbert Guan ;
> > > jerin.ja...@caviumnetworks.com; hemant.agra...@nxp.com;
> > > bruce.richard...@intel.com; harry.van.haa...@intel.com
> > > Cc: dev@dpdk.org
> > > Subject: Re: [PATCH v1] build: add more implementers' IDs and PNs for Arm
> > > platforms
> > >
> > > Hi Herbert,
> > >
> > > On Wed, Jan 31, 2018 at 03:39:19PM +0800, Herbert Guan wrote:
> > > > 1) Add native PN option '-march=native' to allow automatic detection.
> > > >Set 'arm_force_native_march' to 'true' in config/arm/meson.build
> > > >to use native PN option.
> > > > 2) Add implementer_pn option for part num selection in cross compile
> > > > 3) Add known Arm cortex PN support
> > > > 4) Add known implementers' IDs (use generic flags/archs by default)
> > > > 5) Sync build options with config/common_armv8a_linuxapp
> > > >
> > > > Signed-off-by: Herbert Guan 
> > > > ---
> > > 
> > > > +
> > > >  machine_args_generic = [
> > > > -['default', ['-march=armv8-a+crc+crypto']]]
> > > > +['default', ['-march=armv8-a']],
> > >
> > > Any specific reason for this change?
> > > Traditional make uses
> > > MACHINE_CFLAGS += -march=armv8-a+crc+crypto
> > > found at mk/machine/armv8a/rte.vars.mk
> > >
> >
> > Both CRC and Crypto are optional instructions / extensions on Arm v8 CPUs.
> > When making a general build (e.g. a release build for distribution), we 
> > need to
> > ensure all targeted CPUs (all Armv8 for example) can support this compiled
> > binary.  Defaulting crc and crypto to be supported may introduce risks.  
> > For a certain
> > CPU/platform, '-march=native' may be used, or CPU implementers can further
> > Customize these args in this file.
> > On the other hand, the rte_cpuflags.c is already supporting run-time CPU 
> > flags
> > (instruction sets) detection and this is the preferred approach.
> >
> 
> Makes sense, As I mentioned in the previous mail some vendors use 64B
> cacheline instead of 128B as of now I dont see a way to detect that. The 
> vendor
> needs to modify implementor Id specific flags flags_.
> With that in mind.
> 
> Acked-by: Pavan Nikhilesh 

Applied to dpdk-next-build

Thanks,
/Bruce

Re: [dpdk-dev] [PATCH v3] net/i40e: fix multiple DDP packages should not be allowed

[Zhang, Helin]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Xing, Beilei
> Sent: Tuesday, February 6, 2018 10:27 AM
> To: Rybalchenko, Kirill; dev@dpdk.org
> Cc: sta...@dpdk.org; Chilikin, Andrey; Wu, Jingjing
> Subject: Re: [dpdk-dev] [PATCH v3] net/i40e: fix multiple DDP packages should
> not be allowed
> 
> 
> 
> > -Original Message-
> > From: Rybalchenko, Kirill
> > Sent: Thursday, February 1, 2018 8:43 PM
> > To: dev@dpdk.org
> > Cc: sta...@dpdk.org; Rybalchenko, Kirill
> > ; Chilikin, Andrey
> > ; Xing, Beilei ; Wu,
> > Jingjing 
> > Subject: [PATCH v3] net/i40e: fix multiple DDP packages should not be
> > allowed
> >
> > Should be not possible to load conflicting DDP profiles.
> > Only DDP profiles of the same group (not 0) can be loaded together; If
> > DDP profile group is 0, it is exclusive, i.e. it cannot be loaded with
> > any other DDP profile; If DDP profile groups are different - these
> > profiles cannot be loaded together;
> >
> > Fixes: b319712f53c8 ("net/i40e: extended list of operations for DDP
> > processing")
> >
> > v3: prevent registration of read-only profiles with profile list
> >
> > Signed-off-by: Kirill Rybalchenko 
> 
> Acked-by: Beilei Xing , thanks.
Applied to dpdk-next-net-intel, with commit log changes. Thanks!

/Helin

Re: [dpdk-dev] [PATCH v3] net/i40e: fix issue about interrupt

[Zhang, Helin]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Beilei Xing
> Sent: Tuesday, February 6, 2018 1:34 PM
> To: Zhang, Qi Z; Wu, Jingjing
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH v3] net/i40e: fix issue about interrupt
> 
> This patch fixes interval error and corrects macros when enable rx interrupt
> mode. The patch also fixes a logical error during support multiple driver.
> 
> Fixes: be6c228d4da3 ("i40e: support Rx interrupt")
> Fixes: b20aa3aee390 ("net/i40e: fix multiple driver support issue")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Beilei Xing 
Acked-by: Helin Zhang 

Re: [dpdk-dev] [PATCH v2] doc: update the usage for shared library

[Mcnamara, John]

> -Original Message-
> From: Varghese, Vipin
> Sent: Tuesday, February 6, 2018 2:09 PM
> To: dev@dpdk.org; Mcnamara, John 
> Cc: sta...@dpdk.org; Kovacevic, Marko ;
> Varghese, Vipin 
> Subject: [PATCH v2] doc: update the usage for shared library
> 
> Add note information to intimate about use of option '-d' for shared
> library in DPDK application.
> 
> Signed-off-by: Vipin Varghese 
> ---
> 
> V2 Changes:
>  - updated the space - John
>  - updated testpmd to dpdk-testpmd - John

Hi,

It should be the other way around. dpdk-testpmd should be changed to
testpmd:


> +
> +  When ``dpdk-testpmd`` is built with shared library, use option ``-
> d`` to
> +  load the dynamic PMD for ``rte_eal_init``.

Re: [dpdk-dev] [PATCH v3] net/i40e: fix issue about interrupt

[Zhang, Helin]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Zhang, Helin
> Sent: Tuesday, February 6, 2018 11:23 PM
> To: Xing, Beilei; Zhang, Qi Z; Wu, Jingjing
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3] net/i40e: fix issue about interrupt
> 
> 
> 
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Beilei Xing
> > Sent: Tuesday, February 6, 2018 1:34 PM
> > To: Zhang, Qi Z; Wu, Jingjing
> > Cc: dev@dpdk.org; sta...@dpdk.org
> > Subject: [dpdk-dev] [PATCH v3] net/i40e: fix issue about interrupt
> >
> > This patch fixes interval error and corrects macros when enable rx
> > interrupt mode. The patch also fixes a logical error during support multiple
> driver.
> >
> > Fixes: be6c228d4da3 ("i40e: support Rx interrupt")
> > Fixes: b20aa3aee390 ("net/i40e: fix multiple driver support issue")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Beilei Xing 
> Acked-by: Helin Zhang 
Applied to dpdk-next-net-intel, with commit log changes, thanks!

Helin

Re: [dpdk-dev] [PATCH 1/8] vhost: add security model documentation to vhost_user.c

[Kovacevic, Marko]

<...>

> > This is a useful comment but I don't know if it makes sense to include it in
> the vhost_user.c file.
> >
> > Particularly at the top where it looks like a general descriptive comment 
> > for
> the file.
> >
> > It would probably be better in the vhost-user section of the programmer's
> guide:
> >
> > http://dpdk.org/doc/guides/prog_guide/vhost_lib.html
> 
> That is the public API documentation for users of the library.  They don't
> parse VhostUserMsg so I'm not sure the comment would be relevant there.
> 
> > Also, the subject line shouldn't include an underscore.
> 
> Do you mean the "vhost_user.c" filename in the subject line?
> 
> Please explain why this isn't allowed.
> 
> Stefan


You can run this command to check the git log.

./devtools/check-git-log.sh -1

Running git check log on HEAD~1:  34962
==
Wrong headline format:
vhost: add security model documentation to vhost_user.c

[dpdk-dev] [PATCH] ether: fix incorrect stats query for lowest xstat id

[Bruce Richardson]

When querying either the name or the value of a stat using the xstats
APIs, a check is done to see if the regular stats API or the xstats APIs
for the driver need to be used. However, the id of the stat requested is
checked to see if it is greater than the number of basic stats, rather
than checking for greater-or-equal, meaning that the xstat with the lowest
id gets incorrectly treated as a basic stat.

This problem manifests itself when you call proc_info using "--xstats-id"
for the first xstat, you get no name of the stat printed, and a random(ish)
stat value.

Fixes: 4773152f850b ("ethdev: optimize xstats by ids APIs")

Signed-off-by: Bruce Richardson 
---
 lib/librte_ether/rte_ethdev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 78bed1a16..a6ce2a5ba 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -2045,7 +2045,7 @@ rte_eth_xstats_get_names_by_id(uint16_t port_id,
 
if (ids) {
for (i = 0; i < size; i++) {
-   if (ids[i] > basic_count) {
+   if (ids[i] >= basic_count) {
no_ext_stat_requested = 0;
break;
}
@@ -2225,7 +2225,7 @@ rte_eth_xstats_get_by_id(uint16_t port_id, const uint64_t 
*ids,
 
if (ids) {
for (i = 0; i < size; i++) {
-   if (ids[i] > basic_count) {
+   if (ids[i] >= basic_count) {
no_ext_stat_requested = 0;
break;
}
-- 
2.14.3

Re: [dpdk-dev] [PATCH v4] doc: convert Intel sharing license headers to SPDX tags

[Kovacevic, Marko]

> Subject: [dpdk-dev] [PATCH v4] doc: convert Intel sharing license headers to
> SPDX tags
> 
> Signed-off-by: Ferruh Yigit 
> Acked-by: Bruce Richardson 
> ---
> v3: Intel ones sharing copyright
> ---
>  doc/guides/linux_gsg/linux_drivers.rst | 28 +---

<...>

Acked-by: Marko Kovacevic 

Re: [dpdk-dev] [PATCH] doc: fix release note for rawdev library

[Kovacevic, Marko]

> Signed-off-by: Shreyansh Jain 
> ---
>  doc/guides/rel_notes/release_18_02.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Marko Kovacevic 

[dpdk-dev] [PATCH v3] doc: add info on multiple instance SW crypto

[Vipin Varghese]

Add infomration to explain applications using multiple instances of sw
crypto with example.

Signed-off-by: Vipin Varghese 
---

V3 Changes:
 - moved the multiple sw crypto to more generic place holder - Pablo

V2 Changes:
 - Updated Note for better wording - Pablo
 - Multiple instance information to Crypto Device Lib - Pablo
---
 doc/guides/prog_guide/cryptodev_lib.rst | 9 +
 1 file changed, 9 insertions(+)

diff --git a/doc/guides/prog_guide/cryptodev_lib.rst 
b/doc/guides/prog_guide/cryptodev_lib.rst
index 2b338b9..d11e377 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -70,6 +70,15 @@ From the command line using the --vdev EAL option
 
--vdev  
'crypto_aesni_mb0,max_nb_queue_pairs=2,max_nb_sessions=1024,socket_id=0'
 
+.. Note::
+
+   * If DPDK application requires multiple software crypto PMD devices then 
required
+ number of ``--vdev`` with appropriate libraries are to be added.
+
+   * An Application with crypto PMD instaces sharing the same library requires 
unique ID.
+
+   Example: ``--vdev  'crypto_aesni_mb0' --vdev  'crypto_aesni_mb1'``
+
 Our using the rte_vdev_init API within the application code.
 
 .. code-block:: c
-- 
1.9.1

[dpdk-dev] [PATCH] bus: fix dpaa returning IOVA as PA

[Pavan Nikhilesh]

Fix dpaa bus returning IOVA as PA when there is no device attached to
the bus.

Fixes: 1ee9569576f6 ("config: enable dpaaX drivers for generic ARMv8")
Fixes: d5a4e3a00c4a ("bus/dpaa: set IOVA mode as physical")

Signed-off-by: Pavan Nikhilesh 
---

 Currently Octeontx platform is broken due to this, please merge this asap.

 drivers/bus/dpaa/dpaa_bus.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/bus/dpaa/dpaa_bus.c b/drivers/bus/dpaa/dpaa_bus.c
index 41ee640e2..579870297 100644
--- a/drivers/bus/dpaa/dpaa_bus.c
+++ b/drivers/bus/dpaa/dpaa_bus.c
@@ -501,6 +501,10 @@ rte_dpaa_find_device(const struct rte_device *start, 
rte_dev_cmp_t cmp,
 static enum rte_iova_mode
 rte_dpaa_get_iommu_class(void)
 {
+   if ((access(DPAA_DEV_PATH1, F_OK) != 0) &&
+   (access(DPAA_DEV_PATH2, F_OK) != 0)) {
+   return RTE_IOVA_DC;
+   }
return RTE_IOVA_PA;
 }

--
2.16.0

Re: [dpdk-dev] [PATCH v3] doc: add info on multiple instance SW crypto

[De Lara Guarch, Pablo]

> -Original Message-
> From: Varghese, Vipin
> Sent: Tuesday, February 6, 2018 4:12 PM
> To: dev@dpdk.org; De Lara Guarch, Pablo
> 
> Cc: sta...@dpdk.org; Mcnamara, John ;
> Kovacevic, Marko ; Varghese, Vipin
> 
> Subject: [PATCH v3] doc: add info on multiple instance SW crypto
> 
> Add infomration to explain applications using multiple instances of sw
> crypto with example.
> 
> Signed-off-by: Vipin Varghese 
> ---
> 
> V3 Changes:
>  - moved the multiple sw crypto to more generic place holder - Pablo
> 
> V2 Changes:
>  - Updated Note for better wording - Pablo
>  - Multiple instance information to Crypto Device Lib - Pablo
> ---
>  doc/guides/prog_guide/cryptodev_lib.rst | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/doc/guides/prog_guide/cryptodev_lib.rst
> b/doc/guides/prog_guide/cryptodev_lib.rst
> index 2b338b9..d11e377 100644
> --- a/doc/guides/prog_guide/cryptodev_lib.rst
> +++ b/doc/guides/prog_guide/cryptodev_lib.rst
> @@ -70,6 +70,15 @@ From the command line using the --vdev EAL option
> 
> --vdev
> 'crypto_aesni_mb0,max_nb_queue_pairs=2,max_nb_sessions=1024,socket
> _id=0'
> 
> +.. Note::
> +
> +   * If DPDK application requires multiple software crypto PMD devices
> then required
> + number of ``--vdev`` with appropriate libraries are to be added.
> +
> +   * An Application with crypto PMD instaces sharing the same library
> requires unique ID.

Typo: instances (which could be fixed when merging).

Also, there is no need to add sta...@dpdk.org, so I will remove it from the CC 
list.

Apart from this:

Acked-by: Pablo de Lara 

Re: [dpdk-dev] [PATCH v4] raw/skeleton: fix device start test

[Thomas Monjalon]

06/02/2018 07:43, Shreyansh Jain:
> Device can only be started if firmware is loaded, as per Skeleton
> rawdev driver semantics. This patch fixes original implementation
> which attempted to start the device without loading firmware.
> 
> Fixes: 55ca1b0f2151 ("raw/skeleton: add test cases")
> Cc: shreyansh.j...@nxp.com
> 
> Signed-off-by: Shreyansh Jain 

Applied, thanks

Re: [dpdk-dev] [PATCH v2] doc: update application minimum requirement info

[De Lara Guarch, Pablo]

> -Original Message-
> From: Varghese, Vipin
> Sent: Monday, February 5, 2018 5:32 PM
> To: dev@dpdk.org; Kovacevic, Marko ; De
> Lara Guarch, Pablo 
> Cc: Mcnamara, John ; Varghese, Vipin
> 
> Subject: [PATCH v2] doc: update application minimum requirement info
> 
> Added note section to update information for use cases working with
> multiple crypto devices.
> 
> Signed-off-by: Vipin Varghese 

Acked-by: Pablo de Lara 

Re: [dpdk-dev] [PATCH] doc: fix release note for rawdev library

[Thomas Monjalon]

06/02/2018 17:10, Kovacevic, Marko:
> > Signed-off-by: Shreyansh Jain 
> > ---
> >  doc/guides/rel_notes/release_18_02.rst | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Acked-by: Marko Kovacevic 

Applied, thanks

Re: [dpdk-dev] [PATCH v2] examples/l2fwd: check if user portmask is valid

[De Lara Guarch, Pablo]

> -Original Message-
> From: Varghese, Vipin
> Sent: Thursday, February 1, 2018 6:59 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; De Lara Guarch, Pablo
> ; Richardson, Bruce
> ; Varghese, Vipin
> 
> Subject: [PATCH v2] examples/l2fwd: check if user portmask is valid
> 
> User can pass portmask with any value, even invalid mask. The code checks
> against actual portmask.
> 
> Signed-off-by: Vipin Varghese 
> ---
> 
> V2 Changes:
>  - correct the spelling in comment - Vipin

I think there is no need to CC stable here, so I will remove it from the list.

Acked-by: Pablo de Lara 

[dpdk-dev] [PATCH] net/bnxt: fix packet type

[Olivier Matz]

The hw flags are not read correctly: the defines
RX_PKT_CMPL_FLAGS_ITYPE_* are not bits but values, so the should not be
tested with if (value & X) but with if ((value & MASK) == X).
This was resulting in a wrong packet type.

For instance, an IPv4/ICMP packet was returning a value of 7 for
the layer 4, which is undefined.

This patch rework the way packet types are processed, to ensure
that only valid packet types will be advertised.

Fixes: 3d2a6644eb05 ("net/bnxt: support getting ptypes")
Cc: sta...@dpdk.org

Signed-off-by: Olivier Matz 
---
 drivers/net/bnxt/bnxt_rxr.c | 75 -
 1 file changed, 47 insertions(+), 28 deletions(-)

diff --git a/drivers/net/bnxt/bnxt_rxr.c b/drivers/net/bnxt/bnxt_rxr.c
index 9b88a64bf..2b4044a83 100644
--- a/drivers/net/bnxt/bnxt_rxr.c
+++ b/drivers/net/bnxt/bnxt_rxr.c
@@ -338,41 +338,60 @@ static inline struct rte_mbuf *bnxt_tpa_end(
 static uint32_t
 bnxt_parse_pkt_type(struct rx_pkt_cmpl *rxcmp, struct rx_pkt_cmpl_hi *rxcmp1)
 {
-   uint32_t pkt_type = 0;
-   uint32_t t_ipcs = 0, ip = 0, ip6 = 0;
-   uint32_t tcp = 0, udp = 0, icmp = 0;
-   uint32_t vlan = 0;
+   uint32_t l3, pkt_type = 0;
+   uint32_t t_ipcs = 0, ip6 = 0, vlan = 0;
+   uint32_t flags_type;
 
vlan = !!(rxcmp1->flags2 &
rte_cpu_to_le_32(RX_PKT_CMPL_FLAGS2_META_FORMAT_VLAN));
+   pkt_type |= vlan ? RTE_PTYPE_L2_ETHER_VLAN : RTE_PTYPE_L2_ETHER;
+
t_ipcs = !!(rxcmp1->flags2 &
rte_cpu_to_le_32(RX_PKT_CMPL_FLAGS2_T_IP_CS_CALC));
ip6 = !!(rxcmp1->flags2 &
 rte_cpu_to_le_32(RX_PKT_CMPL_FLAGS2_IP_TYPE));
-   icmp = !!(rxcmp->flags_type &
- rte_cpu_to_le_16(RX_PKT_CMPL_FLAGS_ITYPE_ICMP));
-   tcp = !!(rxcmp->flags_type &
-rte_cpu_to_le_16(RX_PKT_CMPL_FLAGS_ITYPE_TCP));
-   udp = !!(rxcmp->flags_type &
-rte_cpu_to_le_16(RX_PKT_CMPL_FLAGS_ITYPE_UDP));
-   ip = !!(rxcmp->flags_type &
-   rte_cpu_to_le_16(RX_PKT_CMPL_FLAGS_ITYPE_IP));
-
-   pkt_type |= ((ip || tcp || udp || icmp) && !t_ipcs && !ip6) ?
-   RTE_PTYPE_L3_IPV4_EXT_UNKNOWN : 0;
-   pkt_type |= ((ip || tcp || udp || icmp) && !t_ipcs && ip6) ?
-   RTE_PTYPE_L3_IPV6_EXT_UNKNOWN : 0;
-   pkt_type |= (!t_ipcs &&  icmp) ? RTE_PTYPE_L4_ICMP : 0;
-   pkt_type |= (!t_ipcs &&  udp) ? RTE_PTYPE_L4_UDP : 0;
-   pkt_type |= (!t_ipcs &&  tcp) ? RTE_PTYPE_L4_TCP : 0;
-   pkt_type |= ((ip || tcp || udp || icmp) && t_ipcs && !ip6) ?
-   RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN : 0;
-   pkt_type |= ((ip || tcp || udp || icmp) && t_ipcs && ip6) ?
-   RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN : 0;
-   pkt_type |= (t_ipcs &&  icmp) ? RTE_PTYPE_INNER_L4_ICMP : 0;
-   pkt_type |= (t_ipcs &&  udp) ? RTE_PTYPE_INNER_L4_UDP : 0;
-   pkt_type |= (t_ipcs &&  tcp) ? RTE_PTYPE_INNER_L4_TCP : 0;
-   pkt_type |= vlan ? RTE_PTYPE_L2_ETHER_VLAN : 0;
+
+   flags_type = rxcmp->flags_type &
+   rte_cpu_to_le_32(RX_PKT_CMPL_FLAGS_ITYPE_MASK);
+
+   if (!t_ipcs && !ip6)
+   l3 = RTE_PTYPE_L3_IPV4_EXT_UNKNOWN;
+   else if (!t_ipcs && ip6)
+   l3 = RTE_PTYPE_L3_IPV6_EXT_UNKNOWN;
+   else if (t_ipcs && !ip6)
+   l3 = RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN;
+   else
+   l3 = RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN;
+
+   switch (flags_type) {
+   case RTE_LE32(RX_PKT_CMPL_FLAGS_ITYPE_ICMP):
+   if (!t_ipcs)
+   pkt_type |= l3 | RTE_PTYPE_L4_ICMP;
+   else
+   pkt_type |= l3 | RTE_PTYPE_INNER_L4_ICMP;
+   break;
+
+   case RTE_LE32(RX_PKT_CMPL_FLAGS_ITYPE_TCP):
+   if (!t_ipcs)
+   pkt_type |= l3 | RTE_PTYPE_L4_TCP;
+   else
+   pkt_type |= l3 | RTE_PTYPE_INNER_L4_TCP;
+   break;
+
+   case RTE_LE32(RX_PKT_CMPL_FLAGS_ITYPE_UDP):
+   if (!t_ipcs)
+   pkt_type |= l3 | RTE_PTYPE_L4_UDP;
+   else
+   pkt_type |= l3 | RTE_PTYPE_INNER_L4_UDP;
+   break;
+
+   case RTE_LE32(RX_PKT_CMPL_FLAGS_ITYPE_IP):
+   if (!t_ipcs)
+   pkt_type |= l3 | RTE_PTYPE_L4_ICMP;
+   else
+   pkt_type |= l3 | RTE_PTYPE_INNER_L4_ICMP;
+   break;
+   }
 
return pkt_type;
 }
-- 
2.11.0

[dpdk-dev] [PATCH] bus/fslmc: fix build issue with latest glib-headers

[Jerin Jacob]

Fix the following build error with latest glib-headers(
Part of aarch64-linux-gnu-gcc-7.3.0 toolchain)

In file included from /tmp/drivers/bus/fslmc/mc/fsl_mc_sys.h:30:0,
 from /tmp/drivers/bus/fslmc/mc/dpmng.c:7:
/usr/aarch64-linux-gnu/usr/include/libio.h:21:2: error:
#warning " is deprecated; use  instead." [-Werror=cpp]

Fixes: 3af733ba8da8 ("bus/fslmc: introduce MC object functions")
Cc: sta...@dpdk.org

Signed-off-by: Jerin Jacob 
---

Since fslmc is part of the default armv8 config now, With out this patch
it breaks all armv8 build with latest toolchain

---
 drivers/bus/fslmc/mc/fsl_mc_sys.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/bus/fslmc/mc/fsl_mc_sys.h 
b/drivers/bus/fslmc/mc/fsl_mc_sys.h
index a48da1071..d0c7b39f8 100644
--- a/drivers/bus/fslmc/mc/fsl_mc_sys.h
+++ b/drivers/bus/fslmc/mc/fsl_mc_sys.h
@@ -27,7 +27,6 @@ struct fsl_mc_io {
 #else /* __linux_driver__ */
 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.16.1

Re: [dpdk-dev] [PATCH v2 0/3] testpmd: fix rss forward config

[Thomas Monjalon]

> Matan Azrad (3):
>   app/testpmd: fix port index in RSS fwd config
>   app/testpmd: fix port topology in RSS fwd config
>   app/testpmd: use dedicated function to get Tx port

Applied, thanks

[dpdk-dev] [PATCH v2] bus/dpaa: fix dpaa returning IOVA as PA by default

[Pavan Nikhilesh]

Fix dpaa bus returning IOVA as PA even when it is not running on dpaa
platform.

Fixes: 1ee9569576f6 ("config: enable dpaaX drivers for generic ARMv8")
Fixes: d5a4e3a00c4a ("bus/dpaa: set IOVA mode as physical")

Signed-off-by: Pavan Nikhilesh 
---

 v2 Changes:
 - redo commit log.

 Currently all armv8 platforms are broken due to this.

 drivers/bus/dpaa/dpaa_bus.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/bus/dpaa/dpaa_bus.c b/drivers/bus/dpaa/dpaa_bus.c
index 290b967da..f2bb3b158 100644
--- a/drivers/bus/dpaa/dpaa_bus.c
+++ b/drivers/bus/dpaa/dpaa_bus.c
@@ -541,6 +541,10 @@ rte_dpaa_find_device(const struct rte_device *start, 
rte_dev_cmp_t cmp,
 static enum rte_iova_mode
 rte_dpaa_get_iommu_class(void)
 {
+   if ((access(DPAA_DEV_PATH1, F_OK) != 0) &&
+   (access(DPAA_DEV_PATH2, F_OK) != 0)) {
+   return RTE_IOVA_DC;
+   }
return RTE_IOVA_PA;
 }

--
2.14.1

Re: [dpdk-dev] [PATCH v2] bus/dpaa: fix dpaa returning IOVA as PA by default

[Hemant Agrawal]

On 2/6/2018 10:52 PM, Pavan Nikhilesh wrote:

Fix dpaa bus returning IOVA as PA even when it is not running on dpaa
platform.

Fixes: 1ee9569576f6 ("config: enable dpaaX drivers for generic ARMv8")
Fixes: d5a4e3a00c4a ("bus/dpaa: set IOVA mode as physical")

Signed-off-by: Pavan Nikhilesh 
---

  v2 Changes:
  - redo commit log.

  Currently all armv8 platforms are broken due to this.

  drivers/bus/dpaa/dpaa_bus.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/bus/dpaa/dpaa_bus.c b/drivers/bus/dpaa/dpaa_bus.c
index 290b967da..f2bb3b158 100644
--- a/drivers/bus/dpaa/dpaa_bus.c
+++ b/drivers/bus/dpaa/dpaa_bus.c
@@ -541,6 +541,10 @@ rte_dpaa_find_device(const struct rte_device *start, 
rte_dev_cmp_t cmp,
  static enum rte_iova_mode
  rte_dpaa_get_iommu_class(void)
  {
+   if ((access(DPAA_DEV_PATH1, F_OK) != 0) &&
+   (access(DPAA_DEV_PATH2, F_OK) != 0)) {
+   return RTE_IOVA_DC;
+   }
return RTE_IOVA_PA;
  }

--
2.14.1



Acked-by: Hemant Agrawal 

Re: [dpdk-dev] [dpdk-stable] [PATCH] bus/fslmc: fix build issue with latest glib-headers

[Thomas Monjalon]

06/02/2018 18:14, Jerin Jacob:
> Fix the following build error with latest glib-headers(
> Part of aarch64-linux-gnu-gcc-7.3.0 toolchain)
> 
> In file included from /tmp/drivers/bus/fslmc/mc/fsl_mc_sys.h:30:0,
>  from /tmp/drivers/bus/fslmc/mc/dpmng.c:7:
> /usr/aarch64-linux-gnu/usr/include/libio.h:21:2: error:
> #warning " is deprecated; use  instead." [-Werror=cpp]
> 
> Fixes: 3af733ba8da8 ("bus/fslmc: introduce MC object functions")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Jerin Jacob 
> ---
> 
> Since fslmc is part of the default armv8 config now, With out this patch
> it breaks all armv8 build with latest toolchain

Applied, thanks

Re: [dpdk-dev] [PATCH v2] bus/dpaa: fix dpaa returning IOVA as PA by default

[Thomas Monjalon]

06/02/2018 18:28, Hemant Agrawal:
> On 2/6/2018 10:52 PM, Pavan Nikhilesh wrote:
> > Fix dpaa bus returning IOVA as PA even when it is not running on dpaa
> > platform.
> > 
> > Fixes: 1ee9569576f6 ("config: enable dpaaX drivers for generic ARMv8")
> > Fixes: d5a4e3a00c4a ("bus/dpaa: set IOVA mode as physical")
> > 
> > Signed-off-by: Pavan Nikhilesh 
> > ---
> > 
> >   v2 Changes:
> >   - redo commit log.
> > 
> >   Currently all armv8 platforms are broken due to this.
> > 
> Acked-by: Hemant Agrawal 

Applied, thanks

Re: [dpdk-dev] [PATCH] ether: fix incorrect stats query for lowest xstat id

[Ferruh Yigit]

On 2/6/2018 4:06 PM, Bruce Richardson wrote:
> When querying either the name or the value of a stat using the xstats
> APIs, a check is done to see if the regular stats API or the xstats APIs
> for the driver need to be used. However, the id of the stat requested is
> checked to see if it is greater than the number of basic stats, rather
> than checking for greater-or-equal, meaning that the xstat with the lowest
> id gets incorrectly treated as a basic stat.
> 
> This problem manifests itself when you call proc_info using "--xstats-id"
> for the first xstat, you get no name of the stat printed, and a random(ish)
> stat value.
> 
> Fixes: 4773152f850b ("ethdev: optimize xstats by ids APIs")
> 
> Signed-off-by: Bruce Richardson 

Reviewed-by: Ferruh Yigit 

Re: [dpdk-dev] [PATCH] ether: fix incorrect stats query for lowest xstat id

[Thomas Monjalon]

06/02/2018 17:06, Bruce Richardson:
> When querying either the name or the value of a stat using the xstats
> APIs, a check is done to see if the regular stats API or the xstats APIs
> for the driver need to be used. However, the id of the stat requested is
> checked to see if it is greater than the number of basic stats, rather
> than checking for greater-or-equal, meaning that the xstat with the lowest
> id gets incorrectly treated as a basic stat.
> 
> This problem manifests itself when you call proc_info using "--xstats-id"
> for the first xstat, you get no name of the stat printed, and a random(ish)
> stat value.
> 
> Fixes: 4773152f850b ("ethdev: optimize xstats by ids APIs")
> 
> Signed-off-by: Bruce Richardson 

Applied, thanks

It looks like the stats functions are the most reworked and fixed.
It is a no-end story. According to git statistics, it is probably
the most complicate code of DPDK :)
I am thinking about being more conservative and do not accept any
new change in these rocket science functions ;)

Re: [dpdk-dev] [PATCH v2] bbdev: fix exported dynamic log type

[Thomas Monjalon]

06/02/2018 14:29, Amr Mokhtar:
> This patch fixes shared library compilation due to undefined
> reference to an exported variable 'bbdev_logtype'.
> 
> v2:
> * In this fix,
> * - The logtype has become static and owned individually by each
> *component.
> * - Helper logging macros are removed from bbdev lib header files
> *and replaced with macros defined by each driver at its ease.
> * - 'bbdev_logtype' removed from .map
> 
> v1:
> * This patch fixes shared library compilation due to undefined
> * reference to an exported variable 'bbdev_logtype'.
> * In this fix, the logtype is converted to static in the bbdev lib,
> * in bbdev null pmd and turbo sw pmd.
> 
> 
> Fixes: 4935e1e9f76e ("bbdev: introduce wireless base band device lib")
> Fixes: b8cfe2c9aed2 ("bb/turbo_sw: add software turbo driver")
> Fixes: 7dc2b1589440 ("bb/null: add null base band device driver")
> Cc: tho...@monjalon.net
> 
> Signed-off-by: Amr Mokhtar 

Applied, thanks

Re: [dpdk-dev] [PATCH v2] examples/l2fwd: check if user portmask is valid

[Thomas Monjalon]

> > User can pass portmask with any value, even invalid mask. The code checks
> > against actual portmask.
> > 
> > Signed-off-by: Vipin Varghese 
> > ---
> > 
> > V2 Changes:
> >  - correct the spelling in comment - Vipin
> 
> I think there is no need to CC stable here, so I will remove it from the list.
> 
> Acked-by: Pablo de Lara 

Applied, thanks

Re: [dpdk-dev] IXGBE, IOMMU DMAR DRHD handling fault issue

[Ravi Kerur]

On Mon, Feb 5, 2018 at 2:01 AM, Burakov, Anatoly 
wrote:

> On 02-Feb-18 8:51 PM, Ravi Kerur wrote:
>
>>
>>
>> On Fri, Feb 2, 2018 at 12:21 PM, Ravi Kerur > rke...@gmail.com>> wrote:
>>
>>
>>
>> On Fri, Feb 2, 2018 at 2:28 AM, Burakov, Anatoly
>> mailto:anatoly.bura...@intel.com>> wrote:
>>
>> On 01-Feb-18 7:26 PM, Ravi Kerur wrote:
>>
>>
>>
>> On Thu, Feb 1, 2018 at 2:10 AM, Burakov, Anatoly
>> > 
>> >
>> >> wrote:
>>
>>  On 31-Jan-18 9:51 PM, Ravi Kerur wrote:
>>
>>
>>  Hi Anatoly,
>>
>>  Thanks. I am following wiki link below which uses
>> vIOMMU with
>>  DPDK as a use-case and instantiate VM as specified
>> with Q35
>>  chipset in Qemu.
>>
>> https://wiki.qemu.org/Features/VT-d
>> 
>>  > >
>>
>>  Qemu-version is 2.11
>>  Host kernel 4.9
>>  Guest kernel 4.4
>>
>>  I can only guess that guest kernel needs an upgrade
>> in my setup
>>  to work correctly, if versions on my setup rings a
>> bell on not
>>  having support kindly let me know.
>>
>>  When 'modprobe vfio enable_unsafe_noiommu_node=Y'
>> is executed on
>>  guest I get following error
>>  ...
>>  vfio: unknown parameter
>> 'enable_unsafe_noiommu_node' ignored
>>  ...
>>
>>  in guest.
>>
>>  Thanks.
>>
>>
>>  AFAIK kernel 4.4 should have noiommu mode - it was
>> introduced in
>>  3.1x days. However, in order for that to work, kernel
>> also has to be
>>  built with this mode enabled. My guess is, whoever is
>> the supplier
>>  of your kernel, did not do that. You should
>> double-check the kernel
>>  configuration of your distribution.
>>
>>  However, if you have vIOMMU in QEMU, you shouldn't need
>> noiommu mode
>>  - "regular" vfio should work fine. noiommu mode should
>> only be
>>  needed if you know you don't have IOMMU enabled in your
>> kernel, and
>>  even if you can't enable it, you can still use igb_uio.
>>
>> Hi Anatoly,
>>
>> Do you suggest I take this discussion to kvm/qemu mailing
>> list as I am not sure which component has the issue? I check
>> dmesg for BIOS physical memory map and address reported as
>> fault by DMAR is reported by BIOS as usable on both host and
>> vm.
>>
>> [ 4539.597737] DMAR: [DMA Read] Request device [04:10.0]
>> fault addr *33a128000 *[fault reason 06] PTE Read access is
>> not set
>>
>> dmesg | grep BIOS
>> [0.00] e820: BIOS-provided physical RAM map:
>> [0.00] BIOS-e820: [mem
>> 0x-0x0009afff] usable
>> [0.00] BIOS-e820: [mem
>> 0x0009b000-0x0009] reserved
>> [0.00] BIOS-e820: [mem
>> 0x000e-0x000f] reserved
>> [0.00] BIOS-e820: [mem
>> 0x0010-0x7938afff] usable
>> [0.00] BIOS-e820: [mem
>> 0x7938b000-0x7994bfff] reserved
>> [0.00] BIOS-e820: [mem
>> 0x7994c000-0x7999cfff] ACPI data
>> [0.00] BIOS-e820: [mem
>> 0x7999d000-0x79f7dfff] ACPI NVS
>> [0.00] BIOS-e820: [mem
>> 0x79f7e000-0x7bd37fff] reserved
>> [0.00] BIOS-e820: [mem
>> 0x7bd38000-0x7bd38fff] usable
>> [0.00] BIOS-e820: [mem
>> 0x7bd39000-0x7bdbefff] reserved
>> [0.00] BIOS-e820: [mem
>> 0x7bdbf000-0x7bff] usable
>> [0.00] BIOS-e820: [mem
>> 0x7c00-0x8fff] reserved
>> [0.00] BIOS-e820: [mem
>> 0xfed1c000-0xfed44fff] reserved
>> [0.00] BIOS-e820: [mem
>> 0xff00-0x] reserved
>> [*0.00] BIOS-e820: [mem
>>   

Re: [dpdk-dev] [PATCH] examples/ip_pipeline: fix timer_period unit

[Singh, Jasvinder]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of
> long...@viettel.com.vn
> Sent: Wednesday, January 31, 2018 8:48 AM
> To: Dumitrescu, Cristian 
> Cc: dev@dpdk.org; longtb5 
> Subject: [dpdk-dev] [PATCH] examples/ip_pipeline: fix timer_period unit
> 
> The timer_period option specified by users via config file should have unit of
> 1 millisecond. However timer_period is internally converted to unit of 10
> millisecond.
> 
> Fixes: 4e14069328fc ("examples/ip_pipeline: measure CPU utilization")
> 
> Signed-off-by: Bao-Long Tran 
> ---
>  examples/ip_pipeline/init.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/examples/ip_pipeline/init.c b/examples/ip_pipeline/init.c index
> 55d246f..bb07efa 100644
> --- a/examples/ip_pipeline/init.c
> +++ b/examples/ip_pipeline/init.c
> @@ -1704,7 +1704,7 @@ app_init_pipelines(struct app_params *app)
>   data->ptype = ptype;
> 
>   data->timer_period = (rte_get_tsc_hz() *
> - params->timer_period) / 100;
> + params->timer_period) / 1000;
>   }
>  }

Reviewed-by: Jasvinder Singh 

Re: [dpdk-dev] [PATCH v5 1/6] test: fix memory leak in bitmap test

[Thomas Monjalon]

06/02/2018 14:35, Anatoly Burakov:
> Acked-by: Cristian Dumitrescu 
> 
> Fixes: c7e4a134e769 ("test: verify bitmap operations")
> Cc: pbhagavat...@caviumnetworks.com
> Signed-off-by: Anatoly Burakov 

Series applied, thanks

[dpdk-dev] EAL reports "ot enough memory available on socket 0!"

[Huertas García , Víctor]

Hi all,


This is my first post in this mailing list. I am glad to become a member of 
this community.


I am a newbie using DPDK and I have tried to compile and execute an example app 
called "l3fwd-acl".


The DPDK command is DPDK_Test -c 0xf0 -n 2 --socket-mem 64

but the application tells me the following:


EAL: Detected 8 lcore(s)
EAL: Probing VFIO support...
EAL: VFIO support initialized
EAL: Cannot obtain physical addresses: Success. Only vfio will function.
EAL: Not enough memory available on socket 0! Requested: 64MB, available: 0MB
EAL: FATAL: Cannot init memory

EAL: Cannot init memory

EAL: Error - exiting with code: 1
  Cause: Invalid EAL parameters



I don't know what else I can do to make this app run as I have reserved 
hugepages as the user guide tells as well as mounted the /mnt/huge folder.


cat /proc/meminfo | grep Huge
AnonHugePages:520192 kB
HugePages_Total:  64
HugePages_Free:   64
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB


My machine is has this topology (only one Numa node is detected):


udo usertools/cpu_layout.py
[sudo] password for root:
==
Core and Socket Information (as reported by '/sys/devices/system/cpu')
==

cores =  [0, 1, 2, 3]
sockets =  [0, 1]

   Socket 0Socket 1
   
Core 0 [0] [4]
Core 1 [1] [5]
Core 2 [2] [6]
Core 3 [3] [7]



I have compiled the application using Eclipse IDE (g++) under an OpenSuse 42.3 
Leap. Everything seemed to compile well and vfio-pci driver could be loaded on 
two NICs.

So everything seems to be OK but I am totally stuck on this EAL initialization 
problem.


I would appreciate it if some expert could shed a light on my problem.


Thanks a lot!!





Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, 
contiene información de carácter confidencial exclusivamente dirigida a su 
destinatario o destinatarios. Si no es vd. el destinatario indicado, queda 
notificado que la lectura, utilización, divulgación y/o copia sin autorización 
está prohibida en virtud de la legislación vigente. En el caso de haber 
recibido este correo electrónico por error, se ruega notificar inmediatamente 
esta circunstancia mediante reenvío a la dirección electrónica del remitente.
Evite imprimir este mensaje si no es estrictamente necesario.

This email and any file attached to it (when applicable) contain(s) 
confidential information that is exclusively addressed to its recipient(s). If 
you are not the indicated recipient, you are informed that reading, using, 
disseminating and/or copying it without authorisation is forbidden in 
accordance with the legislation in effect. If you have received this email by 
mistake, please immediately notify the sender of the situation by resending it 
to their email address.
Avoid printing this message if it is not absolutely necessary.

Re: [dpdk-dev] [PATCH] examples/ip_pipeline: fix timer_period unit

[Thomas Monjalon]

> > The timer_period option specified by users via config file should have unit 
> > of
> > 1 millisecond. However timer_period is internally converted to unit of 10
> > millisecond.
> > 
> > Fixes: 4e14069328fc ("examples/ip_pipeline: measure CPU utilization")

Cc: sta...@dpdk.org

> > Signed-off-by: Bao-Long Tran 
> 
> Reviewed-by: Jasvinder Singh 

Applied, thanks

Re: [dpdk-dev] [PATCH v2] eventdev: fix unchecked return in default Rx adapter conf cb

[Jerin Jacob]

-Original Message-
> Date: Sun, 4 Feb 2018 23:48:31 +0530
> From: Nikhil Rao 
> To: dev@dpdk.org
> CC: nikhil@intel.com, vipin.vargh...@intel.com,
>  deepak.k.j...@intel.com, jerin.ja...@caviumnetworks.com
> Subject: [PATCH v2] eventdev: fix unchecked return in default Rx adapter
>  conf cb
> X-Mailer: git-send-email 2.7.4
> 
> The default adapter configuration callback is invoked when a Rx
> queue is added to the adapter and the adapter detects that a SW
> service is needed. The adapter needs to re-configure the device
> with an additional port and to do do, it needs to stop the
> device and restart it after it is done reconfiguring it. This
> patch adds code to check the return code of
> rte_event_dev_start() for both when the reconfiguration fails
> and when it succeeds and introduces a new error code (-EIO)
> for the first case.
> 
> Fixes: 9c38b704d280 ("eventdev: add eth Rx adapter implementation")
> Coverity issue: 257000
> 
> Signed-off-by: Nikhil Rao 

Cc: sta...@dpdk.org
Acked-by: Jerin Jacob 

Re: [dpdk-dev] [PATCH v2] eventdev: fix unchecked return in default Rx adapter conf cb

[Thomas Monjalon]

> > The default adapter configuration callback is invoked when a Rx
> > queue is added to the adapter and the adapter detects that a SW
> > service is needed. The adapter needs to re-configure the device
> > with an additional port and to do do, it needs to stop the
> > device and restart it after it is done reconfiguring it. This
> > patch adds code to check the return code of
> > rte_event_dev_start() for both when the reconfiguration fails
> > and when it succeeds and introduces a new error code (-EIO)
> > for the first case.
> > 
> > Fixes: 9c38b704d280 ("eventdev: add eth Rx adapter implementation")
> > Coverity issue: 257000
> > 
> > Signed-off-by: Nikhil Rao 
> 
> Cc: sta...@dpdk.org
> Acked-by: Jerin Jacob 

Applied, thanks

Re: [dpdk-dev] [PATCH] doc: remove UTF-8 BOM from programmer's guide

[Thomas Monjalon]

> > Fixes: 55694b2a9f64 ("doc: add membership documentation")
> > Cc: yipeng1.w...@intel.com
> > Signed-off-by: Anatoly Burakov 
> 
> Acked-by: John McNamara 

Applied, thanks

Re: [dpdk-dev] [PATCH] doc: add info on hyperthreading to power library

[Thomas Monjalon]

06/02/2018 14:27, Kovacevic, Marko:
> > Signed-off-by: David Hunt 
> > ---
> >  doc/guides/prog_guide/power_man.rst | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/doc/guides/prog_guide/power_man.rst
> > b/doc/guides/prog_guide/power_man.rst
> 
> <...>
> 
> Acked-by: Marko Kovacevic 

Applied, thanks

Re: [dpdk-dev] [PATCH v3] net/virtio-user: fix unchecked return value

[Thomas Monjalon]

14/11/2017 11:39, SebastianX Basierski:
> Report error message if clearing O_NONBLOCK flag will fail,
> then return from function.
> 
> Coverity issue: 143439
> 
> Fixes: ef53b6030039 ("net/virtio-user: support LSC")
> Cc: jianfeng@intel.com
> Cc: y...@fridaylinux.org
> cc: dev@dpdk.org
> 
> Signed-off-by: SebastianX Basierski 
> Acked-by: Jianfeng Tan 
> Acked-by: Maxime Coquelin 

I don't know why this patch was forgotten in the virtio tree.

Applied, thanks

Re: [dpdk-dev] [PATCH v2] net/bonding: fix link status check

[Thomas Monjalon]

17/01/2018 17:02, Ferruh Yigit:
> On 11/29/2017 3:42 PM, Tomasz Kulasek wrote:
> > Some devices needs more time to initialize and bring interface up. When
> > link is down the link properties are not valid, e.g. link_speed is
> > reported as 0 and this is not a valid speed for slave as well as for whole
> > bonding.
> > 
> > During NIC (and bonding) initialization there's concurrency between
> > updating link status and adding slave to the bonding.
> > 
> > This patch:
> > 
> >  - adds delay before configuring bonding (if link is down) to be sure that
> >link status of new slave is valid,
> >  - propagates information about link status from first slave with link up
> >instead of first slave at all, to be sure that link speed is valid.
> > 
> > Fixes: 6abd94d72ab5 ("net/bonding: fix check slaves link properties")
> > Signed-off-by: Tomasz Kulasek 
> > ---
> > v2 changes:
> >  - Checkpatch warnings,
> >  - Improved code style
> Hi Declan,
> 
> Any comment on this patch?

Any news?

Re: [dpdk-dev] Q: uio_generic_pci

[Stephen Hemminger]

On Tue, 6 Feb 2018 12:57:15 +0200
Ran Shalit  wrote:

> Hello,
> 
> I would please like to ask about uio_generic_pci :
> 
> 1. how to set irq from userspace.

No. that is not generally possible.
It is expected that the IRQ will come from the hardware device.
On some hardware it is possible to poke a register and cause an interrupt.

> Is there anything similar to
> echo "3" > /sys/bus/pci/drivers/uio_pci_generic/irq
> in all documentation which talk about it, it is not mentioned (or I
> don't find it):
> https://github.com/rumpkernel/wiki/wiki/Howto:-Accessing-PCI-devices-from-userspace
> http://www.hep.by/gnu/kernel/uio-howto/uio_pci_generic.html
> 
> 2. Is there a way to use dma from userspace with this driver ?

This driver does not provide mappings of the PCI memory regions
so DMA is not possible. Use VFIO-pci or igb_uio instead.

Re: [dpdk-dev] [PATCH] examples/ptpclient: fix Tx configuration

[Thomas Monjalon]

01/02/2018 17:42, Pablo de Lara:
> The PTP Client application requires IEEE1588 to be supported
> by the network driver used, which needs full Tx data path
> to be used.
> 
> Fixes: b960219b0d83 ("examples/ptpclient: convert to new ethdev offloads API")
> 
> Signed-off-by: Pablo de Lara 

Applied, thanks

Re: [dpdk-dev] EAL reports "ot enough memory available on socket 0!"

[Wiles, Keith]

> On Feb 6, 2018, at 12:38 PM, Huertas García, Víctor  wrote:
> 
> Hi all,
> 
> 
> This is my first post in this mailing list. I am glad to become a member of 
> this community.
> 
> 
> I am a newbie using DPDK and I have tried to compile and execute an example 
> app called "l3fwd-acl".
> 
> 
> The DPDK command is DPDK_Test -c 0xf0 -n 2 --socket-mem 64

ran this command as root or used sudo correct?

> 
> but the application tells me the following:
> 
> 
> EAL: Detected 8 lcore(s)
> EAL: Probing VFIO support...
> EAL: VFIO support initialized
> EAL: Cannot obtain physical addresses: Success. Only vfio will function.
> EAL: Not enough memory available on socket 0! Requested: 64MB, available: 0MB
> EAL: FATAL: Cannot init memory
> 
> EAL: Cannot init memory
> 
> EAL: Error - exiting with code: 1
>  Cause: Invalid EAL parameters
> 
> 
> 
> I don't know what else I can do to make this app run as I have reserved 
> hugepages as the user guide tells as well as mounted the /mnt/huge folder.
> 
> 
> cat /proc/meminfo | grep Huge
> AnonHugePages:520192 kB
> HugePages_Total:  64
> HugePages_Free:   64
> HugePages_Rsvd:0
> HugePages_Surp:0
> Hugepagesize:   2048 kB

I assume you added an entry into /etc/sysctl.conf and rebooted, just to make 
sure the huge pages are allocated early in the boot process.

I use 1G huge pages and I assume you are using 2M huge pages

vm.nr_hugepages=32  # 32x2M is 64M

I also disable randomize_va_space, which is not required for those tests.

kernel.randomize_va_space=1


> 
> 
> My machine is has this topology (only one Numa node is detected):
> 
> 
> udo usertools/cpu_layout.py
> [sudo] password for root:
> ==
> Core and Socket Information (as reported by '/sys/devices/system/cpu')
> ==
> 
> cores =  [0, 1, 2, 3]
> sockets =  [0, 1]
> 
>   Socket 0Socket 1
>   
> Core 0 [0] [4]
> Core 1 [1] [5]
> Core 2 [2] [6]
> Core 3 [3] [7]

The CPU layout shows two sockets and normally that means 2 numa node.

I would change the command above —-socket-mem 32,32  (note: two ‘-‘ in front) 
this command gives 32M socket 0 and 32M to socket 1

I have seen some funny memory configs, with huge pages if you do not use 
/etc/sysctl.conf and reboot. Sometimes memory will be allocated to one socket.

I hope that helps.

> 
> 
> 
> I have compiled the application using Eclipse IDE (g++) under an OpenSuse 
> 42.3 Leap. Everything seemed to compile well and vfio-pci driver could be 
> loaded on two NICs.
> 
> So everything seems to be OK but I am totally stuck on this EAL 
> initialization problem.
> 
> 
> I would appreciate it if some expert could shed a light on my problem.
> 
> 
> Thanks a lot!!
> 
> 
> 
> 
> 
> Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, 
> contiene información de carácter confidencial exclusivamente dirigida a su 
> destinatario o destinatarios. Si no es vd. el destinatario indicado, queda 
> notificado que la lectura, utilización, divulgación y/o copia sin 
> autorización está prohibida en virtud de la legislación vigente. En el caso 
> de haber recibido este correo electrónico por error, se ruega notificar 
> inmediatamente esta circunstancia mediante reenvío a la dirección electrónica 
> del remitente.
> Evite imprimir este mensaje si no es estrictamente necesario.
> 
> This email and any file attached to it (when applicable) contain(s) 
> confidential information that is exclusively addressed to its recipient(s). 
> If you are not the indicated recipient, you are informed that reading, using, 
> disseminating and/or copying it without authorisation is forbidden in 
> accordance with the legislation in effect. If you have received this email by 
> mistake, please immediately notify the sender of the situation by resending 
> it to their email address.
> Avoid printing this message if it is not absolutely necessary.

Regards,
Keith

Re: [dpdk-dev] [PATCH v3] doc: update definition of lcore id and lcore index

[Thomas Monjalon]

> > Added examples in lcore index for better explanation on various examples,
> > Sited examples for lcore id.
> 
> Acked-by: John McNamara 

Applied, thanks

Re: [dpdk-dev] [PATCH v3] doc: add info on multiple instance SW crypto

[Thomas Monjalon]

> > Add infomration to explain applications using multiple instances of sw
> > crypto with example.
> > 
> > Signed-off-by: Vipin Varghese 
> 
> Typo: instances (which could be fixed when merging).
> 
> Also, there is no need to add sta...@dpdk.org, so I will remove it from the 
> CC list.
> 
> Apart from this:
> 
> Acked-by: Pablo de Lara 

Applied, thanks

Re: [dpdk-dev] [PATCH v2] doc: update application minimum requirement info

[Thomas Monjalon]

> > Added note section to update information for use cases working with
> > multiple crypto devices.
> > 
> > Signed-off-by: Vipin Varghese 
> 
> Acked-by: Pablo de Lara 

Applied, thanks