Re: [dpdk-dev] [RFC] eventdev: event tx adapter APIs

[Jerin Jacob]

-Original Message-
> Date: Fri, 25 May 2018 20:38:44 +0530
> From: Nikhil Rao 
> To: jerin.ja...@caviumnetworks.com, hemant.agra...@nxp.com
> CC: dev@dpdk.org, narender.vang...@intel.com, abhinandan.guj...@intel.com,
>  gage.e...@intel.com, Nikhil Rao 
> Subject: [RFC] eventdev: event tx adapter APIs
> X-Mailer: git-send-email 1.8.3.1
> 
> The patch below introduces the event tx adapter APIs that encapsulate common
> code for the tx stage of a packet processing pipeline. These APIs allow
> the application to configure a rte_service function that reads mbuf events
> from an event queue and sends mbufs on the transmit queue and ethernet
> port specified in the mbuf private area.
> 

Hi Nikhil,

I think, it is reasonable to have Tx adapter.

Some top level comments to starts with,

1) Slow path API looks fine. The only comment is, How about changing
rte_event_eth_tx_adapter_queue_add() instead of 
rte_event_eth_tx_adapter_queue_start()
to get align  with Rx adapter?

2) This my understanding of fastpath

a) Common code will have a extra port(given through adapter create)
where all workers invoke rte_event_enqueue_burst() to that port and then common 
code 
dequeue from that port and send packet
using rte_eth_tx_burst() and/or using tx buffering APIs

b) If the source queue or sched_type is ORDERED, When it enqueue to the extra 
port it
will change to atomic/direct to maintain the the ingress order if need.

Couple of issues and a minor change in RFC to fix the issues as a proposal.

Issue 1) I think, Using mbuf private data for such purpose will be a problem as
exiting application already may using for it own needs and there will be 
additional cache
miss etc on fastpath to get private data.

Issue 2) At least on Cavium, We can do so optimization by introducing
the same RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT schematics of Rx
adapter. i.e we don't need extra port to converge all traffic from
different workers and transmit.


Considering above two issues2, We would like propose an fastpath API,
which semantics is almost same rte_ethdev_tx_burst().
a) It will get ride of mbuf metadata need
b) New fastpath API gives driver enough possibilities of optimization if
possible.(address the issue (2))

The API can be like,

uint16_t rte_event_eth_tx_adapter_enqueue(uint16_t eth_port_id, uint16_t
eth_queue_id, uint8_t event_port_id, const struct rte_event ev[], uint16_t 
nb_events);

This API would land in driver as function pointer if device has
RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT capability.

If device does not have !RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT then 
common code can choose to ignore event_port_id in
rte_event_eth_tx_adapter_enqueue() and select the port given in adapter
create in common code.

So from the top-level, each worker lcore will look like

while(1)
{
rte_event_dequeue_burst(..,worker[port],..);
(process the packets)
rte_event_eth_tx_adapter_enqueue(... worker[port],...);
}

Thoughts?

Re: [dpdk-dev] [PATCH v2] rte_ring: clarify preemptible nature of ring algorithm

[Burakov, Anatoly]

On 29-May-18 5:36 PM, Honnappa Nagarahalli wrote:

I do not see the documentation regarding this in programmer's guide.


Hi

Apologies, it's not in rte_ring section, it's in programmer's guide for EAL:

http://www.dpdk.org/doc/guides/prog_guide/env_abstraction_layer.html#known-issues

Perhaps this could be referenced in the rte_ring (or indeed copied/moved 
there)?


--
Thanks,
Anatoly

Re: [dpdk-dev] [dpdk-stable] [PATCH v5 1/2] mk: fix cross build errors

[Thomas Monjalon]

30/05/2018 04:45, Gavin Hu:
> From: Bruce Richardson 
> > On Tue, May 29, 2018 at 04:45:55PM +0200, Thomas Monjalon wrote:
> > > 28/05/2018 15:24, Bruce Richardson:
> > > > Would a simpler solution for this not be to put "-Wno-implicit-
> > fallthrough"
> > > > for pmdinfogen? GCC will not give a warning for an unrecognised "-Wno"
> > > > flag when compiling, unless there are other errors. This means we
> > > > can just use the flag without bothering with version checks.
> > >
> > > No, it does not work.
> > > I have this error with clang 5.0.1:
> > > error: unknown warning option '-Wno-format-truncation'
> > >
> > Yes, you still need to check for GCC to use the flag, just not for a 
> > specific
> > version of GCC.
> >
> > /Bruce
> [Gavin Hu] Hi Thomas, '-Wno-format-truncation' is applied to gcc only, not to 
> clang.
> Gcc, icc and clang have their own WERROR_FLAGS, they should not mix up with 
> each other.

Now I understand what we missed from the beginning: I am testing with meson.
This flag is added unconditionnaly in config/meson.build.

> @Bruce,
> Yes, in this sense, I am really concerned about to add 
> -Wno-implicit-fallthrough option in the pmdinfogen Makefile, as it impacts 
> not only gcc, but also clang and icc.
> Maybe this not a best solution, as maybe it is not supported by all 
> compilers. So should I fall back to the previous patch which check for the 
> gcc version and apply the options for gcc only?

[dpdk-dev] [dpdk-announce] DPDK PRC Summit 2018, Agenda announced, Registration open

[Xu, Qian Q]

Dear all
Agenda [1] for DPDK PRC Summit 2018 June 28th in Beijing is announced. You can 
also go to dpdk.org/events to check the schedule and do the registration.
The agenda covers diverse categories as NFV, Virtualization, Smart NIC, 
framework and Cloud. And there are many interesting topics such as scalable 
packet framework, latest virtio1.1, vhost acceleration in DPDK, virtual switch 
with intelligent adapter, FPGA acceleration, Load balancer to support Alibaba 
Dual 11 festival, link-level network slicing, hardware level performance 
analysis and etc. You can check the agenda for more details.
We are looking forwards to seeing you there. Please register here [2][3].
Reminder : This is a community conference --- so let's try to avoid blatant 
product and/or vendor sales pitches.
Questions?  Please contact us by mail eve...@dpdk.org

[1] https://dpdkprcsummit2018.sched.com/
[2] https://www.regonline.com/registration/checkin.aspx?EventId=2205569  
Register DPDK only
[3] http://linux.31huiyi.com/  Register L3C and DPDK

[dpdk-dev] [PATCH v2] net/i40e: fix link status update

[Fan Zhang]

This patch fixes link status update problem in interrupt mode.
Previously, directly reading link status register instead of
accessing via admin queue command may cause the link status
change interrupt callback inactive. This patch fixes the
problem by making the driver only read the register in
"no wait" and polling mode.

Bugzilla ID 54, link https://dpdk.org/tracker/show_bug.cgi?id=54

Fixes: eef2daf2e199 ("net/i40e: fix link update no wait")
Cc: sta...@dpdk.org

Signed-off-by: Fan Zhang 
---
 drivers/net/i40e/i40e_ethdev.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 7d4f1c9da..13c5d3296 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2522,7 +2522,7 @@ i40e_dev_set_link_down(struct rte_eth_dev *dev)
 }
 
 static __rte_always_inline void
-update_link_no_wait(struct i40e_hw *hw, struct rte_eth_link *link)
+update_link_reg(struct i40e_hw *hw, struct rte_eth_link *link)
 {
 /* Link status registers and values*/
 #define I40E_PRTMAC_LINKSTA0x001E2420
@@ -2576,8 +2576,8 @@ update_link_no_wait(struct i40e_hw *hw, struct 
rte_eth_link *link)
 }
 
 static __rte_always_inline void
