[dpdk-dev] [PATCH 0/2] add mlx4 release notes

[Thomas Monjalon]

2015-08-11 16:42, Adrien Mazarguil:
> Following John McNamara's changes we've noticed that mlx4 release notes were
> missing from DPDK 2.0.0. This patchset adds them retroactively and also
> provides mlx4 release notes for DPDK 2.1.0.
> 
> Adrien Mazarguil (2):
>   doc: add missing release notes for mlx4 availability in DPDK 2.0.0
>   doc: add mlx4 release notes to DPDK 2.1.0

Applied, thanks.
Some changes were needed due to previous patch from John.

[dpdk-dev] [PATCH] doc: updated release notes for r2.1

[Thomas Monjalon]

2015-08-13 13:02, Iremonger, Bernard:
> > +  Port hotplug support was added to the following PMDs:
> > +
> > +  * e1000/igb.
> > +  * ixgbe.
> > +  * i40e.
> > +  * fm10k.
> > +  * Ring.
> > +  * Bonding.
> > +  * Virtio.
> 
> ring, bonding and virtio should probably be all lowercase.

Applied with few small fixes, thanks for the big work, John

[dpdk-dev] [PATCH] test_table: initialize table parameteres

[Thomas Monjalon]

2015-08-17 17:58, Pablo de Lara:
> In table_autotest, the structures containing the parameters
> to create the tables were not initialized, and therefore,
> some checks could fail and so the unit test.
> 
> Also, due to this initialization, one of the tests that was
> checking if the table was improperly initialized has been
> removed, as it is not needed anymore (duplicated)
> 
> Signed-off-by: Pablo de Lara 

Applied, thanks

[dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.

[Singh, Jasvinder]

Hi,

> -Original Message-
> From: Yeddula, Avinash [mailto:ayeddula at ciena.com]
> Sent: Monday, August 17, 2015 5:35 PM
> To: Singh, Jasvinder; Richardson, Bruce
> Cc: dev at dpdk.org; Bly, Mike
> Subject: RE: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.
> 
> + Mike ( My team mate)
> Hi Jasvinder, It's not a bidirectional packet flow. The pipeline looks 
> something
> like this.
> 
> Ingress port-Table 1 Table-2 - Mac_Table - Table4  Egress
> port.
> 
> Before the frame goes reaches table 4, we do 2 lookups at the mac table.
> 1. src lookup ( To learn the MAC on the bridge) 2. dst lookup ( Flooding if 
> dst
> MAC look up fails else Unicast/forward if dst lookup success).
> 
> Here are the keys we are using.
> Src lookup key  -  Src MAC (src MAC in the frame) + Bridge ID ( Bridge on
> which it arrived).
> Dst lookup key  - Dst MAC (dst MAC in the frame) + Bridge ID ( Bridge on
> which it arrived)
> 

There is as such no mechanism to support double lookup on the same table for 
the packet. However, alternative approach could be-first perform 
destination lookup and  invoke action handler ( in both table hit & miss case). 
In action handler, Src MAC + bridge ID key can be added to the table 
(rte_pipeline_table_entry_add) .  If a new entry is successfully added to the 
hash for the specified key, or there is already an entry in the hash for the 
specified key, then the position of the entry is returned. In this way, table 
entries will be updated with incoming packets.


> Thanks
> -Avinash
> 
> -Original Message-
> From: Singh, Jasvinder [mailto:jasvinder.singh at intel.com]
> Sent: Monday, August 17, 2015 7:00 AM
> To: Richardson, Bruce; Yeddula, Avinash
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.
> 
> 
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> > Sent: Friday, August 14, 2015 10:25 AM
> > To: Yeddula, Avinash
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.
> >
> > On Thu, Aug 13, 2015 at 05:37:21PM -0400, Yeddula, Avinash wrote:
> > > Any comments on this question ?
> > >
> > > Thanks
> > > -Avinash
> > >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yeddula,
> > > Avinash
> > > Sent: Wednesday, August 12, 2015 3:04 PM
> > > To: dev at dpdk.org
> > > Subject: [dpdk-dev] Lookup mechanim in DPDK HASH table.
> > >
> > > Hello All,
> > >
> > > I'm using DPDK extendable hash tables. This question is with respect
> > > to the
> > lookup aspect of the hash table.
> > > I see that there is just one "t->key_offset" that is pre-defined for
> > > the hash
> > table. I also understand that the frame needs to carry the "lookup_key
> > / keys" in the meta data.
> > >
> > > Here is my question:  How to support more than one lookup with
> > > different
> > keys on the same frame on the same table.
> > > Use case: Src mac  lookup and dst mac lookup on the same mac table.
> > >
> > > Thanks
> > > -Avinash
> >
> > Just to confirm: this is using the extensible bucket hash in the
> > rte_table library of packet framework, rather than the standalone
> > rte_hash library, right?
> >
> > /Bruce
> 
> Could you share detail on the two different keys used for lookups. In case if
> you are considering bidirectional packet flow between the source and
> destination, symmetric hash can be used-
> http://www.ndsl.kaist.edu/~kyoungsoo/papers/TR-symRSS.pdf
> 
> Jasvinder

[dpdk-dev] [PATCH 1/1] test_table: fixed failing unit tests checking offset

[Thomas Monjalon]

> > In commit: 1129992baa61d72c5 checking for offset alignment was removed.
> > Unit tests wasn't updated to reflect that change. This patch changes
> > checks with unaligned offsets to make tests pass.
> > 
> > Signed-off-by: Maciej Gajdzica 
> 
> Acked-by: Daniel Mrzyglod 

Applied, thanks

[dpdk-dev] [PATCH] test_table: initialize table parameteres

[Pablo de Lara]

In table_autotest, the structures containing the parameters
to create the tables were not initialized, and therefore,
some checks could fail and so the unit test.

Also, due to this initialization, one of the tests that was
checking if the table was improperly initialized has been
removed, as it is not needed anymore (duplicated)

Signed-off-by: Pablo de Lara 
---
 app/test/test_table_tables.c | 91 ++--
 1 file changed, 55 insertions(+), 36 deletions(-)

diff --git a/app/test/test_table_tables.c b/app/test/test_table_tables.c
index 88bebf8..566964b 100644
--- a/app/test/test_table_tables.c
+++ b/app/test/test_table_tables.c
@@ -203,8 +203,11 @@ test_table_array(void)
void *entry_ptr;
int key_found;

-   /* Create */
-   struct rte_table_array_params array_params;
+   /* Initialize params and create tables */
+   struct rte_table_array_params array_params = {
+   .n_entries = 7,
+   .offset = 1
+   };

table = rte_table_array_ops.f_create(NULL, 0, 1);
if (table != NULL)
@@ -317,8 +320,12 @@ test_table_lpm(void)
int key_found;
uint32_t entry_size = 1;

-   /* Create */
-   struct rte_table_lpm_params lpm_params;
+   /* Initialize params and create tables */
+   struct rte_table_lpm_params lpm_params = {
+   .n_rules = 1 << 24,
+   .entry_unique_size = entry_size,
+   .offset = 1
+   };

table = rte_table_lpm_ops.f_create(NULL, 0, entry_size);
if (table != NULL)
@@ -331,39 +338,33 @@ test_table_lpm(void)
return -2;

lpm_params.n_rules = 1 << 24;
-   lpm_params.offset = 1;
-
-   table = rte_table_lpm_ops.f_create(_params, 0, entry_size);
-   if (table != NULL)
-   return -3;
-
lpm_params.offset = 32;
lpm_params.entry_unique_size = 0;

table = rte_table_lpm_ops.f_create(_params, 0, entry_size);
if (table != NULL)
-   return -4;
+   return -3;

lpm_params.entry_unique_size = entry_size + 1;

table = rte_table_lpm_ops.f_create(_params, 0, entry_size);
if (table != NULL)
-   return -5;
+   return -4;

lpm_params.entry_unique_size = entry_size;

table = rte_table_lpm_ops.f_create(_params, 0, entry_size);
if (table == NULL)
-   return -6;
+   return -5;

/* Free */
status = rte_table_lpm_ops.f_free(table);
if (status < 0)
-   return -7;
+   return -6;

status = rte_table_lpm_ops.f_free(NULL);
if (status == 0)
-   return -8;
+   return -7;

/* Add */
struct rte_table_lpm_key lpm_key;
@@ -371,75 +372,75 @@ test_table_lpm(void)

table = rte_table_lpm_ops.f_create(_params, 0, 1);
if (table == NULL)
-   return -9;
+   return -8;

status = rte_table_lpm_ops.f_add(NULL, _key, , _found,
_ptr);
if (status == 0)
-   return -10;
+   return -9;

status = rte_table_lpm_ops.f_add(table, NULL, , _found,
_ptr);
if (status == 0)
-   return -11;
+   return -10;

status = rte_table_lpm_ops.f_add(table, _key, NULL, _found,
_ptr);
if (status == 0)
-   return -12;
+   return -11;

lpm_key.depth = 0;
status = rte_table_lpm_ops.f_add(table, _key, , _found,
_ptr);
if (status == 0)
-   return -13;
+   return -12;

lpm_key.depth = 33;
status = rte_table_lpm_ops.f_add(table, _key, , _found,
_ptr);
if (status == 0)
-   return -14;
+   return -13;

lpm_key.depth = 16;
status = rte_table_lpm_ops.f_add(table, _key, , _found,
_ptr);
if (status != 0)
-   return -15;
+   return -14;

/* Delete */
status = rte_table_lpm_ops.f_delete(NULL, _key, _found, NULL);
if (status == 0)
-   return -16;
+   return -15;

status = rte_table_lpm_ops.f_delete(table, NULL, _found, NULL);
if (status == 0)
-   return -17;
+   return -16;

lpm_key.depth = 0;
status = rte_table_lpm_ops.f_delete(table, _key, _found, NULL);
if (status == 0)
-   return -18;
+   return -17;

lpm_key.depth = 33;
status = rte_table_lpm_ops.f_delete(table, _key, _found, NULL);
if (status == 0)
-   return -19;
+   return -18;

lpm_key.depth = 16;
status = rte_table_lpm_ops.f_delete(table, _key, _found, NULL);
if (status != 0)
-   return -20;
+   return -19;

status = 

[dpdk-dev] [PATCH 2/2] eal: Fix compilation on C++

[Thomas Monjalon]

2015-08-17 17:29, Thomas Monjalon:
> 2015-07-03 21:51, Joongi Kim:
> >  * Forward declaration of enum in C++ requires explicit underlying
> >type definitions.
> > 
> >  * This fixes the issue at:
> >http://dpdk.org/ml/archives/dev/2015-April/017065.html
> > 
> > Signed-off-by: Joongi Kim 
> 
> Does the problem appear only with rte_hash_crc.h inclusion?
> 
> The reported errors were:
> 
> include/generic/rte_cpuflags.h:50:6:
> error: use of enum ?rte_cpu_flag_t? without previous declaration
>  enum rte_cpu_flag_t;
> 
> include/generic/rte_cpuflags.h:55:6:
> error: use of enum ?cpu_register_t? without previous declaration
>  enum cpu_register_t;
> 
> >  lib/librte_eal/common/include/arch/x86/rte_cpuflags.h |  4 ++--
> >  lib/librte_eal/common/include/generic/rte_cpuflags.h  | 12 ++--
> 
> Do we need to update lib/librte_eal/common/include/arch/ppc_64/rte_cpuflags.h
> and lib/librte_eal/common/include/arch/tile/rte_cpuflags.h as well?
> 
> Thanks

Applied with same fixes for ppc and tile, thanks

[dpdk-dev] [PATCH] mbuf & mempool: explicit typecast on function return

[Thomas Monjalon]

2015-08-17 10:14, Olivier MATZ:
> Hi Sergey,
> 
> On 08/12/2015 11:11 AM, Sergey Balabanov wrote:
> > When DPDK is being compiled in C++ project using g++ then
> > 'invalid conversion from' error appears. Added explicit
> > typecast on function return to get rid of the error.
> > 
> > Signed-off-by: Sergey Balabanov 
> 
> 
> Fixes: 7755baae8378 ("mbuf: silence warning on pointer arithmetic")
> Fixes: 6cf14ce4ce6c ("mempool: silence warning on pointer arithmetic")
> 
> Acked-by: Olivier Matz 

Split and applied, thanks

[dpdk-dev] [PATCH 2/2] eal: Fix compilation on C++

[Thomas Monjalon]

2015-07-03 21:51, Joongi Kim:
>  * Forward declaration of enum in C++ requires explicit underlying
>type definitions.
> 
>  * This fixes the issue at:
>http://dpdk.org/ml/archives/dev/2015-April/017065.html
> 
> Signed-off-by: Joongi Kim 

Does the problem appear only with rte_hash_crc.h inclusion?

The reported errors were:

include/generic/rte_cpuflags.h:50:6:
error: use of enum ?rte_cpu_flag_t? without previous declaration
 enum rte_cpu_flag_t;

include/generic/rte_cpuflags.h:55:6:
error: use of enum ?cpu_register_t? without previous declaration
 enum cpu_register_t;

>  lib/librte_eal/common/include/arch/x86/rte_cpuflags.h |  4 ++--
>  lib/librte_eal/common/include/generic/rte_cpuflags.h  | 12 ++--

Do we need to update lib/librte_eal/common/include/arch/ppc_64/rte_cpuflags.h
and lib/librte_eal/common/include/arch/tile/rte_cpuflags.h as well?

Thanks

[dpdk-dev] [PATCH 1/2] lib: Fix pointer arithmetic for C++

[Thomas Monjalon]

2015-07-03 21:51, Joongi Kim:
>  lib/librte_malloc/malloc_elem.h  | 4 ++--
>  lib/librte_mempool/rte_mempool.c | 2 +-

These files are not part of the API and should not be included.
No need to fix them for C++.

[dpdk-dev] [PATCH v6 4/9] ethdev: remove HW specific stats in stats structs

[Olivier MATZ]

Hi Maryam,

On 07/15/2015 03:11 PM, Maryam Tahhan wrote:
> Remove non generic stats in rte_stats_strings and mark the relevant
> fields in struct rte_eth_stats as deprecated.
> 
> Signed-off-by: Maryam Tahhan 
> ---
>  doc/guides/rel_notes/abi.rst  | 12 
>  lib/librte_ether/rte_ethdev.c |  9 -
>  lib/librte_ether/rte_ethdev.h | 30 --
>  3 files changed, 32 insertions(+), 19 deletions(-)
> 
> diff --git a/doc/guides/rel_notes/abi.rst b/doc/guides/rel_notes/abi.rst
> index 931e785..d5bf625 100644
> --- a/doc/guides/rel_notes/abi.rst
> +++ b/doc/guides/rel_notes/abi.rst
> @@ -24,3 +24,15 @@ Deprecation Notices
>  
>  * The Macros RTE_HASH_BUCKET_ENTRIES_MAX and RTE_HASH_KEY_LENGTH_MAX are
>deprecated and will be removed with version 2.2.
> +
> +* The following fields have been deprecated in rte_eth_stats:
> +  * uint64_t imissed
> +  * uint64_t ibadcrc
> +  * uint64_t ibadlen
> +  * uint64_t imcasts
> +  * uint64_t fdirmatch
> +  * uint64_t fdirmiss
> +  * uint64_t tx_pause_xon
> +  * uint64_t rx_pause_xon
> +  * uint64_t tx_pause_xoff
> +  * uint64_t rx_pause_xoff

Looking again at this patch, I'm wondering if "imissed" should
be kept instead of beeing deprecated. I think it could be useful to
differentiate ierrors from imissed, and it's not a hw-specific
statistic. What do you think?

One more comment: it seems these fields are marked as deprecated but
they are still used on other drivers (e1000, i40e, ...).

Regards,
Olivier


> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> index 7689328..c8f0e9a 100755
> --- a/lib/librte_ether/rte_ethdev.c
> +++ b/lib/librte_ether/rte_ethdev.c
> @@ -142,17 +142,8 @@ static const struct rte_eth_xstats_name_off 
> rte_stats_strings[] = {
>   {"rx_bytes", offsetof(struct rte_eth_stats, ibytes)},
>   {"tx_bytes", offsetof(struct rte_eth_stats, obytes)},
>   {"tx_errors", offsetof(struct rte_eth_stats, oerrors)},
> - {"rx_missed_errors", offsetof(struct rte_eth_stats, imissed)},
> - {"rx_crc_errors", offsetof(struct rte_eth_stats, ibadcrc)},
> - {"rx_bad_length_errors", offsetof(struct rte_eth_stats, ibadlen)},
>   {"rx_errors", offsetof(struct rte_eth_stats, ierrors)},
>   {"alloc_rx_buff_failed", offsetof(struct rte_eth_stats, rx_nombuf)},
> - {"fdir_match", offsetof(struct rte_eth_stats, fdirmatch)},
> - {"fdir_miss", offsetof(struct rte_eth_stats, fdirmiss)},
> - {"tx_flow_control_xon", offsetof(struct rte_eth_stats, tx_pause_xon)},
> - {"rx_flow_control_xon", offsetof(struct rte_eth_stats, rx_pause_xon)},
> - {"tx_flow_control_xoff", offsetof(struct rte_eth_stats, tx_pause_xoff)},
> - {"rx_flow_control_xoff", offsetof(struct rte_eth_stats, rx_pause_xoff)},
>  };
>  #define RTE_NB_STATS (sizeof(rte_stats_strings) / 
> sizeof(rte_stats_strings[0]))
>  
> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> index d76bbb3..a862027 100644
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -193,19 +193,29 @@ struct rte_eth_stats {
>   uint64_t opackets;  /**< Total number of successfully transmitted 
> packets.*/
>   uint64_t ibytes;/**< Total number of successfully received bytes. */
>   uint64_t obytes;/**< Total number of successfully transmitted 
> bytes. */
> - uint64_t imissed;   /**< Total of RX missed packets (e.g full FIFO). */
> - uint64_t ibadcrc;   /**< Total of RX packets with CRC error. */
> - uint64_t ibadlen;   /**< Total of RX packets with bad length. */
> + /**< Deprecated; Total of RX missed packets (e.g full FIFO). */
> + uint64_t imissed;
> + /**< Deprecated; Total of RX packets with CRC error. */
> + uint64_t ibadcrc;
> + /**< Deprecated; Total of RX packets with bad length. */
> + uint64_t ibadlen;
>   uint64_t ierrors;   /**< Total number of erroneous received packets. */
>   uint64_t oerrors;   /**< Total number of failed transmitted packets. */
> - uint64_t imcasts;   /**< Total number of multicast received packets. */
> + uint64_t imcasts;
> + /**< Deprecated; Total number of multicast received packets. */
>   uint64_t rx_nombuf; /**< Total number of RX mbuf allocation failures. */
> - uint64_t fdirmatch; /**< Total number of RX packets matching a filter. 
> */
> - uint64_t fdirmiss;  /**< Total number of RX packets not matching any 
> filter. */
> - uint64_t tx_pause_xon;  /**< Total nb. of XON pause frame sent. */
> - uint64_t rx_pause_xon;  /**< Total nb. of XON pause frame received. */
> - uint64_t tx_pause_xoff; /**< Total nb. of XOFF pause frame sent. */
> - uint64_t rx_pause_xoff; /**< Total nb. of XOFF pause frame received. */
> + uint64_t fdirmatch;
> + /**< Deprecated; Total number of RX packets matching a filter. */
> + uint64_t fdirmiss;
> + /**< Deprecated; Total number of RX packets not matching any filter. */
> + uint64_t 

[dpdk-dev] [PATCH 2/2] doc: announce removal of LPM memory location

[Thomas Monjalon]

2015-08-17 16:39, Thomas Monjalon:
> This field is deprecated for a long time and should be removed.
> 
> Signed-off-by: Thomas Monjalon 

Series applied

[dpdk-dev] [PATCH 0/3] announce deprecation of functions commented as deprecated

[Thomas Monjalon]

2015-08-17 00:51, Thomas Monjalon:
> As suugested by Stephen, some functions are marked as deprecated in the code
> and should now be removed.
> Let's follow the deprecation process and announce it in the release notes.
> 
> Thomas Monjalon (3):
>   doc: announce legacy 7-tuple acl rule removal
>   doc: announce removal of kni functions using port id
>   doc: announce ring PMD functions removal

Applied

[dpdk-dev] [PATCH 2/2] doc: announce removal of LPM memory location

[Thomas Monjalon]

This field is deprecated for a long time and should be removed.

Signed-off-by: Thomas Monjalon 
---
 doc/guides/rel_notes/deprecation.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index bf0ac95..da17880 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -25,6 +25,9 @@ Deprecation Notices

 * The function rte_jhash2 is deprecated and should be removed.

+* The field mem_location of the rte_lpm structure is deprecated and should be
+  removed as well as the macros RTE_LPM_HEAP and RTE_LPM_MEMZONE.
+
 * Significant ABI changes are planned for struct rte_mbuf, struct rte_kni_mbuf,
   and several ``PKT_RX_`` flags will be removed, to support unified packet type
   from release 2.1. Those changes may be enabled in the upcoming release 2.1
-- 
2.4.2

[dpdk-dev] [PATCH 1/2] doc: announce removal of jhash2 function

[Thomas Monjalon]

Fixes: 7530c9eea7d9 ("hash: rename a jhash function")

Signed-off-by: Thomas Monjalon 
---
 doc/guides/rel_notes/deprecation.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 46a88ca..bf0ac95 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -23,6 +23,8 @@ Deprecation Notices
 * The Macros RTE_HASH_BUCKET_ENTRIES_MAX and RTE_HASH_KEY_LENGTH_MAX are
   deprecated and will be removed with version 2.2.

+* The function rte_jhash2 is deprecated and should be removed.
+
 * Significant ABI changes are planned for struct rte_mbuf, struct rte_kni_mbuf,
   and several ``PKT_RX_`` flags will be removed, to support unified packet type
   from release 2.1. Those changes may be enabled in the upcoming release 2.1
-- 
2.4.2

[dpdk-dev] [PATCH 1/1] table_test: renamed test_table_ACL to lowercase

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Maciej Gajdzica
> Sent: Thursday, August 13, 2015 11:33 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 1/1] table_test: renamed test_table_ACL to
> lowercase
> 
> Renamed function name to comply with coding standard.
> 
> Signed-off-by: Maciej Gajdzica 