-update_link_wait(struct i40e_hw *hw, struct rte_eth_link *link,
-   bool enable_lse)
+update_link_aq(struct i40e_hw *hw, struct rte_eth_link *link,
+   bool enable_lse, int wait_to_complete)
 {
 #define CHECK_INTERVAL 100  /* 100ms */
 #define MAX_REPEAT_TIME10  /* 1s (10 * 100ms) in total */
@@ -2601,7 +2601,7 @@ update_link_wait(struct i40e_hw *hw, struct rte_eth_link 
*link,
}
 
link->link_status = link_status.link_info & I40E_AQ_LINK_UP;
-   if (unlikely(link->link_status != 0))
+   if (!wait_to_complete || link->link_status)
break;
 
rte_delay_ms(CHECK_INTERVAL);
@@ -2649,10 +2649,10 @@ i40e_dev_link_update(struct rte_eth_dev *dev,
link.link_autoneg = !(dev->data->dev_conf.link_speeds &
ETH_LINK_SPEED_FIXED);
 
-   if (!wait_to_complete)
-   update_link_no_wait(hw, &link);
+   if (!wait_to_complete && !enable_lse)
+   update_link_reg(hw, &link);
else
-   update_link_wait(hw, &link, enable_lse);
+   update_link_aq(hw, &link, enable_lse, wait_to_complete);
 
ret = rte_eth_linkstatus_set(dev, &link);
i40e_notify_all_vfs_link_status(dev);
-- 
2.13.6

[dpdk-dev] [PATCH v2] net/i40e: fix link status update

[Fan Zhang]

This patch fixes link status update problem in interrupt mode.
Previously, directly reading link status register instead of
accessing via admin queue command may cause the link status
change interrupt callback inactive. This patch fixes the
problem by making the driver only read the register in
"no wait" and polling mode.

Bugzilla ID 54, link https://dpdk.org/tracker/show_bug.cgi?id=54

Fixes: eef2daf2e199 ("net/i40e: fix link update no wait")
Cc: sta...@dpdk.org

Signed-off-by: Fan Zhang 
---
 drivers/net/i40e/i40e_ethdev.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 7d4f1c9da..13c5d3296 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2522,7 +2522,7 @@ i40e_dev_set_link_down(struct rte_eth_dev *dev)
 }
 
 static __rte_always_inline void
-update_link_no_wait(struct i40e_hw *hw, struct rte_eth_link *link)
+update_link_reg(struct i40e_hw *hw, struct rte_eth_link *link)
 {
 /* Link status registers and values*/
 #define I40E_PRTMAC_LINKSTA0x001E2420
@@ -2576,8 +2576,8 @@ update_link_no_wait(struct i40e_hw *hw, struct 
rte_eth_link *link)
 }
 
 static __rte_always_inline void
-update_link_wait(struct i40e_hw *hw, struct rte_eth_link *link,
-   bool enable_lse)
+update_link_aq(struct i40e_hw *hw, struct rte_eth_link *link,
+   bool enable_lse, int wait_to_complete)
 {
 #define CHECK_INTERVAL 100  /* 100ms */
 #define MAX_REPEAT_TIME10  /* 1s (10 * 100ms) in total */
@@ -2601,7 +2601,7 @@ update_link_wait(struct i40e_hw *hw, struct rte_eth_link 
*link,
}
 
link->link_status = link_status.link_info & I40E_AQ_LINK_UP;
-   if (unlikely(link->link_status != 0))
+   if (!wait_to_complete || link->link_status)
break;
 
rte_delay_ms(CHECK_INTERVAL);
@@ -2649,10 +2649,10 @@ i40e_dev_link_update(struct rte_eth_dev *dev,
link.link_autoneg = !(dev->data->dev_conf.link_speeds &
ETH_LINK_SPEED_FIXED);
 
-   if (!wait_to_complete)
-   update_link_no_wait(hw, &link);
+   if (!wait_to_complete && !enable_lse)
+   update_link_reg(hw, &link);
else
-   update_link_wait(hw, &link, enable_lse);
+   update_link_aq(hw, &link, enable_lse, wait_to_complete);
 
ret = rte_eth_linkstatus_set(dev, &link);
i40e_notify_all_vfs_link_status(dev);
-- 
2.13.6

[dpdk-dev] [PATCH v3] net/i40e: fix link status update

[Fan Zhang]

This patch fixes link status update problem in interrupt mode.
Previously, directly reading link status register instead of
accessing via admin queue command may cause the link status
change interrupt callback inactive. This patch fixes the
problem by making the driver only read the register in
"no wait" and polling mode.

Bugzilla ID: 54
Fixes: eef2daf2e199 ("net/i40e: fix link update no wait")
Cc: sta...@dpdk.org

Signed-off-by: Fan Zhang 
---
 drivers/net/i40e/i40e_ethdev.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 7d4f1c9da..13c5d3296 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2522,7 +2522,7 @@ i40e_dev_set_link_down(struct rte_eth_dev *dev)
 }
 
 static __rte_always_inline void
-update_link_no_wait(struct i40e_hw *hw, struct rte_eth_link *link)
+update_link_reg(struct i40e_hw *hw, struct rte_eth_link *link)
 {
 /* Link status registers and values*/
 #define I40E_PRTMAC_LINKSTA0x001E2420
@@ -2576,8 +2576,8 @@ update_link_no_wait(struct i40e_hw *hw, struct 
rte_eth_link *link)
 }
 
 static __rte_always_inline void
-update_link_wait(struct i40e_hw *hw, struct rte_eth_link *link,
-   bool enable_lse)
+update_link_aq(struct i40e_hw *hw, struct rte_eth_link *link,
+   bool enable_lse, int wait_to_complete)
 {
 #define CHECK_INTERVAL 100  /* 100ms */
 #define MAX_REPEAT_TIME10  /* 1s (10 * 100ms) in total */
@@ -2601,7 +2601,7 @@ update_link_wait(struct i40e_hw *hw, struct rte_eth_link 
*link,
}
 
link->link_status = link_status.link_info & I40E_AQ_LINK_UP;
-   if (unlikely(link->link_status != 0))
+   if (!wait_to_complete || link->link_status)
break;
 
rte_delay_ms(CHECK_INTERVAL);
@@ -2649,10 +2649,10 @@ i40e_dev_link_update(struct rte_eth_dev *dev,
link.link_autoneg = !(dev->data->dev_conf.link_speeds &
ETH_LINK_SPEED_FIXED);
 
-   if (!wait_to_complete)
-   update_link_no_wait(hw, &link);
+   if (!wait_to_complete && !enable_lse)
+   update_link_reg(hw, &link);
else
-   update_link_wait(hw, &link, enable_lse);
+   update_link_aq(hw, &link, enable_lse, wait_to_complete);
 
ret = rte_eth_linkstatus_set(dev, &link);
i40e_notify_all_vfs_link_status(dev);
-- 
2.13.6

Re: [dpdk-dev] [PATCH v3] net/i40e: fix link status update

[Zhang, Qi Z]

> -Original Message-
> From: Zhang, Roy Fan
> Sent: Wednesday, May 30, 2018 4:31 PM
> To: dev@dpdk.org
> Cc: Zhang, Helin ; Zhang, Roy Fan
> ; Zhang, Qi Z ;
> sta...@dpdk.org
> Subject: [PATCH v3] net/i40e: fix link status update
> 
> This patch fixes link status update problem in interrupt mode.
> Previously, directly reading link status register instead of accessing via 
> admin
> queue command may cause the link status change interrupt callback inactive.
> This patch fixes the problem by making the driver only read the register in
> "no wait" and polling mode.
> 
> Bugzilla ID: 54
> Fixes: eef2daf2e199 ("net/i40e: fix link update no wait")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Fan Zhang 

Acked-by: Qi Zhang 

Re: [dpdk-dev] [dpdk-stable] [PATCH v5 1/2] mk: fix cross build errors

[Gavin Hu]

> -Original Message-
> From: Thomas Monjalon 
> Sent: Wednesday, May 30, 2018 4:32 PM
> To: Gavin Hu 
> Cc: Bruce Richardson ; dev@dpdk.org
> Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v5 1/2] mk: fix cross build
> errors
>
> 30/05/2018 04:45, Gavin Hu:
> > From: Bruce Richardson 
> > > On Tue, May 29, 2018 at 04:45:55PM +0200, Thomas Monjalon wrote:
> > > > 28/05/2018 15:24, Bruce Richardson:
> > > > > Would a simpler solution for this not be to put "-Wno-implicit-
> > > fallthrough"
> > > > > for pmdinfogen? GCC will not give a warning for an unrecognised "-
> Wno"
> > > > > flag when compiling, unless there are other errors. This means
> > > > > we can just use the flag without bothering with version checks.
> > > >
> > > > No, it does not work.
> > > > I have this error with clang 5.0.1:
> > > > error: unknown warning option '-Wno-format-truncation'
> > > >
> > > Yes, you still need to check for GCC to use the flag, just not for a
> > > specific version of GCC.
> > >
> > > /Bruce
> > [Gavin Hu] Hi Thomas, '-Wno-format-truncation' is applied to gcc only, not
> to clang.
> > Gcc, icc and clang have their own WERROR_FLAGS, they should not mix up
> with each other.
>
> Now I understand what we missed from the beginning: I am testing with
> meson.
> This flag is added unconditionnaly in config/meson.build.

[Gavin Hu] Hi Thomas and Bruce, then do you have more comments on the v5 patch?
Any comments are welcome, if no, can you act the patches for merging?

>
> > @Bruce,
> > Yes, in this sense, I am really concerned about to add -Wno-implicit-
> fallthrough option in the pmdinfogen Makefile, as it impacts not only gcc, but
> also clang and icc.
> > Maybe this not a best solution, as maybe it is not supported by all
> compilers. So should I fall back to the previous patch which check for the gcc
> version and apply the options for gcc only?
>
>

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [dpdk-dev] [PATCH] net/sfc: add missing Rx descriptor status callback

[Ferruh Yigit]

On 5/30/2018 7:44 AM, Andrew Rybchenko wrote:
> Thomas, Ferruh,
> 
> I've found out that the following patch is deferred in patchwork:
> https://dpdk.org/dev/patchwork/patch/40455/
> 
> It is critical under certain conditions since fix application crash.
> The patch is net/sfc local and just few lines - absolutely harmless.
> The only potential DPDK-wide effect is build, but the patch is really
> trivial and it is hard to imagine how it could affect the build.
> I'd like it to be included in 18.05, if possible.
> 
> I understand that 18.05 is really very-very late already and it
> could be too late even for such patch. Just would like to
> double-check it.

Hi Andrew,

I did mark it as deferred and I overlooked that this fixes a crash.

Agree that scope is local and only effect should be build, I confirmed the build
but to be sure I suggest get the patch and trigger an Intel daily build, and
include the patch into release if only that build also returns success.

> 
> Thanks,
> Andrew.
> 
> On 05/28/2018 09:50 AM, Andrew Rybchenko wrote:
>> Rx descriptor status callback was lost and request of the Rx
>> descriptor status crashes application if equal stride super-buffer
>> Rx mode is used.
>>
>> Fixes: 390f9b8d82c9 ("net/sfc: support equal stride super-buffer Rx mode")
>>
>> Signed-off-by: Andrew Rybchenko 
>> ---
>>  drivers/net/sfc/sfc_ef10_essb_rx.c | 9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/net/sfc/sfc_ef10_essb_rx.c 
>> b/drivers/net/sfc/sfc_ef10_essb_rx.c
>> index 289b61e52..5f5af602c 100644
>> --- a/drivers/net/sfc/sfc_ef10_essb_rx.c
>> +++ b/drivers/net/sfc/sfc_ef10_essb_rx.c
>> @@ -413,6 +413,14 @@ sfc_ef10_essb_rx_qdesc_npending(__rte_unused struct 
>> sfc_dp_rxq *dp_rxq)
>>  return -ENOTSUP;
>>  }
>>  
>> +static sfc_dp_rx_qdesc_status_t sfc_ef10_essb_rx_qdesc_status;
>> +static int
>> +sfc_ef10_essb_rx_qdesc_status(__rte_unused struct sfc_dp_rxq *dp_rxq,
>> +  __rte_unused uint16_t offset)
>> +{
>> +return -ENOTSUP;
>> +}
>> +
>>  static sfc_dp_rx_get_dev_info_t sfc_ef10_essb_rx_get_dev_info;
>>  static void
>>  sfc_ef10_essb_rx_get_dev_info(struct rte_eth_dev_info *dev_info)
>> @@ -687,5 +695,6 @@ struct sfc_dp_rx sfc_ef10_essb_rx = {
>>  .qpurge = sfc_ef10_essb_rx_qpurge,
>>  .supported_ptypes_get   = sfc_ef10_supported_ptypes_get,
>>  .qdesc_npending = sfc_ef10_essb_rx_qdesc_npending,
>> +.qdesc_status   = sfc_ef10_essb_rx_qdesc_status,
>>  .pkt_burst  = sfc_ef10_essb_recv_pkts,
>>  };
> 

Re: [dpdk-dev] [PATCH v3] net/i40e: fix link status update

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org]
> Sent: Wednesday, May 30, 2018 9:31 AM
> To: dev@dpdk.org
> Cc: Zhang, Helin ; Zhang, Roy Fan
> ; Zhang, Qi Z ;
> sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH v3] net/i40e: fix link status update
> 
> This patch fixes link status update problem in interrupt mode.
> Previously, directly reading link status register instead of accessing via 
> admin
> queue command may cause the link status change interrupt callback inactive.
> This patch fixes the problem by making the driver only read the register in 
> "no
> wait" and polling mode.
> 
> Bugzilla ID: 54
> Fixes: eef2daf2e199 ("net/i40e: fix link update no wait")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Fan Zhang 

Tested-by: Pablo de Lara 

Re: [dpdk-dev] Stable ABI status of rte_meter_[t|s]rtcm_profile_config

[Singh, Jasvinder]