Acked-by: Pablo de Lara 

[dpdk-dev] [ovs-dev] Status of Open vSwitch with DPDK

[Mark D. Gray]

On 08/15/15 08:16, Flavio Leitner wrote:
> On Fri, Aug 14, 2015 at 04:04:40PM +, Gray, Mark D wrote:
>> Hi Daniele,
>>
>> Thanks for starting this conversation. It is a good list :) I have 
>> crossed-posted this
>> to dpdk.org as I feel that some of the points could be interesting to that 
>> community
>> as they are related to how DPDK is used.
>>
>> How do "users" of OVS with DPDK feel about this list? Does anyone disagree or
>> does anyone have any additions? What are your experiences?
>>
>>>
>>> There has been some discussion lately about the status of the Open vSwitch
>>> port to DPDK.  While part of the code has been tested for quite some time,
>>> I think we can agree that there are a few rough spots that prevent it from
>>> being easily deployed and used.
>>>
>>> I was hoping to get some feedback from the community about those rough
>>> spots,
>>> i.e. areas where OVS+DPDK can/needs to improve to become more
>>> "production
>>> ready" and user-friendly.
>>>
>>> - PMD threads and queues management: the code has shown several bugs
>>> and
>>> the
>>>netdev interfaces don't seem up to the job anymore.
>>
>> You had a few ideas about how to refactor this before but I was concerned
>> about the effect it would have on throughput. I can't find the thread.
>>
>> Do you have some further ideas about how to achieve this?
>
> I miss the fact that we can't tell which queue can go to each PMD and
> also that all devices must have the same number of rx queues. I agree
> that there are other issues, but it seems the kind of configuration
> knobs I am looking for might not be the end goal since what has been
> said is to look for a more automated way.  Having said so, I also
> would like to hear if you have further ideas about how to archive that.
>
>
>>>There's a lot of margin of improvement: we could factor out the code from
>>>dpif-netdev, add configuration parameters for advanced users, and figure
>>> out
>>>a way to add unit tests.
>>>
>>
>> I think this is a general issue with both the kernel datapath (and netdevs)
>> and the userspace datapath. There isn't much unit testing (or testing) 
>> outside
>> of the slow path.
>
> Maybe we could exercise the interfaces using pcap pmd.
>
>

We had a similar idea. Using this, it would be possible to test the 
entire datapath or netdev for functionality! I don?t think there is an 
equivalent for the kernel datapath?

>>>Related to this, the system should be as fast as possible out-of-the-box,
>>>without requiring too much tuning.
>>
>> This is a good point. I think the kernel datapath has a similar issue. You 
>> can
>> get a certain level of performance without compiling with -Ofast or
>> pinning threads but you will (even with the kernel datapath) get better
>> performance if you pin threads (and possibly compile differently). I guess
>> it is more visible with the dpdk datapath as performance is one of the key
>> values. It is also more detrimental to the performance if you don't set it
>> up correctly.
>
> Not only that, you need to consider how the resources will be
> distributed upfront so that you don't run out of hugepages, perhaps
> isolate PMD CPUs from the Linux scheduler, etc.  So, I think a more
> realistic goal would be: the system should require minimal/none tuning
> to run with acceptable performance.
>

How do you define "acceptable" performance :)?

>
>> Perhaps we could provide scripts to help do this?
>
> Or profiles (if that isn't included in your scripts definition)
>

Maybe we should define profiles like "performance", "minimum cores", etc

>
>> I think this is also interesting to the DPDK community. There is
>> knowledge required when running DPDK enabled apps to
>> get good performance: core pinning is one thing that comes to mind.
>>
>>>
>>> - Userspace tunneling: while the code has been there for quite some time it
>>>hasn't received the level of testing that the Linux kernel datapath
>>> tunneling
>>>has.
>>>
>>
>> Again, there is a lack of test infrastructure in general for OVS. vsperf is 
>> a good
>> start, and it would be great to see more people use and contribute to it!
>
> Yes.
>
>
>>> - Documentation: other than a step by step tutorial,  it cannot be said
>>> that
>>>DPDK is a first class citizen in the OVS documentation.  Manpages could
>>> be
>>>improved.
>>
>> Easily done. The INSTALL guide is pretty good but the structure could be 
>> better.
>> There is also a lack of manpages. Good point.
>
> Yup.
>
>
>>> - Vhost: the code has not received the level of testing of the kernel
>>> vhost.
>>>Another doubt shared by some developers is whether we should keep
>>>vhost-cuse, given its relatively low ease of use and the overlapping with
>>>the far more standard vhost-user.
>>
>> vhost-cuse is required for older versions of qemu. I'm aware of some 
>> companies
>> using it as they are restricted to an older version of qemu. I think it is 
>> deprecated
>> at the moment? Is there 

[dpdk-dev] [PATCH] mbuf & mempool: explicit typecast on function return

[Olivier MATZ]

Hi Joongi,

On 08/17/2015 02:28 PM, Joongi Kim wrote:
> I already have fixed this issue
> at http://dpdk.org/dev/patchwork/patch/6068/ .
> There is another issue related to "underlying type" for enum
> declarations http://dpdk.org/dev/patchwork/patch/6067/, for C++11 compilers.
> 
> In the second patch I missed updating headers for architectures other
> than x86,
> so it needs to be updated before applying to the master branch.
> 
> It would be great for me to have this fixed on the master branch,
> as I am manually applying above patches whenever I pull the latest codes.
> 

+CC Thomas.

Sorry, I missed your previous patches. I think it would indeed be
helpful to have them included before the release to allow compilation
of C++ programs.

I'm wondering if we should add a C++ example in dpdk/examples: people
would see the problem before commiting, or if they miss it, I know some
people are doing automatic compilation tests every day.

Regards,
Olivier



> Regards,
> Joongi
> 
> 2015? 8? 17? (?) ?? 5:15, Olivier MATZ  >?? ??:
> 
> Hi Sergey,
> 
> On 08/12/2015 11:11 AM, Sergey Balabanov wrote:
> > When DPDK is being compiled in C++ project using g++ then
> > 'invalid conversion from' error appears. Added explicit
> > typecast on function return to get rid of the error.
> >
> > Signed-off-by: Sergey Balabanov  >
> 
> 
> Fixes: 7755baae8378 ("mbuf: silence warning on pointer arithmetic")
> Fixes: 6cf14ce4ce6c ("mempool: silence warning on pointer arithmetic")
> 
> Acked-by: Olivier Matz  >
> 
> Thanks
> 

[dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.

[Bly, Mike]

Venkat,

While that does ?solve? the issue, I find the approach of tying the 
meta-data-key-offset to a specific table highly limiting. IMO, it would be far 
more interesting to provide the offset as part of the lookup call itself. For 
example, I might have an optimized code sequence that generates a series of 
?keys? in meta data, which then triggers a series of lookups, where one or more 
lookups are different keys, but in the same table(s). As it stands now, the 
proposed solution requires an iterative updating of the same key location in 
meta data between lookups. This also prevents multiple tables from sharing the 
same meta data ?space? for overlapping key values, in that I am forced to 
iteratively change/reload said key data.

Another thing to consider would be the ability to provide offset/size per 
sub-field for a given key. The MAC table in question is a great example. I?ll 
add IP addresses here as well to make it a bit more interesting:

Meta-data = DA | (SA << 6*8) | (BRIDGE_ID << 12*8) | (DIP << 14*8) | (SIP << 
20*8)

If we were allowed to use per field offset/size values, I could use the above 
meta-data for two MAC lookups and two FIB/RIB lookups and perhaps a combo L2/L3 
ACL lookup. However, the current limitation requires me to modify the 
?meta-data? before each individual lookup, which means my frame parsing is 
iterative and NOT necessarily optimized.

-MikeB

From: Venkateswara Rao Thummala [mailto:venkat.thummala.1...@gmail.com]
Sent: Monday, August 17, 2015 11:06 AM
To: Yeddula, Avinash
Cc: Singh, Jasvinder; Richardson, Bruce; dev at dpdk.org; Bly, Mike
Subject: Re: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.

Hi Avinash,
I think, you can use the same table by just updating the packet meta data based 
on the Look UP.
In the first lookup, you can populate the meta data [key offset] with the 
source MAC and in the second lookup, you can populate the same meta data with 
the destination lookup. I think this should work.
Thanks
Venkat
OneHop Networks

On 17 August 2015 at 22:05, Yeddula, Avinash mailto:ayeddula at ciena.com>> wrote:
+ Mike ( My team mate)
Hi Jasvinder, It's not a bidirectional packet flow. The pipeline looks 
something like this.

Ingress port-Table 1 Table-2 - Mac_Table - Table4  Egress 
port.

Before the frame goes reaches table 4, we do 2 lookups at the mac table.
1. src lookup ( To learn the MAC on the bridge)
2. dst lookup ( Flooding if dst MAC look up fails else Unicast/forward if dst 
lookup success).

Here are the keys we are using.
Src lookup key  -  Src MAC (src MAC in the frame) + Bridge ID ( Bridge on which 
it arrived).
Dst lookup key  - Dst MAC (dst MAC in the frame) + Bridge ID ( Bridge on which 
it arrived)


Thanks
-Avinash

-Original Message-
From: Singh, Jasvinder [mailto:jasvinder.singh at 
intel.com]
Sent: Monday, August 17, 2015 7:00 AM
To: Richardson, Bruce; Yeddula, Avinash
Cc: dev at dpdk.org
Subject: RE: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.



> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On 
> Behalf Of Bruce Richardson
> Sent: Friday, August 14, 2015 10:25 AM
> To: Yeddula, Avinash
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.
>
> On Thu, Aug 13, 2015 at 05:37:21PM -0400, Yeddula, Avinash wrote:
> > Any comments on this question ?
> >
> > Thanks
> > -Avinash
> >
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] 
> > On Behalf Of Yeddula,
> > Avinash
> > Sent: Wednesday, August 12, 2015 3:04 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] Lookup mechanim in DPDK HASH table.
> >
> > Hello All,
> >
> > I'm using DPDK extendable hash tables. This question is with respect
> > to the
> lookup aspect of the hash table.
> > I see that there is just one "t->key_offset" that is pre-defined for
> > the hash
> table. I also understand that the frame needs to carry the "lookup_key
> / keys" in the meta data.
> >
> > Here is my question:  How to support more than one lookup with
> > different
> keys on the same frame on the same table.
> > Use case: Src mac  lookup and dst mac lookup on the same mac table.
> >
> > Thanks
> > -Avinash
>
> Just to confirm: this is using the extensible bucket hash in the
> rte_table library of packet framework, rather than the standalone
> rte_hash library, right?
>
> /Bruce