> On 05/28/2018 11:31 AM, Andy Green wrote:
> > Hi -
> >
> > Between 18.02 and the putative 18.05 there were changes in the way the
> > meter stuff deals with its config.
> >
> > I updated the related code in lagopus, but I get warnings about using
> > the new APIs (it's the same for rte_meter_trtcm_profile_config())
> >
> > ./dpdk/meter.c: In function 'dpdk_register_meter':
> > ./dpdk/meter.c:119:7: warning: 'rte_meter_srtcm_profile_config' is
> > deprecated: Symbol is not yet part of stable ABI
> > [-Wdeprecated-declarations]
> >     rte_meter_srtcm_profile_config(&lband->sp, ¶m);
> >     ^
> > In file included from ./dpdk/meter.c:27:0:
> > /home/agreen/lagopus/src/dpdk/build/include/rte_meter.h:86:1: note:
> > declared here
> >   rte_meter_srtcm_profile_config(struct rte_meter_srtcm_profile *p,
> >   ^
> > ./dpdk/meter.c:132:7: warning: 'rte_meter_srtcm_profile_config' is
> > deprecated: Symbol is not yet part of stable ABI
> > [-Wdeprecated-declarations]
> >     rte_meter_srtcm_profile_config(&lband->sp, ¶m);
> >     ^
> > In file included from ./dpdk/meter.c:27:0:
> > /home/agreen/lagopus/src/dpdk/build/include/rte_meter.h:86:1: note:
> > declared here
> >   rte_meter_srtcm_profile_config(struct rte_meter_srtcm_profile *p,
> >
> >
> > As far as I can see this api change is not optional, it changes the
> > parameters for related apis to require a struct prepared with these
> > new apis.
> 
> IOW should these exports still be "experimental"
> 
> EXPERIMENTAL {
>  global:
> 
>  rte_meter_srtcm_profile_config;
>  rte_meter_trtcm_profile_config; };
> 
> ...when the changes also introduced in
> c06ddf9698e0c2a9653cfa971f9ddc205065662c unconditionally modify the
> existing APIs to require the new stuff?
> 
> @@ -138,6 +187,7 @@ rte_meter_srtcm_color_aware_check(struct
> rte_meter_srtcm *m,
>*/
>   static inline enum rte_meter_color
>   rte_meter_trtcm_color_blind_check(struct rte_meter_trtcm *m,
> +   struct rte_meter_trtcm_profile *p,
>  uint64_t time,
>  uint32_t pkt_len);
> 
> etc

The above meter APIs change has followed the deprecation procedure, therefore, 
IMO, should not be treated as experimental. In general, this is open question 
as nothing is specified in the docs.

   

Re: [dpdk-dev] Stable ABI status of rte_meter_[t|s]rtcm_profile_config

[Andy Green]

On 05/30/2018 05:55 PM, Singh, Jasvinder wrote:




On 05/28/2018 11:31 AM, Andy Green wrote:

Hi -

Between 18.02 and the putative 18.05 there were changes in the way the
meter stuff deals with its config.

I updated the related code in lagopus, but I get warnings about using
the new APIs (it's the same for rte_meter_trtcm_profile_config())

./dpdk/meter.c: In function 'dpdk_register_meter':
./dpdk/meter.c:119:7: warning: 'rte_meter_srtcm_profile_config' is
deprecated: Symbol is not yet part of stable ABI
[-Wdeprecated-declarations]
     rte_meter_srtcm_profile_config(&lband->sp, ¶m);
     ^
In file included from ./dpdk/meter.c:27:0:
/home/agreen/lagopus/src/dpdk/build/include/rte_meter.h:86:1: note:
declared here
   rte_meter_srtcm_profile_config(struct rte_meter_srtcm_profile *p,
   ^
./dpdk/meter.c:132:7: warning: 'rte_meter_srtcm_profile_config' is
deprecated: Symbol is not yet part of stable ABI
[-Wdeprecated-declarations]
     rte_meter_srtcm_profile_config(&lband->sp, ¶m);
     ^
In file included from ./dpdk/meter.c:27:0:
/home/agreen/lagopus/src/dpdk/build/include/rte_meter.h:86:1: note:
declared here
   rte_meter_srtcm_profile_config(struct rte_meter_srtcm_profile *p,


As far as I can see this api change is not optional, it changes the
parameters for related apis to require a struct prepared with these
new apis.


IOW should these exports still be "experimental"

EXPERIMENTAL {
  global:

  rte_meter_srtcm_profile_config;
  rte_meter_trtcm_profile_config; };

...when the changes also introduced in
c06ddf9698e0c2a9653cfa971f9ddc205065662c unconditionally modify the
existing APIs to require the new stuff?

@@ -138,6 +187,7 @@ rte_meter_srtcm_color_aware_check(struct
rte_meter_srtcm *m,
*/
   static inline enum rte_meter_color
   rte_meter_trtcm_color_blind_check(struct rte_meter_trtcm *m,
+   struct rte_meter_trtcm_profile *p,
  uint64_t time,
  uint32_t pkt_len);

etc


The above meter APIs change has followed the deprecation procedure, therefore, 
IMO, should not be treated as experimental. In general, this is open question 
as nothing is specified in the docs.


Thanks.

Another way to ask the same question is: "after we changed the related, 
pre-existing api to require this, why is it useful to want it to blow 
warnings unless we enable EXPERIMENTAL"?


Before the patch, meter api itself wasn't experimental evidently. 
Lagopus uses the old api without EXPERIMENTAL enabled for 18.02; then on 
18.05, after the api it was previously using without EXPERIMENTAL 
changed, it blows warnings after it was actually unconditionally forced 
to adapt to use the new stuff.


Unless I misunderstood it, you can't meaningfully, retrospectively, mark 
a public API EXPERIMENTAL after you changed it, and this is marking 
EXPERIMENTAL a new unconditional dependency on a new type for an API 
that was a previously available via a non-EXPERIMENTAL public api.


Effectively I think you just decided to change the public api (which is 
normal enough for living projects...) and that's the end of it. 
EXPERIMENTAL is only meaningful for stuff you can cleanly enable or 
disable at build-time, this is not such a situation.


If so it should get un-experimentalized for export...

-Andy

Re: [dpdk-dev] [dpdk-stable] [PATCH v5 1/2] mk: fix cross build errors

[Thomas Monjalon]

30/05/2018 11:41, Gavin Hu:
> From: Thomas Monjalon 
> > 30/05/2018 04:45, Gavin Hu:
> > > From: Bruce Richardson 
> > > > On Tue, May 29, 2018 at 04:45:55PM +0200, Thomas Monjalon wrote:
> > > > > 28/05/2018 15:24, Bruce Richardson:
> > > > > > Would a simpler solution for this not be to put "-Wno-implicit-
> > > > fallthrough"
> > > > > > for pmdinfogen? GCC will not give a warning for an unrecognised "-
> > Wno"
> > > > > > flag when compiling, unless there are other errors. This means
> > > > > > we can just use the flag without bothering with version checks.
> > > > >
> > > > > No, it does not work.
> > > > > I have this error with clang 5.0.1:
> > > > > error: unknown warning option '-Wno-format-truncation'
> > > > >
> > > > Yes, you still need to check for GCC to use the flag, just not for a
> > > > specific version of GCC.
> > > >
> > > > /Bruce
> > > [Gavin Hu] Hi Thomas, '-Wno-format-truncation' is applied to gcc only, not
> > to clang.
> > > Gcc, icc and clang have their own WERROR_FLAGS, they should not mix up
> > with each other.
> >
> > Now I understand what we missed from the beginning: I am testing with
> > meson.
> > This flag is added unconditionnaly in config/meson.build.
> 
> [Gavin Hu] Hi Thomas and Bruce, then do you have more comments on the v5 
> patch?
> Any comments are welcome, if no, can you act the patches for merging?

Of course we have comments!
I keep telling you that compilation is not working.
Try meson compilation: devtools/test-meson-builds.sh

Re: [dpdk-dev] [PATCH v3] net/i40e: fix link status update

[Thomas Monjalon]

> > This patch fixes link status update problem in interrupt mode.
> > Previously, directly reading link status register instead of accessing via 
> > admin
> > queue command may cause the link status change interrupt callback inactive.
> > This patch fixes the problem by making the driver only read the register in 
> > "no
> > wait" and polling mode.
> > 
> > Bugzilla ID: 54
> > Fixes: eef2daf2e199 ("net/i40e: fix link update no wait")
> > Cc: sta...@dpdk.org
> > 
> > Signed-off-by: Fan Zhang 
> 
> Tested-by: Pablo de Lara 

Applied, thanks

Re: [dpdk-dev] [PATCH] net/sfc: add missing Rx descriptor status callback

[Thomas Monjalon]

30/05/2018 11:42, Ferruh Yigit:
> On 5/30/2018 7:44 AM, Andrew Rybchenko wrote:
> > Thomas, Ferruh,
> > 
> > I've found out that the following patch is deferred in patchwork:
> > https://dpdk.org/dev/patchwork/patch/40455/
> > 
> > It is critical under certain conditions since fix application crash.
> > The patch is net/sfc local and just few lines - absolutely harmless.
> > The only potential DPDK-wide effect is build, but the patch is really
> > trivial and it is hard to imagine how it could affect the build.
> > I'd like it to be included in 18.05, if possible.
> > 
> > I understand that 18.05 is really very-very late already and it
> > could be too late even for such patch. Just would like to
> > double-check it.
> 
> Hi Andrew,
> 
> I did mark it as deferred and I overlooked that this fixes a crash.
> 
> Agree that scope is local and only effect should be build, I confirmed the 
> build
> but to be sure I suggest get the patch and trigger an Intel daily build, and
> include the patch into release if only that build also returns success.
> 
> > 
> > Thanks,
> > Andrew.
> > 
> > On 05/28/2018 09:50 AM, Andrew Rybchenko wrote:
> >> Rx descriptor status callback was lost and request of the Rx
> >> descriptor status crashes application if equal stride super-buffer
> >> Rx mode is used.
> >>
> >> Fixes: 390f9b8d82c9 ("net/sfc: support equal stride super-buffer Rx mode")
> >>
> >> Signed-off-by: Andrew Rybchenko 

Applied, thanks for the heads up.

[dpdk-dev] [Bug 55] I40E PMD driver in vector mode implicitly requires number of RX descriptors in a ring to be power of two

[bugzilla]

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

Bug ID: 55
   Summary: I40E PMD driver in vector mode implicitly requires
number of RX descriptors in a ring to be power of two
   Product: DPDK
   Version: 17.11
  Hardware: x86
OS: Linux
Status: CONFIRMED
  Severity: major
  Priority: Normal
 Component: ethdev
  Assignee: dev@dpdk.org
  Reporter: kjeld.morten...@tieto.com
  Target Milestone: ---

We have experienced instability of the I40E PMD in case it is compiled in
vector mode (CONFIG_RTE_LIBRTE_I40E_INC_VECTOR).

General observation:

We see instability in case we set the number of RX descriptors in a ring buffer
to something which is NOT the power of two.

Debugging was done on 17.11, but code inspection was performed on latest
master.

---
Observation 1, process hang (infinite loop?):

Debugging points to:
_i40e_rx_queue_release_mbufs_vec
http://dpdk.org/browse/dpdk/tree/drivers/net/i40e/i40e_rxtx_vec_common.h#n144

Here the else-part contains a loop which iterates over:
 i = (i + 1) & mask;
The mask is:
 const unsigned mask = rxq->nb_rx_desc - 1;

This suggests that nb_rx_desc assumes a power of two.

---
Observation 2, some RX packets are unexpectedly empty (but we do not have in
depth view in this case):

A more general (quick and incomplete) code inspection of the RX vector part of
the I40E driver source code gave the following finding:

In the procedure _recv_raw_pkts_vec,
http://dpdk.org/browse/dpdk/tree/drivers/net/i40e/i40e_rxtx_vec_sse.c#n453
we have:
  rxq->rx_tail = (uint16_t)(rxq->rx_tail & (rxq->nb_rx_desc - 1));

Again this suggests to me that it is assumed that nb_rx_desc should be a power
of two in the vector case.

---

We certainly understand that one can optimize performance using a power-of-two
assumption about the RX ring buffer size. For example, this seems what the
FM10K driver does:
  15.2.1.1. Prerequisites and Pre-conditions
  http://dpdk.org/doc/guides/nics/fm10k.html
In this case FM10K has documented the "limitation" and also has an explicit
check using the rte_is_power_of_2 procedure in case of vectorization.

Should we have something similar for I40E in vector mode? 

--
Kjeld Mortensen
Tieto

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

[dpdk-dev] Compilation of MLX5 driver

[Nitin Katiyar]

Hi,
I am trying to compile MLX5 PMD driver by setting 
"CONFIG_RTE_LIBRTE_MLX5_PMD=y" and hitting following compilation error.

fatal error: infiniband/mlx5_hw.h: No such file or directory

I have installed MLNX_OFED _LINUX-4.2-1.2.0 on my Ubuntu 14.04 machine but 
still hitting the same error. Am I missing some other package?

Regards,
Nitin

Re: [dpdk-dev] [dpdk-stable] [PATCH v2] doc/guides/rel_notes: Add known issue for IOMMU attributes read

[Thomas Monjalon]

> > > Linux kernel 4.10.0 iommu attribute read error
> > >
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Rosen Xu 
> > 
> > 
> > Could you open an Bugzilla defect for this and add it to the text.
> > 
> > Like this patch: http://dpdk.org/dev/patchwork/patch/40475/
> 
> Actually, I changed my mind. This isn't quite the same as the other new, 
> known issues, so there is no need to track it in Bugzilla or move it to the 
> release note.
> 
> It is okay as is.
> 
> Acked-by: John McNamara 

Applied, thanks

Re: [dpdk-dev] [PATCH v3] doc: add known issue of rte abort on FreeBSD

[Thomas Monjalon]

> > Added known issue of rte_abort taking a long time on FreeBSD due to recent
> > memory subsystem rework.
> > Also, reference Bugzilla entry for keeping most current information in one
> > place.
> > 
> > Signed-off-by: Reshma Pattan 
> > Acked-by: Anatoly Burakov 
> 
> Acked-by: John McNamara 

Applied, thanks

Re: [dpdk-dev] [PATCH v2] doc: document known issues for multiprocess

[Thomas Monjalon]

> > Also, reference Bugzilla entry for keeping most current information in one
> > place.
> > 
> > Signed-off-by: Anatoly Burakov 
> 
> Acked-by: John McNamara 

Applied, thanks

Re: [dpdk-dev] [RFC v2] vhost: new rte_vhost API proposal

[Stojaczyk, DariuszX]

> -Original Message-
> From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> Sent: Wednesday, May 30, 2018 10:57 AM
> On Tue, May 29, 2018 at 01:38:33PM +, Stojaczyk, DariuszX wrote:
> >
> >
> > > -Original Message-
> > > From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> > > Sent: Friday, May 25, 2018 12:06 PM
> > > On Fri, May 18, 2018 at 03:01:05PM +0200, Dariusz Stojaczyk wrote:
> > > > +struct rte_vhost2_msg {
> > > > +   uint32_t id;
> > >
> > > Is this what the vhost-user specification calls the "request type"?
> > > I suggest following the vhost-user spec terminology.
> > >
> > > > +   uint32_t flags;
> > > > +   uint32_t size; /**< The following payload size. */
> > > > +   void *payload;
> > > > +   int fds[RTE_VHOST2_MEMORY_MAX_NREGIONS];
> > >
> > > Is it necessary to expose file descriptor passing in the API?
> > > virtio-vhost-user doesn't have file descriptor passing, so it's best
> > > if this can be hidden inside rte_vhost2.
> >
> > So it's another argument for not exposing raw message handling to the
> user.
> > If there's some backend-specific vhost-user message in future that
> contains an fd, it will need a set of new abstractions to work with virtio-
> vhost-user anyway.
> > I guess I'll get back the original custom_msg idea from V1.
> 
> Hold on, have you looked at the device-specific messages defined in the
> vhost-user spec?  Do any of them even pass resources (file descriptors)?

There's at least VHOST_USER_NVME_SET_CQ_CALL (currently in review, not present 
in master yet). Vhost-nvme is a one big hack that doesn't use any virtqueues, 
so it has its own message for callfd.

Re: [dpdk-dev] [PATCH] doc: document bonding known issue

[Thomas Monjalon]

> > Signed-off-by: Radu Nicolau 
> 
> Acked-by: John McNamara 

Applied with some formatting/typo changes, thanks

Re: [dpdk-dev] [PATCH] doc: document vhost performance regression

[Thomas Monjalon]

> > Signed-off-by: Maxime Coquelin 
> 
> Acked-by: John McNamara 

Applied, thanks

Re: [dpdk-dev] Compilation of MLX5 driver

[Nélio Laranjeiro]

Hi,

On Wed, May 30, 2018 at 11:54:31AM +, Nitin Katiyar wrote:
> Hi,
> I am trying to compile MLX5 PMD driver by setting 
> "CONFIG_RTE_LIBRTE_MLX5_PMD=y" and hitting following compilation error.
> 
> fatal error: infiniband/mlx5_hw.h: No such file or directory
> 
> I have installed MLNX_OFED _LINUX-4.2-1.2.0 on my Ubuntu 14.04 machine but 
> still hitting the same error. Am I missing some other package?

Which version of DPDK are you using (it is important to help)?

Regards,

-- 
Nélio Laranjeiro
6WIND

[dpdk-dev] [Bug 56] crash when freeing memory with no mlx5 device attached

[bugzilla]

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

Bug ID: 56
   Summary: crash when freeing memory with no mlx5 device attached
   Product: DPDK
   Version: 18.05
  Hardware: All
OS: All
Status: CONFIRMED
  Severity: critical
  Priority: Normal
 Component: other
  Assignee: dev@dpdk.org
  Reporter: david.march...@6wind.com
  Target Milestone: ---

This problem is produced when a memory free event reaches the mlx5 callback,
but no mlx5 device has been initialised (yet).

Looking at the code, the mlx5 driver always register a memory callback:

RTE_INIT(rte_mlx5_pmd_init);
static void
rte_mlx5_pmd_init(void)
{
...
rte_mem_event_callback_register("MLX5_MEM_EVENT_CB",
mlx5_mr_mem_event_cb, NULL);
}

When invoked, this callback tries to take a lock:

void
mlx5_mr_mem_event_cb(enum rte_mem_event event_type, const void *addr,   
 size_t len, void *arg __rte_unused)
{   
struct priv *priv;  
struct mlx5_dev_list *dev_list = &mlx5_shared_data->mem_event_cb_list;  

switch (event_type) {   
case RTE_MEM_EVENT_FREE:
rte_rwlock_write_lock(&mlx5_shared_data->mem_event_rwlock); 
/* Iterate all the existing mlx5 devices. */

But this lock is not initialised unless a mlx5 device has been probed, since
its init is done in mlx5_prepare_shared_data() called from mlx5_pci_probe().


Reproducing the issue is not direct, I forced an allocation / liberation in the
testpmd code to make sure a free event would be triggered:

root@ubuntu1604:~/dpdk# git diff
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 35cf266..79c9531 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2772,6 +2772,8 @@ main(int argc, char** argv)
}
 #endif

+   rte_free(rte_malloc(NULL, 1000, 0));
+
 #ifdef RTE_LIBRTE_CMDLINE
if (strlen(cmdline_filename) != 0)
cmdline_read_from_file(cmdline_filename);


Then:

root@ubuntu1604:~/dpdk# LD_LIBRARY_PATH=/root/rdma-core/build/lib
./build/app/testpmd --log-level .*,8 -c 0x6 -- -i --total-num-mbufs 2048
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 0 on socket 0
EAL: Detected lcore 2 as core 0 on socket 0
...
EAL: Trying to obtain current memory policy.
EAL: Setting policy MPOL_PREFERRED for socket 0
EAL: Restoring previous memory policy: 0
EAL: Calling mem event callback 'MLX5_MEM_EVENT_CB:(nil)'EAL: request:
mp_malloc_sync
EAL: Heap on socket 0 was expanded by 90MB
Interactive-mode selected
testpmd: create a new mbuf pool : n=2048, size=2176,
socket=0
testpmd: preferred mempool ops selected: ring_mp_mc
EAL: Trying to obtain current memory policy.
EAL: Setting policy MPOL_PREFERRED for socket 0
EAL: Restoring previous memory policy: 0
EAL: alloc_pages_on_heap(): couldn't allocate physically contiguous space
EAL: Trying to obtain current memory policy.
EAL: Setting policy MPOL_PREFERRED for socket 0
EAL: Restoring previous memory policy: 0
EAL: Calling mem event callback 'MLX5_MEM_EVENT_CB:(nil)'EAL: request:
mp_malloc_sync
EAL: Heap on socket 0 was expanded by 8MB
Done
EAL: Trying to obtain current memory policy.
EAL: Setting policy MPOL_PREFERRED for socket 0
EAL: Restoring previous memory policy: 0
EAL: Calling mem event callback 'MLX5_MEM_EVENT_CB:(nil)'EAL: request:
mp_malloc_sync
EAL: Heap on socket 0 was expanded by 10MB
EAL: Calling mem event callback 'MLX5_MEM_EVENT_CB:(nil)'Segmentation fault
(core dumped)


root@ubuntu1604:~/dpdk# gdb ./build/app/testpmd core
...
Core was generated by `./build/app/testpmd --log-level .*,8 -c 0x6 -- -i
--total-num-mbufs 2048'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  rte_rwlock_write_lock (rwl=) at
/root/dpdk/build/include/generic/rte_rwlock.h:103
103 x = rwl->cnt;
[Current thread is 1 (Thread 0x7f1871022c00 (LWP 5732))]
(gdb) bt
#0  rte_rwlock_write_lock (rwl=) at
/root/dpdk/build/include/generic/rte_rwlock.h:103
#1  mlx5_mr_mem_event_cb (event_type=RTE_MEM_EVENT_FREE, addr=0x7f1474a0,
len=10485760, arg=) at /root/dpdk/drivers/net/mlx5/mlx5_mr.c:884
#2  0x0054ae86 in eal_memalloc_mem_event_notify ()
#3  0x00558994 in malloc_heap_free ()
#4  0x0055445f in rte_free ()
#5  0x00477231 in main ()

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

[dpdk-dev] i40evf: Problem with the statistics

[Mridula V Gangadharan]

Hi,

I am testing packet drops scenario by setting the MTU size.
My setup have i40evf driver. I set the dpdk interface's MTU size to 1800.
I am sending 100 packets of size 1918 each.
I am expecting the drop counter to increment.
rte_eth_stats_get() returns i.packets with number of packets I sent.
There are no drop counters incrementing. Also my application is not recieving 
any packets.
Is there some issue with dpdk statistics?
xstats  output is as follows. It is not showing any drops but rx_good_bytes 
counts are incrementing.



NIC extended statistics for port 1

rx_good_packets: 656
tx_good_packets: 556
rx_good_bytes: 225160
tx_good_bytes: 33360
rx_errors: 0
tx_errors: 0
rx_mbuf_allocation_errors: 0
rx_q0packets: 0
rx_q0bytes: 0
rx_q0errors: 0
tx_q0packets: 0
tx_q0bytes: 0
rx_bytes: 225160
rx_unicast_packets: 656
rx_multicast_packets: 0
rx_broadcast_packets: 0
rx_dropped_packets: 0
rx_unknown_protocol_packets: 0
tx_bytes: 33360
tx_unicast_packets: 556
tx_multicast_packets: 0
tx_broadcast_packets: 0
tx_dropped_packets: 0
tx_error_packets: 0

Thanks and Regards,
Mridula


Disclaimer:
This communication (including any attachments) is intended for the use of the 
intended recipient(s) only and may contain information that is considered 
confidential, proprietary, sensitive and/or otherwise legally protected. Any 
unauthorized use or dissemination of this communication is strictly prohibited. 
If you have received this communication in error, please immediately notify the 
sender by return e-mail message and delete all copies of the original 
communication. Thank you for your cooperation.

[dpdk-dev] [PATCH] version: 18.05.0

[Thomas Monjalon]

Signed-off-by: Thomas Monjalon 
---
 lib/librte_eal/common/include/rte_version.h | 4 ++--
 meson.build | 2 +-
 pkg/dpdk.spec   | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/librte_eal/common/include/rte_version.h 
b/lib/librte_eal/common/include/rte_version.h
index c1d735204..6e2a23624 100644
--- a/lib/librte_eal/common/include/rte_version.h
+++ b/lib/librte_eal/common/include/rte_version.h
@@ -42,14 +42,14 @@ extern "C" {
 /**
  * Extra string to be appended to version number
  */
-#define RTE_VER_SUFFIX "-rc"
+#define RTE_VER_SUFFIX ""
 
 /**
  * Patch release number
  *   0-15 = release candidates
  *   16   = release
  */
-#define RTE_VER_RELEASE 6
+#define RTE_VER_RELEASE 16
 
 /**
  * Macro to compute a version number usable for comparisons
diff --git a/meson.build b/meson.build
index 29a7257f7..5b2234f09 100644
--- a/meson.build
+++ b/meson.build
@@ -2,7 +2,7 @@
 # Copyright(c) 2017 Intel Corporation
 
 project('DPDK', 'C',
-   version: '18.05-rc6',
+   version: '18.05.0',
license: 'BSD',
default_options: ['buildtype=release', 'default_library=static'],
meson_version: '>= 0.41'
diff --git a/pkg/dpdk.spec b/pkg/dpdk.spec
index 23dec98f4..bba69dd13 100644
--- a/pkg/dpdk.spec
+++ b/pkg/dpdk.spec
@@ -2,7 +2,7 @@
 # Copyright 2014 6WIND S.A.
 
 Name: dpdk
-Version: 18.02
+Version: 18.05
 Release: 1
 Packager: packag...@6wind.com
 URL: http://dpdk.org
-- 
2.16.2

Re: [dpdk-dev] [dpdk-techboard] [PATCH] version: 18.05.0

[Hemant Agrawal]

HI Thomas,

-Original Message-
From: techboard [mailto:techboard-boun...@dpdk.org] On Behalf Of Thomas Monjalon
Sent: Wednesday, May 30, 2018 7:34 PM
To: dev@dpdk.org
Cc: techbo...@dpdk.org
Subject: [dpdk-techboard] [PATCH] version: 18.05.0

Signed-off-by: Thomas Monjalon 
---
 lib/librte_eal/common/include/rte_version.h | 4 ++--
 meson.build | 2 +-
 pkg/dpdk.spec   | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/librte_eal/common/include/rte_version.h 
b/lib/librte_eal/common/include/rte_version.h
index c1d735204..6e2a23624 100644
--- a/lib/librte_eal/common/include/rte_version.h
+++ b/lib/librte_eal/common/include/rte_version.h
@@ -42,14 +42,14 @@ extern "C" {
 /**
  * Extra string to be appended to version number
  */
-#define RTE_VER_SUFFIX "-rc"
+#define RTE_VER_SUFFIX ""
 
 /**
  * Patch release number
  *   0-15 = release candidates
  *   16   = release
  */
-#define RTE_VER_RELEASE 6
+#define RTE_VER_RELEASE 16
 
 /**
  * Macro to compute a version number usable for comparisons diff --git 
a/meson.build b/meson.build index 29a7257f7..5b2234f09 100644
--- a/meson.build
+++ b/meson.build
@@ -2,7 +2,7 @@
 # Copyright(c) 2017 Intel Corporation
 
 project('DPDK', 'C',
-   version: '18.05-rc6',
+   version: '18.05.0',
license: 'BSD',
default_options: ['buildtype=release', 'default_library=static'],
meson_version: '>= 0.41'
diff --git a/pkg/dpdk.spec b/pkg/dpdk.spec index 23dec98f4..bba69dd13 100644
--- a/pkg/dpdk.spec
+++ b/pkg/dpdk.spec
@@ -2,7 +2,7 @@
 # Copyright 2014 6WIND S.A.
 
 Name: dpdk
-Version: 18.02
+Version: 18.05
 Release: 1
 Packager: packag...@6wind.com
 URL: 
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdpdk.org&data=02%7C01%7Chemant.agrawal%40nxp.com%7C48615abe3db24f0c85b808d5c6363c53%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636632858604736852&sdata=mqnW8I%2BcLE7DFhPYZLWj1d5VBlTREvx5cntvW4HUUZA%3D&reserved=0

[Hemant]  Just wondering, if you think that packager should be changed to 
dpdk.org?

Otherwise
Acked

--
2.16.2

[dpdk-dev] [PATCH] net/ixgbe: fix crash on detach

[Pablo de Lara]

When detaching a port bound to ixgbe PMD, if the port
does not have any VFs, *vfinfo is not set and there is
a NULL dereference attempt, when calling
rte_eth_switch_domain_free(), which expects VFs to be used,
causing a segmentation fault.

Steps to reproduce:

./testpmd -- -i
testpmd> port stop all
testpmd> port close all
testpmd> port detach 0

Fixes: cf80ba6e2038 ("net/ixgbe: add support for representor ports")

Reported-by: Anatoly Burakov 
Signed-off-by: Pablo de Lara 
---
 drivers/net/ixgbe/ixgbe_pf.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_pf.c b/drivers/net/ixgbe/ixgbe_pf.c
index 4d199c802..c381acf44 100644
--- a/drivers/net/ixgbe/ixgbe_pf.c
+++ b/drivers/net/ixgbe/ixgbe_pf.c
@@ -135,14 +135,14 @@ void ixgbe_pf_host_uninit(struct rte_eth_dev *eth_dev)
RTE_ETH_DEV_SRIOV(eth_dev).def_vmdq_idx = 0;
RTE_ETH_DEV_SRIOV(eth_dev).def_pool_q_idx = 0;
 
-   ret = rte_eth_switch_domain_free((*vfinfo)->switch_domain_id);
-   if (ret)
-   PMD_INIT_LOG(WARNING, "failed to free switch domain: %d", ret);
-
vf_num = dev_num_vf(eth_dev);
if (vf_num == 0)
return;
 
+   ret = rte_eth_switch_domain_free((*vfinfo)->switch_domain_id);
+   if (ret)
+   PMD_INIT_LOG(WARNING, "failed to free switch domain: %d", ret);
+
rte_free(*vfinfo);
*vfinfo = NULL;
 }
-- 
2.13.6

Re: [dpdk-dev] [dpdk-techboard] [PATCH] version: 18.05.0

[Thomas Monjalon]

30/05/2018 16:09, Hemant Agrawal:
> --- a/pkg/dpdk.spec
> +++ b/pkg/dpdk.spec
> @@ -2,7 +2,7 @@
>  # Copyright 2014 6WIND S.A.
>  
>  Name: dpdk
> -Version: 18.02
> +Version: 18.05
>  Release: 1
>  Packager: packag...@6wind.com
> 
> [Hemant]  Just wondering, if you think that packager should be changed to 
> dpdk.org?

It needs to be discussed.
It is a template for RPM and I am not sure this field is used anyway.
Can be changed during 18.08.

[dpdk-dev] [PATCH] net/mlx5: only register memory callback when probing a device

[David Marchand]

The callback should be invoked only for memory that has been registered
in a device, hence, no need to track cleanup events if no device is
present.

Bugzilla-ID: 56
Fixes: 974f1e7ef146 ("net/mlx5: add new memory region support")

Signed-off-by: David Marchand 
---
 drivers/net/mlx5/mlx5.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index d77a20db4..601d03f71 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -138,6 +138,8 @@ mlx5_prepare_shared_data(void)
LIST_INIT(&mlx5_shared_data->mem_event_cb_list);
rte_rwlock_init(&mlx5_shared_data->mem_event_rwlock);
}
+   rte_mem_event_callback_register("MLX5_MEM_EVENT_CB",
+   mlx5_mr_mem_event_cb, NULL);
}
rte_spinlock_unlock(&mlx5_shared_data_lock);
 }
@@ -1460,8 +1462,6 @@ rte_mlx5_pmd_init(void)
}
mlx5_glue->fork_init();
rte_pci_register(&mlx5_driver);
-   rte_mem_event_callback_register("MLX5_MEM_EVENT_CB",
-   mlx5_mr_mem_event_cb, NULL);
 }
 
 RTE_PMD_EXPORT_NAME(net_mlx5, __COUNTER__);
-- 
2.11.0

[dpdk-dev] [PATCH] maintainers: claim responsibility for bonding PMD

[Chas Williams]

Add myself as co-maintainer for bonding driver and related materials.

Signed-off-by: Chas Williams 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7398749d7..4667fa7fb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -430,6 +430,7 @@ F: doc/guides/nics/features/default.ini
 
 Link bonding
 M: Declan Doherty 
+M: Chas Williams 
 F: drivers/net/bonding/
 F: doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst
 F: test/test/test_link_bonding*
-- 
2.14.3

[dpdk-dev] [PATCH] mem: add missing newline in log message

[David Marchand]

Fixes: 56efb4c11753 ("malloc: support callbacks on memory events")

Signed-off-by: David Marchand 
---
 lib/librte_eal/common/eal_common_memalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_eal/common/eal_common_memalloc.c 
b/lib/librte_eal/common/eal_common_memalloc.c
index 3005ef980..1d41ea112 100644
--- a/lib/librte_eal/common/eal_common_memalloc.c
+++ b/lib/librte_eal/common/eal_common_memalloc.c
@@ -243,7 +243,7 @@ eal_memalloc_mem_event_notify(enum rte_mem_event event, 
const void *start,
rte_rwlock_read_lock(&mem_event_rwlock);
 
TAILQ_FOREACH(entry, &mem_event_callback_list, next) {
-   RTE_LOG(DEBUG, EAL, "Calling mem event callback '%s:%p'",
+   RTE_LOG(DEBUG, EAL, "Calling mem event callback '%s:%p'\n",
entry->name, entry->arg);
entry->clb(event, start, len, entry->arg);
}
-- 
2.11.0

Re: [dpdk-dev] [PATCH] mem: add missing newline in log message

[Burakov, Anatoly]

On 30-May-18 3:45 PM, David Marchand wrote:

Fixes: 56efb4c11753 ("malloc: support callbacks on memory events")

Signed-off-by: David Marchand 
---


Acked-by: Anatoly Burakov 

--
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH] net/ixgbe: fix crash on detach

[Burakov, Anatoly]

On 30-May-18 7:31 AM, Pablo de Lara wrote:

When detaching a port bound to ixgbe PMD, if the port
does not have any VFs, *vfinfo is not set and there is
a NULL dereference attempt, when calling
rte_eth_switch_domain_free(), which expects VFs to be used,
causing a segmentation fault.

Steps to reproduce:

./testpmd -- -i
testpmd> port stop all
testpmd> port close all
testpmd> port detach 0

Fixes: cf80ba6e2038 ("net/ixgbe: add support for representor ports")

Reported-by: Anatoly Burakov 
Signed-off-by: Pablo de Lara 
---


Tested-by: Anatoly Burakov 

--
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH] maintainers: claim responsibility for bonding PMD

[Ferruh Yigit]

On 5/30/2018 3:44 PM, Chas Williams wrote:
> Add myself as co-maintainer for bonding driver and related materials.
> 
> Signed-off-by: Chas Williams 

Acked-by: Ferruh Yigit 


Thanks Chas for step in for support!

Re: [dpdk-dev] [PATCH v1] doc: add SPDX Licence to doc files

[Kovacevic, Marko]

> > [Hemant] I got following recommendation from the Linux Foundation legal:
> > "For files that are e.g. release scripts and documentation, these are
> > typically understood to consist of contributions that are copyrighted
> > by their contributors. So even if there isn't a notice in the file, it
> > would still generally be understood to be subject to its contributors'
> > copyrights and to be licensed out under an open source license.
> >
> > As you suggested, adding copyright and license notices can help
> > clarify these specifics for downstream uses. We have recommended as
> > best practices that projects add something like "Copyright The
> > _ Project" or "Copyright The __ contributors". I think
> > your suggestion of "Copyright The DPDK Community" is fine. And yes,
> > I'd recommend including the appropriate license notice and/or SPDX
> > identifier in these files as well.
> > Just to be clear, also, we _don't_ recommend removing pre-existing
> > copyright notices unless you are the copyright holder in question.
> > It's generally understood that it's fine to add general copyright
> > notices where accurate, but only the copyright holder should remove or
> > modify their own notices. "
> >
> > [Hemant] So, "The DPDK Project" or "The DPDK contributors" or "The
> > DPDK community" - anything is fine, we have to use just one of these
> > consistently.


After some discussion intel would prefer to keep the license as is on the 
release notes. 
Other contributors/companies can add respective SPDX license for their 
contributions

Marko K.

Re: [dpdk-dev] [PATCH] net/ixgbe: fix crash on detach

[Remy Horton]

On 30/05/2018 07:31, Pablo de Lara wrote:
[..]

Reported-by: Anatoly Burakov 
Signed-off-by: Pablo de Lara 


Acked-by: Remy Horton 

Re: [dpdk-dev] [PATCH v1] doc: add SPDX Licence to doc files

[Ferruh Yigit]

On 5/30/2018 4:18 PM, Kovacevic, Marko wrote:
>>> [Hemant] I got following recommendation from the Linux Foundation legal:
>>> "For files that are e.g. release scripts and documentation, these are
>>> typically understood to consist of contributions that are copyrighted
>>> by their contributors. So even if there isn't a notice in the file, it
>>> would still generally be understood to be subject to its contributors'
>>> copyrights and to be licensed out under an open source license.
>>>
>>> As you suggested, adding copyright and license notices can help
>>> clarify these specifics for downstream uses. We have recommended as
>>> best practices that projects add something like "Copyright The
>>> _ Project" or "Copyright The __ contributors". I think
>>> your suggestion of "Copyright The DPDK Community" is fine. And yes,
>>> I'd recommend including the appropriate license notice and/or SPDX
>>> identifier in these files as well.
>>> Just to be clear, also, we _don't_ recommend removing pre-existing
>>> copyright notices unless you are the copyright holder in question.
>>> It's generally understood that it's fine to add general copyright
>>> notices where accurate, but only the copyright holder should remove or
>>> modify their own notices. "
>>>
>>> [Hemant] So, "The DPDK Project" or "The DPDK contributors" or "The
>>> DPDK community" - anything is fine, we have to use just one of these
>>> consistently.
> 
> 
> After some discussion intel would prefer to keep the license as is on the 
> release notes. 
> Other contributors/companies can add respective SPDX license for their 
> contributions

Hi Hemant,

Would it matter if keep the Intel copyright in the release notes that already
have it, and add "The DPDK contributors" as a new copyright holder?

And for the ones don't have any copyright, add only "The DPDK contributors".

It is sometimes not easy call to give a go to remove an existing copyright, even
for release notes ...

Thanks,
ferruh

Re: [dpdk-dev] [PATCH] maintainers: claim responsibility for bonding PMD

[Thomas Monjalon]

30/05/2018 16:52, Ferruh Yigit:
> On 5/30/2018 3:44 PM, Chas Williams wrote:
> > Add myself as co-maintainer for bonding driver and related materials.
> > 
> > Signed-off-by: Chas Williams 
> 
> Acked-by: Ferruh Yigit 
> 
> 
> Thanks Chas for step in for support!

Applied, thanks for helping Chas

Re: [dpdk-dev] [PATCH] net/mlx5: only register memory callback when probing a device

[Yongseok Koh]

> On May 30, 2018, at 7:42 AM, David Marchand  wrote:
> 
> The callback should be invoked only for memory that has been registered
> in a device, hence, no need to track cleanup events if no device is
> present.
> 
> Bugzilla-ID: 56
> Fixes: 974f1e7ef146 ("net/mlx5: add new memory region support")
> 
> Signed-off-by: David Marchand 
> ---

Good finding! Thank you so much for the patch.
Patch is good. Just to be sure, I've run traffic with testpmd and also run
multi-process test examples with traffic. It runs well.

Acked-by: Yongseok Koh 
 
Thanks

> drivers/net/mlx5/mlx5.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
> index d77a20db4..601d03f71 100644
> --- a/drivers/net/mlx5/mlx5.c
> +++ b/drivers/net/mlx5/mlx5.c
> @@ -138,6 +138,8 @@ mlx5_prepare_shared_data(void)
>   LIST_INIT(&mlx5_shared_data->mem_event_cb_list);
>   rte_rwlock_init(&mlx5_shared_data->mem_event_rwlock);
>   }
> + rte_mem_event_callback_register("MLX5_MEM_EVENT_CB",
> + mlx5_mr_mem_event_cb, NULL);
>   }
>   rte_spinlock_unlock(&mlx5_shared_data_lock);
> }
> @@ -1460,8 +1462,6 @@ rte_mlx5_pmd_init(void)
>   }
>   mlx5_glue->fork_init();
>   rte_pci_register(&mlx5_driver);
> - rte_mem_event_callback_register("MLX5_MEM_EVENT_CB",
> - mlx5_mr_mem_event_cb, NULL);
> }
> 
> RTE_PMD_EXPORT_NAME(net_mlx5, __COUNTER__);
> -- 
> 2.11.0
> 

Re: [dpdk-dev] [PATCH] net/mlx5: only register memory callback when probing a device

[Ferruh Yigit]

On 5/30/2018 3:42 PM, David Marchand wrote:
> The callback should be invoked only for memory that has been registered
> in a device, hence, no need to track cleanup events if no device is
> present.
> 
> Bugzilla-ID: 56
> Fixes: 974f1e7ef146 ("net/mlx5: add new memory region support")
> 
> Signed-off-by: David Marchand 

Tested-by: Ferruh Yigit 


(Reproduced using the suggested tespmd update in Bug 56, verified this patch
fixes it.)

Re: [dpdk-dev] [PATCH] net/mlx5: only register memory callback when probing a device

[David Marchand]

On Wed, May 30, 2018 at 5:59 PM, Yongseok Koh  wrote:
>> On May 30, 2018, at 7:42 AM, David Marchand  wrote:
>>
>> The callback should be invoked only for memory that has been registered
>> in a device, hence, no need to track cleanup events if no device is
>> present.
>>
>> Bugzilla-ID: 56
>> Fixes: 974f1e7ef146 ("net/mlx5: add new memory region support")
>>
>> Signed-off-by: David Marchand 
>> ---
>
> Good finding! Thank you so much for the patch.
> Patch is good. Just to be sure, I've run traffic with testpmd and also run
> multi-process test examples with traffic. It runs well.
>
> Acked-by: Yongseok Koh 

Well, this is a quick fix, the mlx5_prepare_shared_data() now does
more than initialising the shared data...
Might be better to revisit later, but this should do the job for 18.05.

Thanks.

-- 
David Marchand

Re: [dpdk-dev] Compilation of MLX5 driver

[Nitin Katiyar]

Hi,
I was compiling 17.05.02.
Regards,
Nitin

-Original Message-
From: Nélio Laranjeiro [mailto:nelio.laranje...@6wind.com] 
Sent: Wednesday, May 30, 2018 6:42 PM
To: Nitin Katiyar 
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Compilation of MLX5 driver

Hi,

On Wed, May 30, 2018 at 11:54:31AM +, Nitin Katiyar wrote:
> Hi,
> I am trying to compile MLX5 PMD driver by setting 
> "CONFIG_RTE_LIBRTE_MLX5_PMD=y" and hitting following compilation error.
> 
> fatal error: infiniband/mlx5_hw.h: No such file or directory
> 
> I have installed MLNX_OFED _LINUX-4.2-1.2.0 on my Ubuntu 14.04 machine but 
> still hitting the same error. Am I missing some other package?

Which version of DPDK are you using (it is important to help)?

Regards,

-- 
Nélio Laranjeiro
6WIND

Re: [dpdk-dev] [dpdk-techboard] [PATCH] version: 18.05.0

[Hemant Agrawal]

Yes, we can postpone it for 18.08

Sent from my Android phone using TouchDown (www.symantec.com)

-Original Message-
From: Thomas Monjalon [tho...@monjalon.net]
Received: Wednesday, 30 May 2018, 8:08PM
To: Hemant Agrawal [hemant.agra...@nxp.com]
CC: dev@dpdk.org [dev@dpdk.org]; techbo...@dpdk.org [techbo...@dpdk.org]
Subject: Re: [dpdk-techboard] [PATCH] version: 18.05.0

30/05/2018 16:09, Hemant Agrawal:
> --- a/pkg/dpdk.spec
> +++ b/pkg/dpdk.spec
> @@ -2,7 +2,7 @@
>  # Copyright 2014 6WIND S.A.
>
>  Name: dpdk
> -Version: 18.02
> +Version: 18.05
>  Release: 1
>  Packager: packag...@6wind.com
>
> [Hemant]  Just wondering, if you think that packager should be changed to 
> dpdk.org?

It needs to be discussed.
It is a template for RPM and I am not sure this field is used anyway.
Can be changed during 18.08.

[dpdk-dev] [Bug 57] ixgbe crash on detach when no VF is created

[bugzilla]

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

Bug ID: 57
   Summary: ixgbe crash on detach when no VF is created
   Product: DPDK
   Version: 18.05
  Hardware: All
OS: Linux
Status: CONFIRMED
  Severity: normal
  Priority: Normal
 Component: ethdev
  Assignee: dev@dpdk.org
  Reporter: ferruh.yi...@intel.com
  Target Milestone: ---

Issue reported by Anatoly Burakov 


Steps to reproduce (with ixgbe port):
./testpmd -- -i
> port stop all
> port close all
> port detach 0


The reason of the crash is:
(*vfinfo) is a null pointer at that point, -> dereferences it. 


The issue is introduced in:
commit cf80ba6e2038a54b6c5ba62ce4200234f5aa3880
Author: Declan Doherty 
Date:   Thu Apr 26 11:41:05 2018 +0100

net/ixgbe: add support for representor ports

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

[dpdk-dev] [PATCH] doc: add ixgbe detach crash known issue in release notes

[Ferruh Yigit]

Signed-off-by: Ferruh Yigit 
---
 doc/guides/rel_notes/release_18_05.rst | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/doc/guides/rel_notes/release_18_05.rst 
b/doc/guides/rel_notes/release_18_05.rst
index 42a5b37c9..c8c4797aa 100644
--- a/doc/guides/rel_notes/release_18_05.rst
+++ b/doc/guides/rel_notes/release_18_05.rst
@@ -625,6 +625,13 @@ Known Issues
 
   Bugzilla entry: https://dpdk.org/tracker/show_bug.cgi?id=53
 
+* **ixgbe PMD crash on hotplug detach when no VF created.**
+
+  ixgbe PMD uninit path cause null pointer dereference because of port 
representor
+  cleanup when number of VF is zero.
+
+  Bugzilla entry: https://dpdk.org/tracker/show_bug.cgi?id=57
+
 * **Bonding PMD may fail to accept new slaves in certain conditions.**
 
   In certain conditions when using testpmd,
-- 
2.14.3

Re: [dpdk-dev] [PATCH] net/ixgbe: fix crash on detach

[Ferruh Yigit]

On 5/30/2018 4:21 PM, Remy Horton wrote:
> 
> On 30/05/2018 07:31, Pablo de Lara wrote:
> [..]
>> Reported-by: Anatoly Burakov 
>> Signed-off-by: Pablo de Lara 
> 
> Acked-by: Remy Horton 

The fix was late for the release.

A patch to document issue as known issue for this release sent:
https://dpdk.org/dev/patchwork/patch/40520/

Re: [dpdk-dev] [PATCH] doc: add ixgbe detach crash known issue in release notes

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Wednesday, May 30, 2018 6:46 PM
> To: Thomas Monjalon ; Mcnamara, John
> ; Kovacevic, Marko 
> Cc: dev@dpdk.org; Yigit, Ferruh 
> Subject: [dpdk-dev] [PATCH] doc: add ixgbe detach crash known issue in release
> notes
> 
> Signed-off-by: Ferruh Yigit 

Acked-by: Pablo de Lara 

Re: [dpdk-dev] [PATCH] net/mlx5: only register memory callback when probing a device

[Thomas Monjalon]

30/05/2018 18:04, David Marchand:
> On Wed, May 30, 2018 at 5:59 PM, Yongseok Koh  wrote:
> >> On May 30, 2018, at 7:42 AM, David Marchand  
> >> wrote:
> >>
> >> The callback should be invoked only for memory that has been registered
> >> in a device, hence, no need to track cleanup events if no device is
> >> present.
> >>
> >> Bugzilla-ID: 56
> >> Fixes: 974f1e7ef146 ("net/mlx5: add new memory region support")
> >>
> >> Signed-off-by: David Marchand 
> >> ---
> >
> > Good finding! Thank you so much for the patch.
> > Patch is good. Just to be sure, I've run traffic with testpmd and also run
> > multi-process test examples with traffic. It runs well.
> >
> > Acked-by: Yongseok Koh 
> 
> Well, this is a quick fix, the mlx5_prepare_shared_data() now does
> more than initialising the shared data...
> Might be better to revisit later, but this should do the job for 18.05.

Applied, thanks

Re: [dpdk-dev] [PATCH] mem: add missing newline in log message

[Thomas Monjalon]

30/05/2018 16:47, Burakov, Anatoly:
> On 30-May-18 3:45 PM, David Marchand wrote:
> > Fixes: 56efb4c11753 ("malloc: support callbacks on memory events")
> > 
> > Signed-off-by: David Marchand 
> > ---
> 
> Acked-by: Anatoly Burakov 

Applied, thanks

Re: [dpdk-dev] [PATCH v5 2/2] doc: add a guide doc for cross compiling from x86

[Thomas Monjalon]

29/05/2018 12:43, Gavin Hu:
> This is the guide for cross compiling ARM64 DPDK from X86 hosts.
> 
> Signed-off-by: Gavin Hu 
> Reviewed-by: Steve Capper 
> Reviewed-by: Honnappa Nagarahalli 
> Reviewed-by: Marko Kovacevic 
> Reviewed-by: Jerin Jacob 
> Reviewed-by: Thomas Monjalon 
> Reviewed-by: Bruce Richardson 

I have not reviewed the content of this patch.
And not sure Jerin and Bruce approve this v5.
Please make sure we fully agree with the patch before adding our
"Reviewed-by" tag.

Re: [dpdk-dev] [dpdk-stable] [PATCH] crypto/armv8: fix HMAC supported digest sizes

[Thomas Monjalon]

29/05/2018 13:28, Akhil Goyal:
> On 5/29/2018 4:15 PM, Anoob Joseph wrote:
> > For HMAC algorithms (SHAx-HMAC), the supported digest sizes are not a
> > fixed value, but a range between 1 and the maximum digest size for those
> > algorithms.
> >
> > Fixes: 0f89def76127 ("crypto/armv8: fix HMAC supported key sizes")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Anoob Joseph 
> > Signed-off-by: Sachin Saxena 
> > ---
> Acked-by: Akhil Goyal 

Applied, thanks

Re: [dpdk-dev] [PATCH] doc: add ixgbe detach crash known issue in release notes

[Thomas Monjalon]

> > Signed-off-by: Ferruh Yigit 
> 
> Acked-by: Pablo de Lara 

Applied, thanks

Re: [dpdk-dev] [PATCH v5 2/2] doc: add a guide doc for cross compiling from x86

[Jerin Jacob]

-Original Message-
> Date: Tue, 29 May 2018 18:43:36 +0800
> From: Gavin Hu 
> To: dev@dpdk.org
> CC: gavin...@arm.com
> Subject: [dpdk-dev] [PATCH v5 2/2] doc: add a guide doc for cross compiling
>  from x86
> X-Mailer: git-send-email 2.1.4
> 
> +   1. EXTRA_CFLAGS and EXTRA_LDFLAGS should be added to include the NUMA 
> headers and link the library respectively,
> +   if the step :ref:`argment_the_cross_toolcain_with_numa_support` was 
> skipped therefore the toolchain was not
> +   argmented with NUMA support.
> +
> +   2. RTE_DEVEL_BUILD has to be disabled, otherwise the numa.h file gets

If the warnings are from numa.h then please use -isystem  
instead of disabling RTE_DEVEL_BUILD.


> +   a lot of compiling errors of Werror=cast-qual, Werror=strict-prototypes 
> and Werror=old-style-definition.
> +   An example is given below:
> +
> +   .. code-block:: console
> +
> +  make -j CROSS=aarch64-linux-gnu- CONFIG_RTE_KNI_KMOD=n 
> CONFIG_RTE_EAL_IGB_UIO=n
> +  RTE_DEVEL_BUILD=n EXTRA_CFLAGS="-I/include" 
> EXTRA_LDFLAGS=
> +  "-L/lib -lnuma"
> +

As discussed earlier, meson cross build instruction is missing.


> diff --git a/doc/guides/linux_gsg/index.rst b/doc/guides/linux_gsg/index.rst
> index 2a7bdfe..077f930 100644
> --- a/doc/guides/linux_gsg/index.rst
> +++ b/doc/guides/linux_gsg/index.rst
> @@ -13,6 +13,7 @@ Getting Started Guide for Linux
>  intro
>  sys_reqs
>  build_dpdk
> +cross_build_dpdk_for_arm64
>  linux_drivers
>  build_sample_apps
>  enable_func
> -- 
> 2.1.4
> 

[dpdk-dev] [PATCH v1] doc: update release notes for 18.05

[John McNamara]

Fix grammar, spelling and formatting of DPDK 18.05 release notes.

Signed-off-by: John McNamara 
---
 doc/guides/rel_notes/release_18_05.rst | 308 +
 1 file changed, 157 insertions(+), 151 deletions(-)

diff --git a/doc/guides/rel_notes/release_18_05.rst 
b/doc/guides/rel_notes/release_18_05.rst
index 42a5b37..b24217e 100644
--- a/doc/guides/rel_notes/release_18_05.rst
+++ b/doc/guides/rel_notes/release_18_05.rst
@@ -45,7 +45,7 @@ New Features
 
   Memory subsystem has been reworked to support new functionality.
 
-  On Linux, support for reserving/unreserving hugepage memory at runtime was
+  On Linux, support for reserving/unreserving hugepage memory at runtime has 
been
   added, so applications no longer need to pre-reserve memory at startup. Due 
to
   reorganized internal workings of memory subsystem, any memory allocated
   through ``rte_malloc()`` or ``rte_memzone_reserve()`` is no longer guaranteed
@@ -53,64 +53,64 @@ New Features
 
   This functionality has introduced the following changes:
 
-  * ``rte_eal_get_physmem_layout()`` was removed
+  * ``rte_eal_get_physmem_layout()`` was removed.
   * A new flag for memzone reservation (``RTE_MEMZONE_IOVA_CONTIG``) was added
 to ensure reserved memory will be IOVA-contiguous, for use with device
-drivers and other cases requiring such memory
-  * New callbacks for memory allocation/deallocation events, allowing user (or
+drivers and other cases requiring such memory.
+  * New callbacks for memory allocation/deallocation events, allowing users (or
 drivers) to be notified of new memory being allocated or deallocated
-  * New callbacks for validating memory allocations above specified limit,
-allowing user to permit or deny memory allocations
+  * New callbacks for validating memory allocations above a specified limit,
+allowing user to permit or deny memory allocations.
   * A new command-line switch ``--legacy-mem`` to enable EAL behavior similar 
to
 how older versions of DPDK worked (memory segments that are 
IOVA-contiguous,
-but hugepages are reserved at startup only, and can never be released)
+but hugepages are reserved at startup only, and can never be released).
   * A new command-line switch ``--single-file-segments`` to put all memory
-segments within a segment list in a single file
+segments within a segment list in a single file.
   * A set of convenience function calls to look up and iterate over allocated
-memory segments
+memory segments.
   * ``-m`` and ``--socket-mem`` command-line arguments now carry an additional
 meaning and mark pre-reserved hugepages as "unfree-able", thereby acting as
 a mechanism guaranteeing minimum availability of hugepage memory to the
-application
+application.
 
   Reserving/unreserving memory at runtime is not currently supported on 
FreeBSD.
 
 * **Added bucket mempool driver.**
 
-  Added bucket mempool driver which provides a way to allocate contiguous
+  Added a bucket mempool driver which provides a way to allocate contiguous
   block of objects.
-  Number of objects in the block depends on how many objects fit in
-  RTE_DRIVER_MEMPOOL_BUCKET_SIZE_KB memory chunk which is build time option.
-  The number may be obtained using rte_mempool_ops_get_info() API.
-  Contiguous blocks may be allocated using rte_mempool_get_contig_blocks() API.
+  The number of objects in the block depends on how many objects fit in the
+  ``RTE_DRIVER_MEMPOOL_BUCKET_SIZE_KB`` memory chunk which is a build time 
option.
+  The number may be obtained using ``rte_mempool_ops_get_info()`` API.
+  Contiguous blocks may be allocated using ``rte_mempool_get_contig_blocks()`` 
API.
 
 * **Added support for port representors.**
 
-  The DPDK port representors (also known as "VF representors" in the specific
+  Added DPDK port representors (also known as "VF representors" in the specific
   context of VFs), which are to DPDK what the Ethernet switch device driver
   model (**switchdev**) is to Linux, and which can be thought as a software
   "patch panel" front-end for applications. DPDK port representors are
   implemented as additional virtual Ethernet device (**ethdev**) instances,
-  spawned on an as needed basis through configuration parameters passed to the
+  spawned on an as-needed basis through configuration parameters passed to the
   driver of the underlying device using devargs.
 
 * **Added support for VXLAN and NVGRE tunnel endpoint.**
 
   New actions types have been added to support encapsulation and decapsulation
   operations for a tunnel endpoint. The new action types are
-  RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_ENCAP, 
RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_DECAP,
-  RTE_FLOW_ACTION_TYPE_JUMP. New item type RTE_FLOW_ACTION_TYPE_MARK has been
-  added to match a flow against a previously marked flow. It also introduced 
shared
-  counter to flow API to counte for a group of flows.
+  ``RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_ENC

Re: [dpdk-dev] [PATCH v1] doc: update release notes for 18.05

[Thomas Monjalon]

30/05/2018 22:25, John McNamara:
> Fix grammar, spelling and formatting of DPDK 18.05 release notes.
> 
> Signed-off-by: John McNamara 

Applied with few more changes below, thanks.

--- b/doc/guides/rel_notes/release_18_05.rst
+++ a/doc/guides/rel_notes/release_18_05.rst
@@ -350,7 +350,7 @@ API Changes
Also, make sure to start the actual text at the margin.
=
 
-* service cores: Service cores no longer marked as experimental.
+* service cores: No longer marked as experimental.
 
   The service cores functions are no longer marked as experimental, and have
   become part of the normal DPDK API and ABI. Any future ABI changes will be
@@ -412,7 +412,7 @@ API Changes
 * ethdev: In struct ``struct rte_eth_dev_info``, field ``rte_pci_device 
*pci_dev``
   has been replaced with field ``struct rte_device *device``.
 
-* Changes to the semantics of ``rte_eth_dev_configure()`` parameters.
+* ethdev: Changes to the semantics of ``rte_eth_dev_configure()`` parameters.
 
   If both the ``nb_rx_q`` and ``nb_tx_q`` parameters are zero,
   ``rte_eth_dev_configure()`` will now use PMD-recommended queue sizes, or if
@@ -420,7 +420,7 @@ API Changes
   fall-back values. Previously setting both of the parameters to zero would
   have resulted in ``-EINVAL`` being returned.
 
-* Changes to the semantics of ``rte_eth_rx_queue_setup()`` parameters.
+* ethdev: Changes to the semantics of ``rte_eth_rx_queue_setup()`` parameters.
 
   If the ``nb_rx_desc`` parameter is zero, ``rte_eth_rx_queue_setup`` will
   now use the PMD-recommended Rx ring size, or in the case where the PMD
@@ -428,7 +428,7 @@ API Changes
   fall-back value. Previously, setting ``nb_rx_desc`` to zero would have
   resulted in an error.
 
-* Changes to the semantics of ``rte_eth_tx_queue_setup()`` parameters.
+* ethdev: Changes to the semantics of ``rte_eth_tx_queue_setup()`` parameters.
 
If the ``nb_tx_desc`` parameter is zero, ``rte_eth_tx_queue_setup`` will
now use the PMD-recommended Tx ring size, or in the case where the PMD
@@ -436,7 +436,7 @@ API Changes
fall-back value. Previously, setting ``nb_tx_desc`` to zero would have
resulted in an error.
 
-* ethdev: several changes were made to the flow API.
+* ethdev: Several changes were made to the flow API.
 
   * The unused DUP action was removed.
   * Actions semantics in flow rules: list order now matters ("first
@@ -479,12 +479,12 @@ API Changes
   * ``RTE_FLOW_ACTION_TYPE_MARK`` item type has been added to match a flow 
against
 a previously marked flow.
 
-* ethdev: change flow APIs regarding count action:
+* ethdev: Change flow APIs regarding count action:
 
   * ``rte_flow_create()`` API count action now requires the ``struct 
rte_flow_action_count``.
   * ``rte_flow_query()`` API parameter changed from action type to action 
structure.
 
-* ethdev: changes to offload API
+* ethdev: Changes to offload API
 
A pure per-port offloading isn't requested to be repeated in 
[rt]x_conf->offloads to
``rte_eth_[rt]x_queue_setup()``. Now any offloading enabled in 
``rte_eth_dev_configure()``
@@ -492,7 +492,7 @@ API Changes
not been enabled in ``rte_eth_dev_configure()`` and is requested to be 
enabled in
``rte_eth_[rt]x_queue_setup()`` must be per-queue type, or otherwise 
trigger an error log.
 
-* ethdev: runtime queue setup:
+* ethdev: Runtime queue setup
 
   ``rte_eth_rx_queue_setup`` and ``rte_eth_tx_queue_setup`` can be called after
   ``rte_eth_dev_start`` if the device supports runtime queue setup. The device 
driver can
@@ -520,7 +520,7 @@ ABI Changes
   structure and the offset of the fields remains the same on platforms
   with 64B cache line, but changes on other platforms.
 
-* mempool: Some Ops have changed.
+* mempool: Some ops have changed.
 
   A new callback ``calc_mem_size`` has been added to ``rte_mempool_ops``
   to allow customization of the required memory size calculation.
@@ -532,7 +532,7 @@ ABI Changes
   Callback ``register_memory_area`` has been removed from ``rte_mempool_ops``
   since the new callback ``populate`` may be used instead of it.
 
-* **Additional fields in rte_eth_dev_info.**
+* ethdev: Additional fields in rte_eth_dev_info.
 
   The ``rte_eth_dev_info`` structure has had two extra entries appended to the
   end of it: ``default_rxportconf`` and ``default_txportconf``. Each of these
@@ -553,32 +553,19 @@ ABI Changes
   sanity fix in the VLAN pattern item (``struct rte_flow_item_vlan``) and
   new transfer attribute (``struct rte_flow_attr``).
 
-**New parameter added to rte_bbdev_op_cap_turbo_dec.**
+* bbdev: New parameter added to rte_bbdev_op_cap_turbo_dec.
 
   A new parameter ``max_llr_modulus`` has been added to
   ``rte_bbdev_op_cap_turbo_dec`` structure to specify maximal LLR (likelihood
   ratio) absolute value.
 
-* **BBdev Queue Groups split into UL/DL Groups.**
+* bbdev: Queue Groups split into UL/DL Groups.
 
   Queue Groups have been split into UL/DL Grou

[dpdk-dev] [dpdk-announce] DPDK 18.05 - Venky Release

[Thomas Monjalon]

A new major release is available:
http://fast.dpdk.org/rel/dpdk-18.05.tar.xz

Some highlights:
- memory subsystem rework
- mempool bucket driver
- improved logging control
- better affinity of control threads
- uevent support for hotplug
- generic multi-process channel (IPC)
- secondary process support in virtual devices
- ethdev API for recommended Rx/Tx parameters
- ethdev API for various tunnels offloads
- ethdev API for interconnect/switch offloads
- ethdev port representor
- ethdev runtime queue setup​
- ethdev driver interfaces switched to new offloading API
- axgbe AMD driver
- bnxt update for Broadcom NetXtreme-S (Stingray)
- cxgbe VF driver for Chelsio T5/T6
- mlx5 striding RQ (multi packets buffer)
- mlx5 tunnels offloads extended
- sfc update for Solarflare XtremeScale X2xxx
- ifcvf vDPA driver for accelerated virtio with Intel FPGA
- vhost selective datapath
- vhost interrupt mode
- virtio-user server mode
- virtio-crypto driver
- tun support in tap driver
- bonding support of flow API
- ccp AMD crypto driver
- compressdev API
- Intel compressdev software driver
- Intel FPGA bus
- DPAA2 QDMA raw driver
- DPAA2 Command Interface raw driver
- eventdev crypto adapter
- eventdev timer adapter
- library to load and execute BPF
- IP pipeline enhancements
- improved meson build coverage

More details in the release notes:
http://dpdk.org/doc/guides/rel_notes/release_18_05.html

The statistics are crazy:
1716 patches from 160 authors
1663 files changed, 199587 insertions(+), 74247 deletions(-)

There are 55 new contributors (including authors, reviewers and testers).
Thanks to Ali Alnubani, Andy Green, Artem V. Andreev, Ashish Gupta,
Ben Shelton, Bin Huang, Boon Ang, Chuhong Yao, Dan Gora, Daniel Shelepov,
Darren Edamura, Gautam Dawar, Gavin Hu,  Govindarajulu Varadarajan,
Greg Tucker, Guido Barzini, Hao Wu, Hasan Alayli, Honnappa Nagarahalli,
Jan Remes, Jananee Parthasarathy, Jay Ding, Kamil Chalupnik, Lei Gong,
Louis Luo, Marcelo Ricardo Leitner, Marco Varlese, Mattias Rönnblom,
Michael Luo, Michael Wildt, Nachiketa Prachanda, Ning Li, Nitin Saxena,
Qingmin Liu, Rahul Gupta, Randy Schacher,  Ravi Kumar, Ray Jui,
Richard Houldsworth, Sachin Saxena, Scott Branden, Shagun Agrawal,
Shally Verma, Shraddha Joshi, Shweta Choudaha, Sirshak Das,
Solal Pirelli, Sunila Sahu, Takanari Hayama, Tianfei Zhang,
Venkatesh Srinivas, Xiaohua Zhang, Xiaoxin Peng, Yilun Xu and Yongji Xie.

Below is the number of patches per company with authors count:
658   Intel (58)
153   Mellanox (8)
149   Solarflare (8)
124   6WIND (8)
 96   NXP (6)
 91   Cavium (11)
 50   a...@warmcat.com (1)
 49   Broadcom (9)
 47   OKTET Labs (3)
 44   Microsoft (2)
 40   AMD (1)
 32   RedHat (4)
 26   Cisco (2)
 22   Semihalf (1)
 22   Chelsio (3)
 15   Netronome (1)
 15   AT&T (4)
 13   xiangxia.m@gmail.com (1)
 13   Huawei (2)
 11   CESNET (1)
  5   Wind River (3)
  5   Tencent (2)
  4   IBM (1)
  4   ARM (2)
  3   VMware (3)
  3   Linaro (1)

Based on Reviewed-by and Acked-by tags, the top reviewers are:
142   Ferruh Yigit
 72   Maxime Coquelin
 57   Pablo de Lara
 56   Bruce Richardson
 50   Qi Zhang
 46   Thomas Monjalon
 43   Jianfeng Tan
 40   Nelio Laranjeiro
 40   Adrien Mazarguil
 36   Shreyansh Jain
 35   Hemant Agrawal
 33   Jerin Jacob
 33   Andrew Rybchenko
 30   Akhil Goyal
 27   Olivier Matz
 27   Andy Moreton
 26   Anatoly Burakov
 23   Yongseok Koh
 22   Konstantin Ananyev
 22   Ivan Malov
 21   Stephen Hemminger


The new features for 18.08 must be submitted during next week,
in order to be reviewed and integrated during June.
The next release is expected to happen at the beginning of August.
The deadlines will be more strictly respected than for 18.05.
Because of shorter release cycle, the next release will be smaller.

Thanks everyone
It was a very special release


Venky Venkatesan, the creator and "Father of DPDK" passed away
in early April of this year.

Venky spent more than two decades working at Intel as an engineer
and architect attaining the well-deserved position of Intel Fellow.
His work spanned every aspect of networking and ranged from network
processors to ASICs to FPGAs to multi-core Intel architecture platforms.
In the mid to late 2000s, as Intel was moving away from network processors,
Venky came up with the idea of

Re: [dpdk-dev] [PATCH v2] rte_ring: clarify preemptible nature of ring algorithm

[Honnappa Nagarahalli]

No problem, it is still in programmer's guide :). I will rework the patch.
Thank you,
Honnappa

-Original Message-
From: Burakov, Anatoly 
Sent: Wednesday, May 30, 2018 2:48 AM
To: Honnappa Nagarahalli ; olivier.m...@6wind.com
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] rte_ring: clarify preemptible nature of ring 
algorithm

On 29-May-18 5:36 PM, Honnappa Nagarahalli wrote:
> I do not see the documentation regarding this in programmer's guide.

Hi

Apologies, it's not in rte_ring section, it's in programmer's guide for EAL:

http://www.dpdk.org/doc/guides/prog_guide/env_abstraction_layer.html#known-issues

Perhaps this could be referenced in the rte_ring (or indeed copied/moved there)?

--
Thanks,
Anatoly
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

[dpdk-dev] [Bug 49] Compile error kni_net.c unknown field ‘ndo_change_mtu’

[bugzilla]

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

balaji shankaran (balajiha...@gmail.com) changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 CC||balajiha...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from balaji shankaran (balajiha...@gmail.com) ---
Hi Chen,

I faced same issue in 17.11 and 18.02 versions. Moving to 18.05 I do not see
this issue.

P.S: I haven't spend time in root causing it and moved ahead with 18.05
version. Hope this information helps.

Thanks
Balaji S

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

Re: [dpdk-dev] Compilation of MLX5 driver

[Shahaf Shuler]

Wednesday, May 30, 2018 7:45 PM, Nitin Katiyar:
> 
> Hi,
> I was compiling 17.05.02.
> Regards,
> Nitin
> 
> -Original Message-
> From: Nélio Laranjeiro [mailto:nelio.laranje...@6wind.com]
> Sent: Wednesday, May 30, 2018 6:42 PM
> To: Nitin Katiyar 
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] Compilation of MLX5 driver
> 
> Hi,
> 
> On Wed, May 30, 2018 at 11:54:31AM +, Nitin Katiyar wrote:
> > Hi,
> > I am trying to compile MLX5 PMD driver by setting
> "CONFIG_RTE_LIBRTE_MLX5_PMD=y" and hitting following compilation
> error.
> >
> > fatal error: infiniband/mlx5_hw.h: No such file or directory

Can you list the files you have under /usr/include/infiniband ? 

> >
> > I have installed MLNX_OFED _LINUX-4.2-1.2.0 on my Ubuntu 14.04 machine
> but still hitting the same error. Am I missing some other package?
> 
> Which version of DPDK are you using (it is important to help)?
> 
> Regards,
> 
> --
> Nélio Laranjeiro
> 6WIND

Re: [dpdk-dev] [PATCH v1] doc: add SPDX Licence to doc files

[Hemant Agrawal]

Hi Ferruh,

On 5/30/2018 4:18 PM, Kovacevic, Marko wrote:
>>> [Hemant] I got following recommendation from the Linux Foundation legal:
>>> "For files that are e.g. release scripts and documentation, these 
>>> are typically understood to consist of contributions that are 
>>> copyrighted by their contributors. So even if there isn't a notice 
>>> in the file, it would still generally be understood to be subject to its 
>>> contributors'
>>> copyrights and to be licensed out under an open source license.
>>>
>>> As you suggested, adding copyright and license notices can help 
>>> clarify these specifics for downstream uses. We have recommended as 
>>> best practices that projects add something like "Copyright The 
>>> _ Project" or "Copyright The __ contributors". I 
>>> think your suggestion of "Copyright The DPDK Community" is fine. And 
>>> yes, I'd recommend including the appropriate license notice and/or 
>>> SPDX identifier in these files as well.
>>> Just to be clear, also, we _don't_ recommend removing pre-existing 
>>> copyright notices unless you are the copyright holder in question.
>>> It's generally understood that it's fine to add general copyright 
>>> notices where accurate, but only the copyright holder should remove 
>>> or modify their own notices. "
>>>
>>> [Hemant] So, "The DPDK Project" or "The DPDK contributors" or "The 
>>> DPDK community" - anything is fine, we have to use just one of these 
>>> consistently.
> 
> 
> After some discussion intel would prefer to keep the license as is on the 
> release notes. 
> Other contributors/companies can add respective SPDX license for their 
> contributions

Hi Hemant,

Would it matter if keep the Intel copyright in the release notes that already 
have it, and add "The DPDK contributors" as a new copyright holder?

And for the ones don't have any copyright, add only "The DPDK contributors".

[Hemant]  agree. There is no need to remove the existing copy rights. However 
the new files which are generic should have the generic copyright. 

It is sometimes not easy call to give a go to remove an existing copyright, 
even for release notes ...


Regards,
 Hemant