Could you share detail on the two different keys used for lookups. In case if 
you are considering bidirectional packet flow between the source and 
destination, symmetric hash can be used-  
http://www.ndsl.kaist.edu/~kyoungsoo/papers/TR-symRSS.pdf

Jasvinder

[dpdk-dev] ieee1588fwd.c implementation

[Mcnamara, John]

> -Original Message-
> From: Stefan Binna [mailto:stefan.binna at salzburgresearch.at]
> Sent: Monday, August 17, 2015 1:48 AM
> To: Mcnamara, John; dev at dpdk.org
> Subject: Re: [dpdk-dev] ieee1588fwd.c implementation
> 
> Hi,
> 
> I'm using the Intel NIC 82547L.
> Furthermore I'm using DPDK-2.0.0, the last stable download from the
> official homepage.
> 
> Is there any method to "measure" the time the NIC takes to process the
> packet from the input port (e.g. port 0) to the output port (port 1)?
> Should be around 8 to 40 microseconds depending on the packet size?


Hi Stefan,

The RX/TX callbacks sample application looks closer to what you are looking for:

"The RX/TX Callbacks sample application is a packet forwarding application
that demonstrates the use of user defined callbacks on received and transmitted
packets. The application performs a simple latency check, using callbacks,
to determine the time packets spend within the application".

http://dpdk.org/doc/guides/sample_app_ug/rxtx_callbacks.html

http://dpdk.org/browse/dpdk/tree/examples/rxtx_callbacks/main.c

John.
-- 

[dpdk-dev] [PATCH 1/1] test_table: added ACL table test to the list

[Gajdzica, MaciejX T]

> -Original Message-
> From: Gajdzica, MaciejX T
> Sent: Wednesday, August 12, 2015 2:41 PM
> To: dev at dpdk.org
> Cc: Gajdzica, MaciejX T
> Subject: [PATCH 1/1] test_table: added ACL table test to the list
> 
> test_table_ACL wasn't invoked when running table_autotest. Added this test to
> table_tests array to make it run with other table tests.
> 
> Signed-off-by: Maciej Gajdzica 

NACK - In current code ACL table tests are executed at the end after table 
tests and table tests combined, so this patch is not needed.

[dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.

[Singh, Jasvinder]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Friday, August 14, 2015 10:25 AM
> To: Yeddula, Avinash
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.
> 
> On Thu, Aug 13, 2015 at 05:37:21PM -0400, Yeddula, Avinash wrote:
> > Any comments on this question ?
> >
> > Thanks
> > -Avinash
> >
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yeddula, Avinash
> > Sent: Wednesday, August 12, 2015 3:04 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] Lookup mechanim in DPDK HASH table.
> >
> > Hello All,
> >
> > I'm using DPDK extendable hash tables. This question is with respect to the
> lookup aspect of the hash table.
> > I see that there is just one "t->key_offset" that is pre-defined for the 
> > hash
> table. I also understand that the frame needs to carry the "lookup_key /
> keys" in the meta data.
> >
> > Here is my question:  How to support more than one lookup with different
> keys on the same frame on the same table.
> > Use case: Src mac  lookup and dst mac lookup on the same mac table.
> >
> > Thanks
> > -Avinash
> 
> Just to confirm: this is using the extensible bucket hash in the rte_table
> library of packet framework, rather than the standalone rte_hash library,
> right?
> 
> /Bruce

Could you share detail on the two different keys used for lookups. In case if 
you are considering bidirectional packet flow between the source and 
destination, symmetric hash can be used-  
http://www.ndsl.kaist.edu/~kyoungsoo/papers/TR-symRSS.pdf 

Jasvinder

[dpdk-dev] [PATCH] mempool: fix the inverted pg_num check on create

[Dan Aloni]

On Mon, Aug 17, 2015 at 10:55:35AM +0200, Olivier MATZ wrote:
> On 08/16/2015 09:08 PM, Dan Aloni wrote:
[..]
> > /* Check that pg_num and pg_shift parameters are valid. */
> > -   if (pg_num < RTE_DIM(mp->elt_pa) || pg_shift > MEMPOOL_PG_SHIFT_MAX) {
> > +   if (pg_num > RTE_DIM(mp->elt_pa) || pg_shift > MEMPOOL_PG_SHIFT_MAX) {
> > rte_errno = EINVAL;
> > return NULL;

> 
> From what I see, RTE_DIM(mp->elt_pa) is always 1:
> 
>   #define MEMPOOL_PG_NUM_DEFAULT  1
>   struct rte_mempool {
>   ...
>   phys_addr_t elt_pa[MEMPOOL_PG_NUM_DEFAULT];
>   }  __rte_cache_aligned;
> 
> From rte_mempool_xmem_create() documentation, pg_num gives the size of
> the paddr array, which is allocated by the caller. So I think there is
> no issue here.

You're right, I missed on the fact that mempool takes pg_num as its
run-time determined size of the array for both its dynamically allocated
copy and the caller's provided array.

The MEMPOOL_PG_NUM_DEFAULT macro is was a bit distracting in this. I
wanted to provide pg_num > 1 and it wasn't clear on whether to modify
the macro, or simply call the function :). So, never mind the patch.

-- 
Dan Aloni

[dpdk-dev] [PATCH v2] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

[Vlad Zolotarov]

According to 82599 and x540 HW specifications RS bit *must* be
set in the last descriptor of *every* packet.

This patch fixes the Tx hang we were constantly hitting with a
seastar-based application on x540 NIC.

Signed-off-by: Vlad Zolotarov 
---
New in v2:
   - ixgbevf: ixgbevf_dev_info_get(): return tx_rs_thresh=1 in
  default tx configuration for all devices since VFs
  are available only on devices newer than 82598.

Signed-off-by: Vlad Zolotarov 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 19 ++-
 drivers/net/ixgbe/ixgbe_rxtx.c   | 23 ++-
 2 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index b8ee1e9..fd9cb77 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2414,6 +2414,15 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
.txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
ETH_TXQ_FLAGS_NOOFFLOADS,
};
+
+   /*
+* According to 82599 and x540 specifications RS bit *must* be set on 
the
+* last descriptor of *every* packet. Therefore we will not allow the
+* tx_rs_thresh above 1 for all NICs newer than 82598.
+*/
+   if (hw->mac.type > ixgbe_mac_82598EB)
+   dev_info->default_txconf.tx_rs_thresh = 1;
+
dev_info->hash_key_size = IXGBE_HKEY_MAX_INDEX * sizeof(uint32_t);
dev_info->reta_size = ETH_RSS_RETA_SIZE_128;
dev_info->flow_type_rss_offloads = IXGBE_RSS_OFFLOAD_ALL;
@@ -2463,7 +2472,15 @@ ixgbevf_dev_info_get(struct rte_eth_dev *dev,
.wthresh = IXGBE_DEFAULT_TX_WTHRESH,
},
.tx_free_thresh = IXGBE_DEFAULT_TX_FREE_THRESH,
-   .tx_rs_thresh = IXGBE_DEFAULT_TX_RSBIT_THRESH,
+   /*
+* According to 82599 and x540 specifications RS bit *must* be
+* set on the last descriptor of *every* packet. Therefore we
+* will not allow the tx_rs_thresh above 1 for all NICs newer
+* than 82598. Since VFs are available only on devices starting
+* from 82599, tx_rs_thresh should be set to 1 for ALL VF
+* devices.
+*/
+   .tx_rs_thresh = 1,
.txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
ETH_TXQ_FLAGS_NOOFFLOADS,
};
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index 91023b9..8dbdffc 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -2085,11 +2085,19 @@ ixgbe_dev_tx_queue_setup(struct rte_eth_dev *dev,
struct ixgbe_tx_queue *txq;
struct ixgbe_hw *hw;
uint16_t tx_rs_thresh, tx_free_thresh;
+   bool rs_deferring_allowed;

PMD_INIT_FUNC_TRACE();
hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);

/*
+* According to 82599 and x540 specifications RS bit *must* be set on 
the
+* last descriptor of *every* packet. Therefore we will not allow the
+* tx_rs_thresh above 1 for all NICs newer than 82598.
+*/
+   rs_deferring_allowed = (hw->mac.type <= ixgbe_mac_82598EB);
+
+   /*
 * Validate number of transmit descriptors.
 * It must not exceed hardware maximum, and must be multiple
 * of IXGBE_ALIGN.
@@ -2110,6 +2118,8 @@ ixgbe_dev_tx_queue_setup(struct rte_eth_dev *dev,
 * to transmit a packet is greater than the number of free TX
 * descriptors.
 * The following constraints must be satisfied:
+*  tx_rs_thresh must be less than 2 for NICs for which RS deferring is
+*  forbidden (all but 82598).
 *  tx_rs_thresh must be greater than 0.
 *  tx_rs_thresh must be less than the size of the ring minus 2.
 *  tx_rs_thresh must be less than or equal to tx_free_thresh.
@@ -2121,9 +2131,20 @@ ixgbe_dev_tx_queue_setup(struct rte_eth_dev *dev,
 * When set to zero use default values.
 */
tx_rs_thresh = (uint16_t)((tx_conf->tx_rs_thresh) ?
-   tx_conf->tx_rs_thresh : DEFAULT_TX_RS_THRESH);
+   tx_conf->tx_rs_thresh :
+   (rs_deferring_allowed ? DEFAULT_TX_RS_THRESH : 1));
tx_free_thresh = (uint16_t)((tx_conf->tx_free_thresh) ?
tx_conf->tx_free_thresh : DEFAULT_TX_FREE_THRESH);
+
+   if (!rs_deferring_allowed && tx_rs_thresh > 1) {
+   PMD_INIT_LOG(ERR, "tx_rs_thresh must be less than 2 since RS "
+ "must be set for every packet for this HW. "
+ "(tx_rs_thresh=%u port=%d queue=%d)",
+(unsigned int)tx_rs_thresh,
+(int)dev->data->port_id, (int)queue_idx);
+   return 

[dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.

[Yeddula, Avinash]

+ Mike ( My team mate)
Hi Jasvinder, It's not a bidirectional packet flow. The pipeline looks 
something like this.

Ingress port-Table 1 Table-2 - Mac_Table - Table4  Egress 
port.

Before the frame goes reaches table 4, we do 2 lookups at the mac table.
1. src lookup ( To learn the MAC on the bridge)
2. dst lookup ( Flooding if dst MAC look up fails else Unicast/forward if dst 
lookup success).

Here are the keys we are using.
Src lookup key  -  Src MAC (src MAC in the frame) + Bridge ID ( Bridge on which 
it arrived).
Dst lookup key  - Dst MAC (dst MAC in the frame) + Bridge ID ( Bridge on which 
it arrived)


Thanks
-Avinash

-Original Message-
From: Singh, Jasvinder [mailto:jasvinder.si...@intel.com] 
Sent: Monday, August 17, 2015 7:00 AM
To: Richardson, Bruce; Yeddula, Avinash
Cc: dev at dpdk.org
Subject: RE: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.



> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Friday, August 14, 2015 10:25 AM
> To: Yeddula, Avinash
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [ 2nd try ] Lookup mechanim in DPDK HASH table.
> 
> On Thu, Aug 13, 2015 at 05:37:21PM -0400, Yeddula, Avinash wrote:
> > Any comments on this question ?
> >
> > Thanks
> > -Avinash
> >
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yeddula, 
> > Avinash
> > Sent: Wednesday, August 12, 2015 3:04 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] Lookup mechanim in DPDK HASH table.
> >
> > Hello All,
> >
> > I'm using DPDK extendable hash tables. This question is with respect 
> > to the
> lookup aspect of the hash table.
> > I see that there is just one "t->key_offset" that is pre-defined for 
> > the hash
> table. I also understand that the frame needs to carry the "lookup_key 
> / keys" in the meta data.
> >
> > Here is my question:  How to support more than one lookup with 
> > different
> keys on the same frame on the same table.
> > Use case: Src mac  lookup and dst mac lookup on the same mac table.
> >
> > Thanks
> > -Avinash
> 
> Just to confirm: this is using the extensible bucket hash in the 
> rte_table library of packet framework, rather than the standalone 
> rte_hash library, right?
> 
> /Bruce

Could you share detail on the two different keys used for lookups. In case if 
you are considering bidirectional packet flow between the source and 
destination, symmetric hash can be used-  
http://www.ndsl.kaist.edu/~kyoungsoo/papers/TR-symRSS.pdf 

Jasvinder

[dpdk-dev] [PATCH] mbuf & mempool: explicit typecast on function return

[Joongi Kim]

I already have fixed this issue at http://dpdk.org/dev/patchwork/patch/6068/
 .
There is another issue related to "underlying type" for enum declarations
http://dpdk.org/dev/patchwork/patch/6067/, for C++11 compilers.

In the second patch I missed updating headers for architectures other than
x86,
so it needs to be updated before applying to the master branch.

It would be great for me to have this fixed on the master branch,
as I am manually applying above patches whenever I pull the latest codes.

Regards,
Joongi

2015? 8? 17? (?) ?? 5:15, Olivier MATZ ?? ??:

> Hi Sergey,
>
> On 08/12/2015 11:11 AM, Sergey Balabanov wrote:
> > When DPDK is being compiled in C++ project using g++ then
> > 'invalid conversion from' error appears. Added explicit
> > typecast on function return to get rid of the error.
> >
> > Signed-off-by: Sergey Balabanov 
>
>
> Fixes: 7755baae8378 ("mbuf: silence warning on pointer arithmetic")
> Fixes: 6cf14ce4ce6c ("mempool: silence warning on pointer arithmetic")
>
> Acked-by: Olivier Matz 
>
> Thanks
>

[dpdk-dev] [PATCH] mempool: fix incompatibility with C++ in header file

[Avi Kivity]

(adding list+Thomas back to cc)

On 08/17/2015 11:33 AM, Olivier MATZ wrote:
> Hi,
>
> On 08/14/2015 10:33 AM, Avi Kivity wrote:
>> C++ doesn't allow implied casting from void * to another pointer, so
>> supply an explicit cast.
>>
>> Signed-off-by: Avi Kivity 
> For Thomas:
> This fix is already submitted in
> http://dpdk.org/dev/patchwork/patch/6750/
>
>
> Thanks Avi

[dpdk-dev] [PATCH] mempool: fix the inverted pg_num check on create

[Olivier MATZ]

Hi,

On 08/16/2015 09:08 PM, Dan Aloni wrote:
> The rest of the code expects pg_num <= RTE_DIM(mp->elt_pa).
> 
> Signed-off-by: Dan Aloni 
> ---
>  lib/librte_mempool/rte_mempool.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/librte_mempool/rte_mempool.c 
> b/lib/librte_mempool/rte_mempool.c
> index 8e185c545479..edcfa8bf9cb1 100644
> --- a/lib/librte_mempool/rte_mempool.c
> +++ b/lib/librte_mempool/rte_mempool.c
> @@ -461,7 +461,7 @@ rte_mempool_xmem_create(const char *name, unsigned n, 
> unsigned elt_size,
>   }
>  
>   /* Check that pg_num and pg_shift parameters are valid. */
> - if (pg_num < RTE_DIM(mp->elt_pa) || pg_shift > MEMPOOL_PG_SHIFT_MAX) {
> + if (pg_num > RTE_DIM(mp->elt_pa) || pg_shift > MEMPOOL_PG_SHIFT_MAX) {
>   rte_errno = EINVAL;
>   return NULL;
>   }
> 


Could you give some details about the conditions to reproduce and the
consequences of the issue?

>From what I see, RTE_DIM(mp->elt_pa) is always 1:

#define MEMPOOL_PG_NUM_DEFAULT  1
struct rte_mempool {
...
phys_addr_t elt_pa[MEMPOOL_PG_NUM_DEFAULT];
}  __rte_cache_aligned;

>From rte_mempool_xmem_create() documentation, pg_num gives the size of
the paddr array, which is allocated by the caller. So I think there is
no issue here.

Regards,
Olivier

[dpdk-dev] ieee1588fwd.c implementation

[Stefan Binna]

Hi,

I'm using the Intel NIC 82547L.
Furthermore I'm using DPDK-2.0.0, the last stable download from the 
official homepage.

Is there any method to "measure" the time the NIC takes to process the 
packet from the input port (e.g. port 0) to the output port (port 1)? 
Should be around 8 to 40 microseconds depending on the packet size?

Thanks. Best regards,
Stefan.

Am 14.08.2015 um 18:04 schrieb Mcnamara, John:
>> -Original Message-
>> From: Stefan Binna [mailto:stefan.binna at salzburgresearch.at]
>> Sent: Thursday, August 13, 2015 12:27 PM
>> To: Mcnamara, John; dev at dpdk.org
>> Subject: Re: [dpdk-dev] ieee1588fwd.c implementation
>>
>> I got PTP working and was able to transmit a valid PTPv2 packet over the
>> DPDK network card.
>>
>> Every time a PTP packet arrives I get following message in the testpmd
>> application: Port 0 Received PTP packet not filtered by hardware
>
> Hi,
>
> That may be due to 1 or 2 different issues:
>
>  1. You are using a NIC that doesn't support PTP timesyncing. What NIC 
> are you using?
>  2. You are using a Fortville NIC but don't have the latest code from 
> dpdk.org.
>
>
>> However, the hardware does not change the timestamp, when I check the
>> received packet.
> You will need to address the above issue first, but just to be clear, the NIC 
> doesn't update the timestamp in the PTP packet. It sets a flag to say that 
> the packet is a L2 PTP packet and that the timestamp of its arrival is 
> available for reading.
>
> John
>

[dpdk-dev] [PATCH] mbuf & mempool: explicit typecast on function return

[Olivier MATZ]

Hi Sergey,

On 08/12/2015 11:11 AM, Sergey Balabanov wrote:
> When DPDK is being compiled in C++ project using g++ then
> 'invalid conversion from' error appears. Added explicit
> typecast on function return to get rid of the error.
> 
> Signed-off-by: Sergey Balabanov 


Fixes: 7755baae8378 ("mbuf: silence warning on pointer arithmetic")
Fixes: 6cf14ce4ce6c ("mempool: silence warning on pointer arithmetic")

Acked-by: Olivier Matz 

Thanks

[dpdk-dev] [PATCH 3/3] doc: announce ring PMD functions removal

[Thomas Monjalon]

These functions are marked as deprecated for a long time:
61934c0956d4 ("ring: convert to use of PMD_REGISTER_DRIVER and fix 
linking")
As suggested in this patch, it should be removed:
http://dpdk.org/ml/archives/dev/2015-June/019253.html

Suggested-by: Stephen Hemminger 
Signed-off-by: Thomas Monjalon 
---
 doc/guides/rel_notes/deprecation.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 2424c61..46a88ca 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -61,6 +61,9 @@ Deprecation Notices
 * librte_kni: Functions based on port id are deprecated for a long time and
   should be removed (rte_kni_create, rte_kni_get_port_id and rte_kni_info_get).

+* librte_pmd_ring: The deprecated functions rte_eth_ring_pair_create and
+  rte_eth_ring_pair_attach should be removed.
+
 * ABI changes are planned for struct virtio_net in order to support vhost-user
   multiple queues feature.
   It should be integrated in release 2.2 without backward compatibility.
-- 
2.4.2

[dpdk-dev] [PATCH 2/3] doc: announce removal of kni functions using port id

[Thomas Monjalon]

These functions are marked as deprecated for a long time:
fbf895d44cfe ("kni: identify device by name")
As suggested in this patch, it should be removed:
http://dpdk.org/ml/archives/dev/2015-June/019254.html

Suggested-by: Stephen Hemminger 
Signed-off-by: Thomas Monjalon 
---
 doc/guides/rel_notes/deprecation.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index a9a12c6..2424c61 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -58,6 +58,9 @@ Deprecation Notices
   the tunnel type, TNI/VNI, inner MAC and inner VLAN are monitored.
   The release 2.2 will contain these changes without backwards compatibility.

+* librte_kni: Functions based on port id are deprecated for a long time and
+  should be removed (rte_kni_create, rte_kni_get_port_id and rte_kni_info_get).
+
 * ABI changes are planned for struct virtio_net in order to support vhost-user
   multiple queues feature.
   It should be integrated in release 2.2 without backward compatibility.
-- 
2.4.2

[dpdk-dev] [PATCH 1/3] doc: announce legacy 7-tuple acl rule removal

[Thomas Monjalon]

These functions are marked as deprecated for a long time.
As suggested in this patch, it should be removed:
http://dpdk.org/ml/archives/dev/2015-June/019255.html

Suggested-by: Stephen Hemminger 
Signed-off-by: Thomas Monjalon 
---
 doc/guides/rel_notes/deprecation.rst | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 8365981..a9a12c6 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -71,6 +71,10 @@ Deprecation Notices
 * The scheduler statistics structure will change to allow keeping track of
   RED actions.

+* librte_acl: The structure rte_acl_ipv4vlan_rule is deprecated and should
+  be removed as well as the associated functions rte_acl_ipv4vlan_add_rules
+  and rte_acl_ipv4vlan_build.
+
 * librte_cfgfile: In order to allow for longer names and values,
   the value of macros CFG_NAME_LEN and CFG_NAME_VAL will be increased.
   Most likely, the new values will be 64 and 256, respectively.
-- 
2.4.2

[dpdk-dev] [PATCH 0/3] announce deprecation of functions commented as deprecated

[Thomas Monjalon]

As suugested by Stephen, some functions are marked as deprecated in the code
and should now be removed.
Let's follow the deprecation process and announce it in the release notes.

Thomas Monjalon (3):
  doc: announce legacy 7-tuple acl rule removal
  doc: announce removal of kni functions using port id
  doc: announce ring PMD functions removal

 doc/guides/rel_notes/deprecation.rst | 10 ++
 1 file changed, 10 insertions(+)

-- 
2.4.2