Re: [dpdk-dev] GSO/GRO support

[Kavanagh, Mark B]

>
>We, at Juniper Opencontrail have added software support for TCP send offload 
>and receive
>offload to DPDK.
>
>If the community is interested, we can publish/upstream it.
>
>Pl let us know what you think of it.

Hi Kiran,

I'd be very interested in this, with a view to integrating your APIs into Open 
vSwitch as a software fallback option for situations in which a particular NIC 
doesn't support TSO/LRO.

If/when you release the code I'd be happy to review and/or test it.

Thanks in advance,
Mark

>
>Thanks,
> Kiran

Re: [dpdk-dev] [PATCH v2] doc: fix unreadable images

[Thomas Monjalon]

2017-02-13 07:45, Jianfeng Tan:
> The images by below two commits are very unclear. Fix it.
> 
> Fixes: 50665deebda ("doc: add guide to use virtio-user for container 
> networking")
> Fixes: 0ba3870e755 ("doc: add guide to use virtio-user as exceptional path")
> 
> Suggested-by: Thomas Monjalon 
> Signed-off-by: Jianfeng Tan 

That's a lot better!

> +  transform="translate(2.9044,-261.723)">
> + Sheet.63
> + Contanier/App
> + 
> +  height="22.5"/>
> +  class="st8"/>
> +  v:langID="1033">Contanier/App

Please check wording. I've caught a typo above (Contanier).

Re: [dpdk-dev] [dpdk-users] Is PF-only driver allowed to upstream into dpdk?

[Ferruh Yigit]

On 2/13/2017 9:43 AM, Netala, Sameera wrote:
> Hi,

Hi Sameera,

> 
> I am currently working on a non-nic mode user space PCI driver which 
> processes custom packets from OCTEON 7xxx processor. As per the requirements, 
> DPDK is the best way to achieve this.

Can you please give more information about hardware? Is this an offload
engine?

> 
> Though I have seen few designs and sources that talk about dpdk pf drivers, I 
> am interested to know if such a driver with pf-only support and which doesn't 
> involve virtual functions will be allowed to upstream into DPDK sources.

There is no problem with PF only drivers, and there are already samples
of it in the project.

As long as driver is open source and for data path, it is good for
upstream. Please feel free to upstream your driver when it is ready.

The discussion about DPDK PF drivers was about if DPDK PF driver should
be in control path or not, this is high level project scope discussion.

Thanks,
ferruh

> 
> Thanks,
> Sameera
> 

[dpdk-dev] FW: [PATCH] net/i40e: fix vlan insert code redundance

[Yang, Qiming]

Hi, Ferruh

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yang, Qiming
> Sent: Friday, February 10, 2017 7:21 PM
> To: Yigit, Ferruh ; dev@dpdk.org
> Cc: Wu, Jingjing 
> Subject: Re: [dpdk-dev] [PATCH] net/i40e: fix vlan insert code redundance
> 
> > On 2/10/2017 1:26 AM, Qiming Yang wrote:
> > > This patch removed useless tx_flags in vlan insertion.
> >
> > Overall this looks good, I wonder what was the initial intention of
> > this code, understanding it helps to figure out if there is a hidden defect.
> 
> Thank you for your remind. I'll investigate it.

I have aligned with Helin (he contribute these code), and make sure these code 
is useless, these code is left by history.

> 
> >
> > This code not fixes a defect, but improves the code, is there any
> > performance gain with this?
> 
> I'll do more test and give you a feedback.

According to my test, this code will not bring any obvious performance gain, 
and no lose also.
And as you said this is not a bug fix, should I remove the fix line and modify 
the commit log?

> 
> > If not, I am for deferring this to next release.
> >
> > >
> > > Fixes: 4861cde46116 ("i40e: new poll mode driver")
> > >
> > > Signed-off-by: Qiming Yang 
> > > ---

Re: [dpdk-dev] FW: [PATCH] net/i40e: fix vlan insert code redundance

[Ferruh Yigit]

On 2/13/2017 10:09 AM, Yang, Qiming wrote:
> Hi, Ferruh
> 
>> -Original Message-
>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yang, Qiming
>> Sent: Friday, February 10, 2017 7:21 PM
>> To: Yigit, Ferruh ; dev@dpdk.org
>> Cc: Wu, Jingjing 
>> Subject: Re: [dpdk-dev] [PATCH] net/i40e: fix vlan insert code redundance
>>
>>> On 2/10/2017 1:26 AM, Qiming Yang wrote:
 This patch removed useless tx_flags in vlan insertion.
>>>
>>> Overall this looks good, I wonder what was the initial intention of
>>> this code, understanding it helps to figure out if there is a hidden defect.
>>
>> Thank you for your remind. I'll investigate it.
> 
> I have aligned with Helin (he contribute these code), and make sure these 
> code is useless, these code is left by history.
> 
>>
>>>
>>> This code not fixes a defect, but improves the code, is there any
>>> performance gain with this?
>>
>> I'll do more test and give you a feedback.
> 
> According to my test, this code will not bring any obvious performance gain, 
> and no lose also.
> And as you said this is not a bug fix, should I remove the fix line and 
> modify the commit log?

Please do if you will send a new version already, no need to send a new
version just for title update.

Thanks,
ferruh

> 
>>
>>> If not, I am for deferring this to next release.
>>>

 Fixes: 4861cde46116 ("i40e: new poll mode driver")

 Signed-off-by: Qiming Yang 
 ---
> 

Re: [dpdk-dev] [PATCH v2 15/15] app/test: add unit tests for SW eventdev driver

[Jerin Jacob]

On Wed, Feb 08, 2017 at 10:44:11AM +, Van Haaren, Harry wrote:
> > -Original Message-
> > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> > Sent: Wednesday, February 8, 2017 10:23 AM
> > To: Van Haaren, Harry 
> > Cc: dev@dpdk.org; Richardson, Bruce ; Hunt, 
> > David
> > ; nipun.gu...@nxp.com; hemant.agra...@nxp.com; Eads, 
> > Gage
> > 
> > Subject: Re: [PATCH v2 15/15] app/test: add unit tests for SW eventdev 
> > driver
> 
> 
>  
> > Thanks for SW driver specific test cases. It provided me a good insight
> > of expected application behavior from SW driver perspective and in turn it 
> > created
> > some challenge in portable applications.
> > 
> > I would like highlight a main difference between the implementation and get 
> > a
> > consensus on how to abstract it?
> 
> Thanks for taking the time to detail your thoughts - the examples certainly 
> help to get a better picture of the whole.
> 



> 
> > - Fairly large number of SA(kind of 2^16 to 2^20) can be processed in 
> > parallel
> > Something existing IPSec application has constraints on
> > http://dpdk.org/doc/guides-16.04/sample_app_ug/ipsec_secgw.html
> > 
> > on_each_worker_cores()
> > while(1)
> > {
> > rte_event_dequeue_burst(ev,..)
> > if (!nr_events);
> > continue;
> > 
> > /* STAGE 1 processing */
> > if(ev.event_type == RTE_EVENT_TYPE_ETHDEV) {
> > sa = find_it_from_packet(ev.mbuf);
> > /* move to next stage2(ATOMIC) */
> > ev.event_type = RTE_EVENT_TYPE_CPU;
> > ev.sub_event_type = 2;
> > ev.sched_type = RTE_SCHED_TYPE_ATOMIC;
> > ev.flow_id =  sa;
> > ev.op = RTE_EVENT_OP_FORWARD;
> > rte_event_enqueue_burst(ev..);
> > 
> > } else if(ev.event_type == RTE_EVENT_TYPE_CPU && ev.sub_event_type == 
> > 2) { /* stage 2 */
> 
> 
> [HvH] In the case of software eventdev ev.queue_id is used instead of 
> ev.sub_event_type - but this is the same lookup operation as mentioned above. 
> I don't see a fundamental difference between these approaches?


Does that mean ev.sub_event_type can not be use for event pipelining.
Right?  Looks like NXP HW has similar common behavior. If so, How about
abstracting with union(see below) to have portable application code?

Application will use "next_stage"(or similar name) to advance the stage, based 
on the
capability or configured mode(flow and/or queue based) underneath
implementation will move to next stage.

I will send a patch with above details. What do you think?

diff --git a/lib/librte_eventdev/rte_eventdev.h
b/lib/librte_eventdev/rte_eventdev.h
index c2f9310..040d70d 100644
--- a/lib/librte_eventdev/rte_eventdev.h
+++ b/lib/librte_eventdev/rte_eventdev.h
@@ -907,17 +907,13 @@ struct rte_event {
uint64_t event;
/** Event attributes for dequeue or enqueue operation */
struct {
-   uint32_t flow_id:20;
+   uint32_t flow_id:28;
/**< Targeted flow identifier for the enqueue and
 * dequeue operation.
 * The value must be in the range of
 * [0, nb_event_queue_flows - 1] which
 * previously supplied to
 * rte_event_dev_configure().
 */
-   uint32_t sub_event_type:8;
-   /**< Sub-event types based on the event source.
-* @see RTE_EVENT_TYPE_CPU
-*/
uint32_t event_type:4;
/**< Event type to classify the event source.
 * @see RTE_EVENT_TYPE_ETHDEV,
 * (RTE_EVENT_TYPE_*)
@@ -935,13 +931,16 @@ struct rte_event {
 * associated with flow id on a given event
 * queue
 * for the enqueue and dequeue operation.
 */
-   uint8_t queue_id;
-   /**< Targeted event queue identifier for the enqueue or
-* dequeue operation.
-* The value must be in the range of
-* [0, nb_event_queues - 1] which previously supplied to
-* rte_event_dev_configure().
-*/
+   union {
+   uint8_t queue_id;
+   /**< Targeted event queue identifier for the 
enqueue or
+* dequeue operation.
+* The value must be in the range of
+* [0, nb_event_queues - 1] which previously 
supplied to
+* rte_event_dev_configure().
+*/
+   uint8_t next_stage;
+

Re: [dpdk-dev] GSO/GRO support

[Ananyev, Konstantin]

Hi Kiran,

> 
> We, at Juniper Opencontrail have added software support for TCP send offload 
> and receive offload to DPDK.
> 
> If the community is interested, we can publish/upstream it.
> 
> Pl let us know what you think of it.

IMO, GRO sounds interesting.
My suggestion would be to submit an RFC to the community.
BTW, there was a discussion on similar subject recently:
http://dpdk.org/ml/archives/dev/2017-February/056949.html
Thanks
Konstantin

[dpdk-dev] [PATCH 1/1] ethdev: fix typo in UDP tunnel add/delete description

[Andrew Rybchenko]

Fixes: 1cbe755fef47 ("ethdev: rename UDP tunnel port functions")

Signed-off-by: Andrew Rybchenko 
---
 lib/librte_ether/rte_ethdev.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index c17bbda..97f3e2d 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -3815,7 +3815,7 @@ int rte_eth_dev_rss_hash_update(uint8_t port_id,
  * The packets with this UDP port will be identified as this type of tunnel.
  * Before enabling any offloading function for a tunnel, users can call this 
API
  * to change or add more UDP port for the tunnel. So the offloading function
- * can take effect on the packets with the sepcific UDP port.
+ * can take effect on the packets with the specific UDP port.
  *
  * @param port_id
  *   The port identifier of the Ethernet device.
@@ -3837,7 +3837,7 @@ int rte_eth_dev_rss_hash_update(uint8_t port_id,
  * any more.
  * Before enabling any offloading function for a tunnel, users can call this 
API
  * to delete a UDP port for the tunnel. So the offloading function will not 
take
- * effect on the packets with the sepcific UDP port.
+ * effect on the packets with the specific UDP port.
  *
  * @param port_id
  *   The port identifier of the Ethernet device.
-- 
1.8.2.3

Re: [dpdk-dev] [dpdk-techboard] decision process and DPDK scope

[Bruce Richardson]

On Fri, Feb 10, 2017 at 06:23:11PM +0100, Thomas Monjalon wrote:
> 2017-02-10 15:54, Bruce Richardson:
> > On Thu, Feb 09, 2017 at 02:49:05PM -0800, Stephen Hemminger wrote:
> > > On Thu, 9 Feb 2017 12:20:47 +
> > > Bruce Richardson  wrote:
> > > 
> > > > > I think we can use this case to avoid seeing it again in the future.
> > > > > I suggest that the technical board should check whether every new 
> > > > > proposed
> > > > > features are explained, discussed and approved enough in the 
> > > > > community.
> > > > > If needed, the technical board meeting minutes will give some lights 
> > > > > to
> > > > > the threads which require more attention.
> > > > > Before adding a new library or adding a major API, there should be
> > > > > some strong reviews which include discussing the DPDK scope.
> > > > >   
> > > > 
> > > > The bigger question here is the default position of the DPDK community -
> > > > default accept, or default reject. Your statements above all are very
> > > > much keeping in the style of default reject i.e. every patch or change
> > > > suggested is assumed to be unfit for acceptance unless reviewed in
> > > > detail to prove beyond doubt otherwise.
> > > > 
> > > > I believe that we should change this default position, as I think that
> > > > reject by default is hurting the community and will continue to do so.
> 
> It is hurting because there is no clear explanation of the process.
> 
> > > > NOTE: I am not suggesting that we allow all code in with zero review,
> > > > but I am suggesting that if something has been reviewed and acked by at
> > > > least one reviewer it should be automatically accepted unless some other
> > > > reviewed objects in a TIMELY manner.
> 
> I see an issue with "automatic" decision after a period of time.
> It puts a lot of pressure on the community to check everything.
> I agree we should state this kind of default. But we should add two
> exceptions:
>   - new API or API change
>   - a maintainer explicitly ask for a techboard discussion
>
Ok, I will accept the referral to the tech board as a reason to not
automatically apply, but I disagree on the API one. For all types of
changes we need to clearly document the number of reviews needed to get
the patches in, and who needs to agree. Once those conditions are met,
we must have a mandatory merge. The difference between adding a new API
and adding an internal code change should only be in the conditions
required for mandatory merge. There must still be an automatic decision
after a set period of time, otherwise we will still see issues with
people leaving reviews till the last minute and then flagging problems
with a patch blocking its merge.

/Bruce

Re: [dpdk-dev] [PATCH] eventdev: Add rte_errno return values to the enqueue and dequeue functions

[Bruce Richardson]

On Fri, Feb 10, 2017 at 03:02:21PM -0600, Gage Eads wrote:
> This change allows user software to differentiate between an invalid argument
> (such as an invalid queue_id or sched_type in an enqueued event) and
> backpressure from the event device.
> 
> The port and device ID checks are placed in RTE_LIBRTE_EVENTDEV_DEBUG header
> guards to avoid the performance hit in non-debug execution.
> 
> Signed-off-by: Gage Eads 
> ---

Do we have some idea of the performance hit from these? It may be too
soon to know, given we don't have many drivers to test with, but if
there is no perf hit seen with the SW driver, I think we should look to
just always do this, rather than having it compile-time off. If it does
prove to be a performance problem we can look to #ifdef it out later.

/Bruce

Re: [dpdk-dev] [PATCH v2 15/15] app/test: add unit tests for SW eventdev driver

[Bruce Richardson]

On Mon, Feb 13, 2017 at 03:58:27PM +0530, Jerin Jacob wrote:
> On Wed, Feb 08, 2017 at 10:44:11AM +, Van Haaren, Harry wrote:
> > > -Original Message-
> > > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> > > Sent: Wednesday, February 8, 2017 10:23 AM
> > > To: Van Haaren, Harry 
> > > Cc: dev@dpdk.org; Richardson, Bruce ; Hunt, 
> > > David
> > > ; nipun.gu...@nxp.com; hemant.agra...@nxp.com; 
> > > Eads, Gage
> > > 
> > > Subject: Re: [PATCH v2 15/15] app/test: add unit tests for SW eventdev 
> > > driver
> > 
> > 
> >  
> > > Thanks for SW driver specific test cases. It provided me a good insight
> > > of expected application behavior from SW driver perspective and in turn 
> > > it created
> > > some challenge in portable applications.
> > > 
> > > I would like highlight a main difference between the implementation and 
> > > get a
> > > consensus on how to abstract it?
> > 
> > Thanks for taking the time to detail your thoughts - the examples certainly 
> > help to get a better picture of the whole.
> > 
> 
> 
> 
> > 
> > > - Fairly large number of SA(kind of 2^16 to 2^20) can be processed in 
> > > parallel
> > > Something existing IPSec application has constraints on
> > > http://dpdk.org/doc/guides-16.04/sample_app_ug/ipsec_secgw.html
> > > 
> > > on_each_worker_cores()
> > > while(1)
> > > {
> > >   rte_event_dequeue_burst(ev,..)
> > >   if (!nr_events);
> > >   continue;
> > > 
> > >   /* STAGE 1 processing */
> > >   if(ev.event_type == RTE_EVENT_TYPE_ETHDEV) {
> > >   sa = find_it_from_packet(ev.mbuf);
> > >   /* move to next stage2(ATOMIC) */
> > >   ev.event_type = RTE_EVENT_TYPE_CPU;
> > >   ev.sub_event_type = 2;
> > >   ev.sched_type = RTE_SCHED_TYPE_ATOMIC;
> > >   ev.flow_id =  sa;
> > >   ev.op = RTE_EVENT_OP_FORWARD;
> > >   rte_event_enqueue_burst(ev..);
> > > 
> > >   } else if(ev.event_type == RTE_EVENT_TYPE_CPU && ev.sub_event_type == 
> > > 2) { /* stage 2 */
> > 
> > 
> > [HvH] In the case of software eventdev ev.queue_id is used instead of 
> > ev.sub_event_type - but this is the same lookup operation as mentioned 
> > above. I don't see a fundamental difference between these approaches?
> 
> 
> Does that mean ev.sub_event_type can not be use for event pipelining.
> Right?  Looks like NXP HW has similar common behavior. If so, How about
> abstracting with union(see below) to have portable application code?

No, it can if so desired. It may be useful in cases where the queue ids
do not directly correspond to the logical stage number, or perhaps when
a packet need to go back to a previous pipeline stage and wants to
record past history (e.g. after tunnel decap).

> 
> Application will use "next_stage"(or similar name) to advance the stage, 
> based on the
> capability or configured mode(flow and/or queue based) underneath
> implementation will move to next stage.
> 
> I will send a patch with above details. What do you think?
> 
> diff --git a/lib/librte_eventdev/rte_eventdev.h
> b/lib/librte_eventdev/rte_eventdev.h
> index c2f9310..040d70d 100644
> --- a/lib/librte_eventdev/rte_eventdev.h
> +++ b/lib/librte_eventdev/rte_eventdev.h
> @@ -907,17 +907,13 @@ struct rte_event {
> uint64_t event;
> /** Event attributes for dequeue or enqueue operation */
> struct {
> -   uint32_t flow_id:20;
> +   uint32_t flow_id:28;
> /**< Targeted flow identifier for the enqueue and
>  * dequeue operation.
>  * The value must be in the range of
>  * [0, nb_event_queue_flows - 1] which
>  * previously supplied to
>  * rte_event_dev_configure().
>  */
> -   uint32_t sub_event_type:8;
> -   /**< Sub-event types based on the event source.
> -* @see RTE_EVENT_TYPE_CPU
> -*/
> uint32_t event_type:4;
> /**< Event type to classify the event source.
>  * @see RTE_EVENT_TYPE_ETHDEV,
>  * (RTE_EVENT_TYPE_*)
> @@ -935,13 +931,16 @@ struct rte_event {
>  * associated with flow id on a given event
>  * queue
>  * for the enqueue and dequeue operation.
>  */
> -   uint8_t queue_id;
> -   /**< Targeted event queue identifier for the enqueue 
> or
> -* dequeue operation.
> -* The value must be in the range of
> -* [0, nb_event_queues - 1] which previously supplied 
> to
> -* rte_event_dev_configure().
> -*/
> +   union 

[dpdk-dev] [PATCH] doc: announce TILE-Gx removal

[Thomas Monjalon]

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 b49e0a0..d40b137 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -62,3 +62,6 @@ Deprecation Notices
   PMDs that implement the latter.
   Target release for removal of the legacy API will be defined once most
   PMDs have switched to rte_flow.
+
+* The architecture TILE-Gx and the associated mpipe driver are not
+  maintained and will be removed in 17.05.
-- 
2.7.0

[dpdk-dev] [PATCH] doc: remove announce of Tx preparation

[Thomas Monjalon]

The feature is part of 17.02, so the ABI changes notice can be removed.

Fixes: 4fb7e803eb1a ("ethdev: add Tx preparation")

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

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index b49e0a0..326fde4 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -23,13 +23,6 @@ Deprecation Notices
   provide a way to handle device initialization currently being done in
   ``eth_driver``.
 
-* In 17.02 ABI changes are planned: the ``rte_eth_dev`` structure will be
-  extended with new function pointer ``tx_pkt_prepare`` allowing verification
-  and processing of packet burst to meet HW specific requirements before
-  transmit. Also new fields will be added to the ``rte_eth_desc_lim`` 
structure:
-  ``nb_seg_max`` and ``nb_mtu_seg_max`` providing information about number of
-  segments limit to be transmitted by device for TSO/non-TSO packets.
-
 * ethdev: an API change is planned for 17.02 for the function
   ``_rte_eth_dev_callback_process``. In 17.02 the function will return an 
``int``
   instead of ``void`` and a fourth parameter ``void *ret_param`` will be added.
-- 
2.7.0

[dpdk-dev] [PATCH] doc: postpone ABI changes to 17.05

[Olivier Matz]

Postpone the ABI changes for mempool and mbuf that were planned
for 17.02 to 17.05.

Signed-off-by: Olivier Matz 
---
 doc/guides/rel_notes/deprecation.rst | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index b49e0a0..9d01e86 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -34,7 +34,7 @@ Deprecation Notices
   ``_rte_eth_dev_callback_process``. In 17.02 the function will return an 
``int``
   instead of ``void`` and a fourth parameter ``void *ret_param`` will be added.
 
-* ABI changes are planned for 17.02 in the ``rte_mbuf`` structure: some fields
+* ABI changes are planned for 17.05 in the ``rte_mbuf`` structure: some fields
   may be reordered to facilitate the writing of ``data_off``, ``refcnt``, and
   ``nb_segs`` in one operation, because some platforms have an overhead if the
   store address is not naturally aligned. Other mbuf fields, such as the
@@ -44,15 +44,15 @@ Deprecation Notices
 * The mbuf flags PKT_RX_VLAN_PKT and PKT_RX_QINQ_PKT are deprecated and
   are respectively replaced by PKT_RX_VLAN_STRIPPED and
   PKT_RX_QINQ_STRIPPED, that are better described. The old flags and
-  their behavior will be kept until 16.11 and will be removed in 17.02.
+  their behavior will be kept until 17.02 and will be removed in 17.05.
 
 * mempool: The functions ``rte_mempool_count`` and ``rte_mempool_free_count``
-  will be removed in 17.02.
+  will be removed in 17.05.
   They are replaced by ``rte_mempool_avail_count`` and
   ``rte_mempool_in_use_count`` respectively.
 
 * mempool: The functions for single/multi producer/consumer are deprecated
-  and will be removed in 17.02.
+  and will be removed in 17.05.
   It is replaced by ``rte_mempool_generic_get/put`` functions.
 
 * ethdev: the legacy filter API, including
-- 
2.8.1

Re: [dpdk-dev] [PATCH v2 15/15] app/test: add unit tests for SW eventdev driver

[Jerin Jacob]

On Mon, Feb 13, 2017 at 10:45:27AM +, Bruce Richardson wrote:
> On Mon, Feb 13, 2017 at 03:58:27PM +0530, Jerin Jacob wrote:
> > On Wed, Feb 08, 2017 at 10:44:11AM +, Van Haaren, Harry wrote:
> > > > -Original Message-
> > > > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> > > > Sent: Wednesday, February 8, 2017 10:23 AM
> > > > To: Van Haaren, Harry 
> > > > Cc: dev@dpdk.org; Richardson, Bruce ; Hunt, 
> > > > David
> > > > ; nipun.gu...@nxp.com; hemant.agra...@nxp.com; 
> > > > Eads, Gage
> > > > 
> > > > Subject: Re: [PATCH v2 15/15] app/test: add unit tests for SW eventdev 
> > > > driver
> > > 
> > > 
> > >  
> > > > Thanks for SW driver specific test cases. It provided me a good insight
> > > > of expected application behavior from SW driver perspective and in turn 
> > > > it created
> > > > some challenge in portable applications.
> > > > 
> > > > I would like highlight a main difference between the implementation and 
> > > > get a
> > > > consensus on how to abstract it?
> > > 
> > > Thanks for taking the time to detail your thoughts - the examples 
> > > certainly help to get a better picture of the whole.
> > > 
> > 
> > 
> > 
> > > 
> > > > - Fairly large number of SA(kind of 2^16 to 2^20) can be processed in 
> > > > parallel
> > > > Something existing IPSec application has constraints on
> > > > http://dpdk.org/doc/guides-16.04/sample_app_ug/ipsec_secgw.html
> > > > 
> > > > on_each_worker_cores()
> > > > while(1)
> > > > {
> > > > rte_event_dequeue_burst(ev,..)
> > > > if (!nr_events);
> > > > continue;
> > > > 
> > > > /* STAGE 1 processing */
> > > > if(ev.event_type == RTE_EVENT_TYPE_ETHDEV) {
> > > > sa = find_it_from_packet(ev.mbuf);
> > > > /* move to next stage2(ATOMIC) */
> > > > ev.event_type = RTE_EVENT_TYPE_CPU;
> > > > ev.sub_event_type = 2;
> > > > ev.sched_type = RTE_SCHED_TYPE_ATOMIC;
> > > > ev.flow_id =  sa;
> > > > ev.op = RTE_EVENT_OP_FORWARD;
> > > > rte_event_enqueue_burst(ev..);
> > > > 
> > > > } else if(ev.event_type == RTE_EVENT_TYPE_CPU && 
> > > > ev.sub_event_type == 2) { /* stage 2 */
> > > 
> > > 
> > > [HvH] In the case of software eventdev ev.queue_id is used instead of 
> > > ev.sub_event_type - but this is the same lookup operation as mentioned 
> > > above. I don't see a fundamental difference between these approaches?
> > 
> > 
> > Does that mean ev.sub_event_type can not be use for event pipelining.
> > Right?  Looks like NXP HW has similar common behavior. If so, How about
> > abstracting with union(see below) to have portable application code?
> 
> No, it can if so desired. It may be useful in cases where the queue ids
> do not directly correspond to the logical stage number, or perhaps when
> a packet need to go back to a previous pipeline stage and wants to
> record past history (e.g. after tunnel decap).

OK. Then we are good. No change is required.

One question though, In what basics application choose to the specific
mode?(I guess, "Going back to previous" use case also can be done though
queue id based scheme).
In our case, The sub_event_type based one gives more of "runtime to completion"
support a packet does not go through different queues.

> 
> > 
> > Application will use "next_stage"(or similar name) to advance the stage, 
> > based on the
> > capability or configured mode(flow and/or queue based) underneath
> > implementation will move to next stage.
> > 
> > I will send a patch with above details. What do you think?
> > 
> > diff --git a/lib/librte_eventdev/rte_eventdev.h
> > b/lib/librte_eventdev/rte_eventdev.h
> > index c2f9310..040d70d 100644
> > --- a/lib/librte_eventdev/rte_eventdev.h
> > +++ b/lib/librte_eventdev/rte_eventdev.h
> > @@ -907,17 +907,13 @@ struct rte_event {
> > uint64_t event;
> > /** Event attributes for dequeue or enqueue operation */
> > struct {
> > -   uint32_t flow_id:20;
> > +   uint32_t flow_id:28;
> > /**< Targeted flow identifier for the enqueue and
> >  * dequeue operation.
> >  * The value must be in the range of
> >  * [0, nb_event_queue_flows - 1] which
> >  * previously supplied to
> >  * rte_event_dev_configure().
> >  */
> > -   uint32_t sub_event_type:8;
> > -   /**< Sub-event types based on the event source.
> > -* @see RTE_EVENT_TYPE_CPU
> > -*/
> > uint32_t event_type:4;
> > /**< Event type to classify the event source.
> >  * @see RTE_EVENT_TYPE_ETHDEV,
> >  

[dpdk-dev] [PATCH] doc: add EAL bus support in release notes

[Shreyansh Jain]

Signed-off-by: Shreyansh Jain 
---
 doc/guides/rel_notes/release_17_02.rst | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/doc/guides/rel_notes/release_17_02.rst 
b/doc/guides/rel_notes/release_17_02.rst
index ec9143c..b5bf0a9 100644
--- a/doc/guides/rel_notes/release_17_02.rst
+++ b/doc/guides/rel_notes/release_17_02.rst
@@ -237,6 +237,16 @@ Resolved Issues
 EAL
 ~~~
 
+* **Added support for representing buses in EAL**
+
+  A new structure ``rte_bus`` is introduced in EAL. This allows for devices to
+  be represented by buses they are connected to. A new bus can be added to
+  DPDK by extending the ``rte_bus`` structure and implementing the scan and
+  probe functions. Once a new bus is registered using provided APIs, new
+  devices can be detected and initialized using bus scan and probe callbacks.
+
+  With this change, devices other than PCI or VDEV type can also be represented
+  in DPDK framework.
 
 Drivers
 ~~~
-- 
2.7.4

Re: [dpdk-dev] [PATCH 1/2] ethdev: add capability control API

[Dumitrescu, Cristian]

> -Original Message-
> From: Wiles, Keith
> Sent: Saturday, February 11, 2017 1:07 PM
> To: Jerin Jacob 
> Cc: Dumitrescu, Cristian ; dev@dpdk.org;
> thomas.monja...@6wind.com; hemant.agra...@nxp.com
> Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: add capability control API
> 
> 
> > On Feb 11, 2017, at 12:38 AM, Jerin Jacob
>  wrote:
> >
> > On Fri, Feb 10, 2017 at 02:05:49PM +, Cristian Dumitrescu wrote:
> >> The rte_flow feature breaks the current monolithic approach for ethdev
> and
> >> introduces the new generic flow API to ethdev using a plugin-like
> approach.
> >>
> >> Basically, the rte_flow API is still logically part of ethdev:
> >> - It extends the ethdev functionality: rte_flow is a new feature/capability
> >>  of ethdev;
> >> - all its functions work on an Ethernet device: the first parameter of the
> >>  rte_flow functions is Ethernet device port ID.
> >>
> >> At the same time, the rte_flow API is a sort of capability plugin for 
> >> ethdev:
> >> - the rte_flow API functions have their own name space: they are called
> >>  rte_flow_operationXYZ() as opposed to
> rte_eth_dev_flow_operationXYZ());
> >> - the rte_flow API functions are placed in separate files in the same
> >>  librte_ether folder as opposed to rte_ethdev.[hc].
> >>
> >> The way it works is by using the existing ethdev API function
> >> rte_eth_dev_filter_ctrl() to query the current Ethernet device port ID for
> the
> >> support of the rte_flow capability and return the pointer to the
> >> rte_flow operations when supported and NULL otherwise:
> >>
> >> struct rte_flow_ops *eth_flow_ops;
> >> int rte = rte_eth_dev_filter_ctrl(eth_port_id,
> >>RTE_ETH_FILTER_GENERIC, RTE_ETH_FILTER_GET, ð_flow_ops);
> >>
> >> Unfortunately, the rte_flow opportunistically uses the
> rte_eth_dev_filter_ctrl()
> >> API function, which is applicable just to RX-side filters as opposed to
> >> introducing a mechanism that could be used by any capability in a generic
> way.
> >>
> >> This is the gap that addressed by the current patch. This mechanism is
> intended
> >> to be used to introduce new capabilities into ethdev in a modular plugin-
> like
> >> approach, such as hierarchical scheduler. Over time, if agreed, it can also
> be
> >> used for exposing the existing Ethernet device capabilities in a modular
> way,
> >> such as: xstats, filters, multicast, mirroring, tunnels, time stamping,
> eeprom,
> >> bypass, etc.
> >>
> >> Signed-off-by: Cristian Dumitrescu 
> >> ---
> >> lib/librte_ether/rte_ethdev.c  | 13 +
> >> lib/librte_ether/rte_ethdev.h  | 29
> +
> >> lib/librte_ether/rte_ether_version.map |  7 +++
> >> 3 files changed, 49 insertions(+)
> >>
> >> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> >> index eb0a94a..ae187c4 100644
> >> --- a/lib/librte_ether/rte_ethdev.c
> >> +++ b/lib/librte_ether/rte_ethdev.c
> >> @@ -2802,6 +2802,19 @@ rte_eth_dev_filter_ctrl(uint8_t port_id, enum
> rte_filter_type filter_type,
> >>return (*dev->dev_ops->filter_ctrl)(dev, filter_type, filter_op, arg);
> >> }
> >>
> >> +int
> >> +rte_eth_dev_capability_control(uint8_t port_id, enum
> rte_eth_capability cap,
> >> +  void *arg)
> >> +{
> >> +  struct rte_eth_dev *dev;
> >> +
> >> +  RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> >> +
> >> +  dev = &rte_eth_devices[port_id];
> >> +  RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->cap_ctrl, -
> ENOTSUP);
> >> +  return (*dev->dev_ops->cap_ctrl)(dev, cap, arg);
> >> +}
> >> +
> >> void *
> >> rte_eth_add_rx_callback(uint8_t port_id, uint16_t queue_id,
> >>rte_rx_callback_fn fn, void *user_param)
> >> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> >> index c17bbda..43ffb9e 100644
> >> --- a/lib/librte_ether/rte_ethdev.h
> >> +++ b/lib/librte_ether/rte_ethdev.h
> >> @@ -1073,6 +1073,12 @@ TAILQ_HEAD(rte_eth_dev_cb_list,
> rte_eth_dev_callback);
> >>  * structure associated with an Ethernet device.
> >>  */
> >>
> >> +enum rte_eth_capability {
> >> +  RTE_ETH_CAPABILITY_FLOW = 0, /**< Flow */
> >> +  RTE_ETH_CAPABILITY_SCHED, /**< Hierarchical Scheduler */
> >> +  RTE_ETH_CAPABILITY_MAX
> >> +};
> >
> > Shouldn't it be the FLAG?. Meaning, To represent ethdev port can have
> both.
> 
> The current API is requesting if the PMD supports the given feature and then
> returns the void * to the structure of function pointers or NULL similar to 
> the
> rte_flow design. The developer would need to ask multiple times to
> understand if all of the features are supported by the PMD. I guess one of
> the options could be to return a list of features the PMD supports. The void *
> would point to the PMD capability list, which would need to be a const of
> some type to prevent someone from modifying the PMD capability list.
> 
> enum rte_eth_capability {
>   RTE_ETH_CAPABILITY_LIST = 0,
>   RTE_ETH_CAPABILITY_FLOW = 1,
>   RTE_ETH_CAPABILITY_SCHED = 2,
>   RTE_ETH_CAP

Re: [dpdk-dev] [PATCH v2 15/15] app/test: add unit tests for SW eventdev driver

[Jerin Jacob]

On Wed, Feb 08, 2017 at 06:02:26PM +, Nipun Gupta wrote:
> 
> 
> > -Original Message-
> > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> > Sent: Wednesday, February 08, 2017 15:53
> > To: Harry van Haaren 
> > Cc: dev@dpdk.org; Bruce Richardson ; David
> > Hunt ; Nipun Gupta ; Hemant
> > }
> > 
> > on_each_cores_linked_to_queue2(stage2)
> > while(1)
> > {
> > /* STAGE 2 processing */
> > nr_events = rte_event_dequeue_burst(ev,..);
> > if (!nr_events);
> > continue;
> > 
> > sa_specific_atomic_processing(sa /* ev.flow_id */);/* seq 
> > number
> > update in critical section */
> > 
> > /* move to next stage(ORDERED) */
> > ev.event_type = RTE_EVENT_TYPE_CPU;
> > ev.sub_event_type = 3;
> > ev.sched_type = RTE_SCHED_TYPE_ORDERED;
> > ev.flow_id =  sa;
> 
> [Nipun] Queue1 has flow_id as an 'sa' with sched_type as 
> RTE_SCHED_TYPE_ATOMIC and
> Queue2 has same flow_id but with sched_type as RTE_SCHED_TYPE_ORDERED.
> Does this mean that same flow_id be associated with separate RTE_SCHED_TYPE_* 
> as sched_type?
> 
> My understanding is that one flow can either be parallel or atomic or ordered.
> The rte_eventdev.h states that sched_type is associated with flow_id, which 
> also seems legitimate:

Yes. flow_id per _event queue_.

>   uint8_t sched_type:2;
>   /**< Scheduler synchronization type (RTE_SCHED_TYPE_*)
>* associated with flow id on a given event queue
>* for the enqueue and dequeue operation.
>*/
> 
> > ev.op = RTE_EVENT_OP_FORWARD;
> > ev.queue_id = 3;
> > /* move to stage 3(event queue 3) */
> > rte_event_enqueue_burst(ev,..);
> > }
> > 
> > on_each_cores_linked_to_queue3(stage3)
> > while(1)
> > {
> > /* STAGE 3 processing */
> > nr_events = rte_event_dequeue_burst(ev,..);
> > if (!nr_events);
> > continue;
> > 
> > sa_specific_ordered_processing(sa /*ev.flow_id */);/* 
> > packets
> > encryption in parallel */
> > 
> > /* move to next stage(ATOMIC) */
> > ev.event_type = RTE_EVENT_TYPE_CPU;
> > ev.sub_event_type = 4;
> > ev.sched_type = RTE_SCHED_TYPE_ATOMIC;
> > output_tx_port_queue =
> > find_output_tx_queue_and_tx_port(ev.mbuff);
> > ev.flow_id =  output_tx_port_queue;
> > ev.op = RTE_EVENT_OP_FORWARD;
> > ev.queue_id = 4;
> > /* move to stage 4(event queue 4) */
> > rte_event_enqueue_burst(ev,...);
> > }
> > 
> > on_each_cores_linked_to_queue4(stage4)
> > while(1)
> > {
> > /* STAGE 4 processing */
> > nr_events = rte_event_dequeue_burst(ev,..);
> > if (!nr_events);
> > continue;
> > 
> > rte_eth_tx_buffer();
> > }
> > 
> > 2) flow-based event pipelining
> > =
> > 
> > - No need to partition queues for different stages
> > - All the cores can operate on all the stages, Thus enables
> > automatic multicore scaling, true dynamic load balancing,
> > - Fairly large number of SA(kind of 2^16 to 2^20) can be processed in 
> > parallel
> > Something existing IPSec application has constraints on
> > http://dpdk.org/doc/guides-16.04/sample_app_ug/ipsec_secgw.html
> > 
> > on_each_worker_cores()
> > while(1)
> > {
> > rte_event_dequeue_burst(ev,..)
> > if (!nr_events);
> > continue;
> > 
> > /* STAGE 1 processing */
> > if(ev.event_type == RTE_EVENT_TYPE_ETHDEV) {
> > sa = find_it_from_packet(ev.mbuf);
> > /* move to next stage2(ATOMIC) */
> > ev.event_type = RTE_EVENT_TYPE_CPU;
> > ev.sub_event_type = 2;
> > ev.sched_type = RTE_SCHED_TYPE_ATOMIC;
> > ev.flow_id =  sa;
> > ev.op = RTE_EVENT_OP_FORWARD;
> > rte_event_enqueue_burst(ev..);
> > 
> > } else if(ev.event_type == RTE_EVENT_TYPE_CPU &&
> > ev.sub_event_type == 2) { /* stage 2 */
> 
> [Nipun] I didn't got that in this case on which event queue (and eventually
> its associated event ports) will the RTE_EVENT_TYPE_CPU type events be 
> received on?

Yes. The same queue which received the event.

> 
> Adding on to what Harry also mentions in other mail, If same code is run in 
> the case you
> mentioned in '#1 - queue_id based event pipelining', after specifying the 
> ev.queue_id
> with appropriate value then also #1 would be good. Isn't it?

See my earlier email

> 
> > 
> > sa_specific_atomic_processing(sa /* ev.flow_id */);/* seq
> > number update in critical section */
> > /* move to next stage(ORDERED) */
> > ev.event_type 

Re: [dpdk-dev] [PATCH] eventdev: Add rte_errno return values to the enqueue and dequeue functions

[Jerin Jacob]

On Mon, Feb 13, 2017 at 10:38:55AM +, Bruce Richardson wrote:
> On Fri, Feb 10, 2017 at 03:02:21PM -0600, Gage Eads wrote:
> > This change allows user software to differentiate between an invalid 
> > argument
> > (such as an invalid queue_id or sched_type in an enqueued event) and
> > backpressure from the event device.
> > 
> > The port and device ID checks are placed in RTE_LIBRTE_EVENTDEV_DEBUG header
> > guards to avoid the performance hit in non-debug execution.
> > 
> > Signed-off-by: Gage Eads 
> > ---
> 
> Do we have some idea of the performance hit from these? It may be too
> soon to know, given we don't have many drivers to test with, but if
> there is no perf hit seen with the SW driver, I think we should look to
> just always do this, rather than having it compile-time off. If it does

IMO, It is better put to under compile-time like ethdev. It is
difficult predict the performance regression on wide range of cores that DPDK
runs now. I think we need to add following additional checks based on
Gage header file change

1) Per event queue ID is valid or not?
2) Per event's sched type doesn't match the capabilities of the destination 
queue.


> prove to be a performance problem we can look to #ifdef it out later.
> 
> /Bruce

[dpdk-dev] [PATCH] doc: add deprecation note for rework of PCI in EAL

[Shreyansh Jain]

EAL PCI layer is planned to be restructured in 17.05 to unlink it from
generic structures like eth_driver, rte_cryptodev_driver, and also move
it into a PCI Bus.

Signed-off-by: Shreyansh Jain 
---
 doc/guides/rel_notes/deprecation.rst | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index fbe2fcb..b12d435 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -13,10 +13,14 @@ Deprecation Notices
   has exposed, like the way we have done with uio-pci-generic. This change
   targets release 17.05.
 
-* ``eth_driver`` is planned to be removed in 17.02. This currently serves as
-  a placeholder for PMDs to register themselves. Changes for ``rte_bus`` will
-  provide a way to handle device initialization currently being done in
-  ``eth_driver``.
+* ABI/API changes are planned for 17.05 for PCI subsystem. This is to
+  unlink EAL dependency on PCI and to move PCI devices to a PCI specific
+  bus.
+
+* ``rte_pci_driver`` is planned to be removed from ``eth_driver`` in 17.05.
+  This is to unlink the ethernet driver from PCI dependencies.
+  Similarly, ``rte_pci_driver`` in planned to be removed from
+  ``rte_cryptodev_driver`` in 17.05.
 
 * In 17.02 ABI changes are planned: the ``rte_eth_dev`` structure will be
   extended with new function pointer ``tx_pkt_prepare`` allowing verification
-- 
2.7.4

[dpdk-dev] [PATCH] doc: remove deprecation notice for rte_bus

[Shreyansh Jain]

Signed-off-by: Shreyansh Jain 
---
 doc/guides/rel_notes/deprecation.rst | 5 -
 1 file changed, 5 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index b49e0a0..fbe2fcb 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -13,11 +13,6 @@ Deprecation Notices
   has exposed, like the way we have done with uio-pci-generic. This change
   targets release 17.05.
 
-* ABI/API changes are planned for 17.02: ``rte_device``, ``rte_driver`` will be
-  impacted because of introduction of a new ``rte_bus`` hierarchy. This would
-  also impact the way devices are identified by EAL. A bus-device-driver model
-  will be introduced providing a hierarchical view of devices.
-
 * ``eth_driver`` is planned to be removed in 17.02. This currently serves as
   a placeholder for PMDs to register themselves. Changes for ``rte_bus`` will
   provide a way to handle device initialization currently being done in
-- 
2.7.4

Re: [dpdk-dev] [PATCH] doc: add deprecation note for rework of PCI in EAL

[Shreyansh Jain]

On Monday 13 February 2017 05:25 PM, Shreyansh Jain wrote:

EAL PCI layer is planned to be restructured in 17.05 to unlink it from
generic structures like eth_driver, rte_cryptodev_driver, and also move
it into a PCI Bus.

Signed-off-by: Shreyansh Jain 
---
 doc/guides/rel_notes/deprecation.rst | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index fbe2fcb..b12d435 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -13,10 +13,14 @@ Deprecation Notices
   has exposed, like the way we have done with uio-pci-generic. This change
   targets release 17.05.

-* ``eth_driver`` is planned to be removed in 17.02. This currently serves as
-  a placeholder for PMDs to register themselves. Changes for ``rte_bus`` will
-  provide a way to handle device initialization currently being done in
-  ``eth_driver``.


Just to highlight, above statement was added by me in 16.11.
As of now I plan to work on removing rte_pci_driver from eth_driver,
rather than removing eth_driver all together (which, probably, was
better idea).
If someone still wishes to work on its complete removal, we can keep
the above. (and probably remove the below).


+* ABI/API changes are planned for 17.05 for PCI subsystem. This is to
+  unlink EAL dependency on PCI and to move PCI devices to a PCI specific
+  bus.
+
+* ``rte_pci_driver`` is planned to be removed from ``eth_driver`` in 17.05.
+  This is to unlink the ethernet driver from PCI dependencies.
+  Similarly, ``rte_pci_driver`` in planned to be removed from
+  ``rte_cryptodev_driver`` in 17.05.

 * In 17.02 ABI changes are planned: the ``rte_eth_dev`` structure will be
   extended with new function pointer ``tx_pkt_prepare`` allowing verification

[dpdk-dev] [PATCH] doc: deprecation note for renaming vfio symbols for exporting

[Shreyansh Jain]

Some vfio symbols need to be exported outside librte_eal. For that, they
need to be renamed to rte_* naming convention.

Signed-off-by: Shreyansh Jain 
---
 doc/guides/rel_notes/deprecation.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index b12d435..092eb2e 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -61,3 +61,9 @@ Deprecation Notices
   PMDs that implement the latter.
   Target release for removal of the legacy API will be defined once most
   PMDs have switched to rte_flow.
+
+* Some vfio APIs are planned to be exported outside librte_eal in 17.05.
+  vfio APIs like ``vfio_setup_device``, ``vfio_get_group_fd`` can be used by
+  subsystem other than EAL/PCI. For that, these need to be exported symbols.
+  Such APIs are planned to be renamed according to ``rte_*`` naming convention
+  and exported from librte_eal.
-- 
2.7.4

Re: [dpdk-dev] [PATCH] eventdev: Add rte_errno return values to the enqueue and dequeue functions

[Bruce Richardson]

On Mon, Feb 13, 2017 at 05:18:11PM +0530, Jerin Jacob wrote:
> On Mon, Feb 13, 2017 at 10:38:55AM +, Bruce Richardson wrote:
> > On Fri, Feb 10, 2017 at 03:02:21PM -0600, Gage Eads wrote:
> > > This change allows user software to differentiate between an invalid 
> > > argument
> > > (such as an invalid queue_id or sched_type in an enqueued event) and
> > > backpressure from the event device.
> > > 
> > > The port and device ID checks are placed in RTE_LIBRTE_EVENTDEV_DEBUG 
> > > header
> > > guards to avoid the performance hit in non-debug execution.
> > > 
> > > Signed-off-by: Gage Eads 
> > > ---
> > 
> > Do we have some idea of the performance hit from these? It may be too
> > soon to know, given we don't have many drivers to test with, but if
> > there is no perf hit seen with the SW driver, I think we should look to
> > just always do this, rather than having it compile-time off. If it does
> 
> IMO, It is better put to under compile-time like ethdev. It is
> difficult predict the performance regression on wide range of cores that DPDK
> runs now. I think we need to add following additional checks based on
> Gage header file change
> 
> 1) Per event queue ID is valid or not?
> 2) Per event's sched type doesn't match the capabilities of the destination 
> queue.
> 

Ok, if we are expanding the number of checks then I definitely think it
needs to be compile-time selected.

/Bruce
> 
> > prove to be a performance problem we can look to #ifdef it out later.
> > 
> > /Bruce

[dpdk-dev] crypto drivers in the API

[Thomas Monjalon]

In the crypto API, the drivers are listed.
In my opinion, it is a wrong designed and these lists should be removed.
Do we need a deprecation notice to plan this removal in 17.05, while
working on bus abstraction?


lib/librte_cryptodev/rte_cryptodev.h:

#define CRYPTODEV_NAME_NULL_PMD crypto_null
/**< Null crypto PMD device name */
#define CRYPTODEV_NAME_AESNI_MB_PMD crypto_aesni_mb
/**< AES-NI Multi buffer PMD device name */
#define CRYPTODEV_NAME_AESNI_GCM_PMDcrypto_aesni_gcm
/**< AES-NI GCM PMD device name */
#define CRYPTODEV_NAME_OPENSSL_PMD  crypto_openssl
/**< Open SSL Crypto PMD device name */
#define CRYPTODEV_NAME_QAT_SYM_PMD  crypto_qat
/**< Intel QAT Symmetric Crypto PMD device name */
#define CRYPTODEV_NAME_SNOW3G_PMD   crypto_snow3g
/**< SNOW 3G PMD device name */
#define CRYPTODEV_NAME_KASUMI_PMD   crypto_kasumi
/**< KASUMI PMD device name */
#define CRYPTODEV_NAME_ZUC_PMD  crypto_zuc
/**< KASUMI PMD device name */
#define CRYPTODEV_NAME_ARMV8_PMDcrypto_armv8
/**< ARMv8 Crypto PMD device name */
#define CRYPTODEV_NAME_SCHEDULER_PMDcrypto_scheduler
/**< Scheduler Crypto PMD device name */

/** Crypto device type */
enum rte_cryptodev_type {
RTE_CRYPTODEV_NULL_PMD = 1, /**< Null crypto PMD */
RTE_CRYPTODEV_AESNI_GCM_PMD,/**< AES-NI GCM PMD */
RTE_CRYPTODEV_AESNI_MB_PMD, /**< AES-NI multi buffer PMD */
RTE_CRYPTODEV_QAT_SYM_PMD,  /**< QAT PMD Symmetric Crypto */
RTE_CRYPTODEV_SNOW3G_PMD,   /**< SNOW 3G PMD */
RTE_CRYPTODEV_KASUMI_PMD,   /**< KASUMI PMD */
RTE_CRYPTODEV_ZUC_PMD,  /**< ZUC PMD */
RTE_CRYPTODEV_OPENSSL_PMD,/**<  OpenSSL PMD */
RTE_CRYPTODEV_ARMV8_PMD,/**< ARMv8 crypto PMD */
RTE_CRYPTODEV_SCHEDULER_PMD,/**< Crypto Scheduler PMD */
};

Re: [dpdk-dev] crypto drivers in the API

[Thomas Monjalon]

(resent to fix email address)
2017-02-13 14:25, Thomas Monjalon:
> In the crypto API, the drivers are listed.
> In my opinion, it is a wrong designed and these lists should be removed.
> Do we need a deprecation notice to plan this removal in 17.05, while
> working on bus abstraction?
> 
> 
> lib/librte_cryptodev/rte_cryptodev.h:
> 
> #define CRYPTODEV_NAME_NULL_PMD crypto_null
> /**< Null crypto PMD device name */
> #define CRYPTODEV_NAME_AESNI_MB_PMD crypto_aesni_mb
> /**< AES-NI Multi buffer PMD device name */
> #define CRYPTODEV_NAME_AESNI_GCM_PMDcrypto_aesni_gcm
> /**< AES-NI GCM PMD device name */
> #define CRYPTODEV_NAME_OPENSSL_PMD  crypto_openssl
> /**< Open SSL Crypto PMD device name */
> #define CRYPTODEV_NAME_QAT_SYM_PMD  crypto_qat
> /**< Intel QAT Symmetric Crypto PMD device name */
> #define CRYPTODEV_NAME_SNOW3G_PMD   crypto_snow3g
> /**< SNOW 3G PMD device name */
> #define CRYPTODEV_NAME_KASUMI_PMD   crypto_kasumi
> /**< KASUMI PMD device name */
> #define CRYPTODEV_NAME_ZUC_PMD  crypto_zuc
> /**< KASUMI PMD device name */
> #define CRYPTODEV_NAME_ARMV8_PMDcrypto_armv8
> /**< ARMv8 Crypto PMD device name */
> #define CRYPTODEV_NAME_SCHEDULER_PMDcrypto_scheduler
> /**< Scheduler Crypto PMD device name */
> 
> /** Crypto device type */
> enum rte_cryptodev_type {
> RTE_CRYPTODEV_NULL_PMD = 1, /**< Null crypto PMD */
> RTE_CRYPTODEV_AESNI_GCM_PMD,/**< AES-NI GCM PMD */
> RTE_CRYPTODEV_AESNI_MB_PMD, /**< AES-NI multi buffer PMD */
> RTE_CRYPTODEV_QAT_SYM_PMD,  /**< QAT PMD Symmetric Crypto */
> RTE_CRYPTODEV_SNOW3G_PMD,   /**< SNOW 3G PMD */
> RTE_CRYPTODEV_KASUMI_PMD,   /**< KASUMI PMD */
> RTE_CRYPTODEV_ZUC_PMD,  /**< ZUC PMD */
> RTE_CRYPTODEV_OPENSSL_PMD,/**<  OpenSSL PMD */
> RTE_CRYPTODEV_ARMV8_PMD,/**< ARMv8 crypto PMD */
> RTE_CRYPTODEV_SCHEDULER_PMD,/**< Crypto Scheduler PMD */
> };

Re: [dpdk-dev] [PATCH] igb_uio: map dummy dma forcing iommu domain attachment

[Alejandro Lucero]

On Fri, Feb 10, 2017 at 7:03 PM, Ferruh Yigit 
wrote:

> On 2/8/2017 11:54 AM, Alejandro Lucero wrote:
> > Hi Ferruh,
> >
> > On Tue, Feb 7, 2017 at 3:59 PM, Ferruh Yigit  > > wrote:
> >
> > Hi Alejandro,
> >
> > On 1/18/2017 12:27 PM, Alejandro Lucero wrote:
> > > For using a DPDK app when iommu is enabled, it requires to
> > > add iommu=pt to the kernel command line. But using igb_uio driver
> > > makes DMAR errors because the device has not an IOMMU domain.
> >
> > Please help to understand the scope of the problem,
> >
> >
> > After reading your reply, I realize I could have explained it better.
> > First of all, this is related to SRIOV, exactly when the VFs are created.
> >
> >
> > 1- How can you re-produce the problem?
> >
> >
> > Using a VF from a Intel card by a DPDK app in the host and a kernel >=
> > 3.15. Although usually VFs are assigned to VMs, it could also be an
> > option to use VFs by the host.
> >
> > BTW, I did not try to reproduce the problem with an Intel card. I
> > triggered this problem with an NFP, but because the problem behind, I
> > bet that is going to happen for an Intel one as well.
>
> I can able to reproduce the problem with ixgbe, by using VF on the host.
>
> And I verified your patch fixes it, it cause device attached to a vfio
> group.
>
> So, I believe good to get this patch, but it is already to late for
> 17.02 release.
> I suggest getting this one early 17.05, so it gives more time to test.
>
>
Ok.


> >
> >
> >
> > 2- What happens get DMAR errors, is it prevents device work or some
> > annoying error messages?
> >
> >
> > A DMAR error implies the device can not access to the DMA address given
> > by the host. I have experienced several situations where it is just that
> > device not being able to work at all, but it also has more global
> > implications and you need to reboot the system because it is unreliable.
> > I think it depends on how these DMAR errors are handled, but in any
> > case, this is a bad thing.
>
> In my test, implication was device is not working.
>
>
Yes, the device can not work for sure as it has not a IOMMU domain to work
with.
But sometimes the device is so badly after it, it does not help to create
one domain and attach the device to it, and just rebooting the system helps.


> >
> >
> >
> > 3- Can you please share the error messages?
> >
> >
> > With this problem you can expect something like this:
> >
> >  559.163874] DMAR: DRHD: handling fault status reg 2
> > [ 559.165427] DMAR: DMAR:[DMA Read] Request device [82:08.0] fault addr
> > e7b73b000
> > [ 559.165427] DMAR:[fault reason 02] Present bit in context entry is
> clear
> > [ 568.367417] DMAR: DRHD: handling fault status reg 102
> > [ 568.369025] DMAR: DMAR:[DMA Read] Request device [82:08.1] fault addr
> > ebb73b000
> > [ 568.369025] DMAR:[fault reason 02] Present bit in context entry is
> clear
> > [ 571.773944] DMAR: DRHD: handling fault status reg 202
> > [ 571.775550] DMAR: DMAR:[DMA Read] Request device [82:08.2] fault addr
> > efb73b000
> > [ 571.775550] DMAR:[fault reason 02] Present bit in context entry is
> clear
> > [ 575.039654] DMAR: DRHD: handling fault status reg 302
> > [ 575.041259] DMAR: DMAR:[DMA Read] Request device [82:08.3] fault addr
> > f3b73b000
> > [ 575.041259] DMAR:[fault reason 02] Present bit in context entry is
> clear
> >
> > There are different DMAR errors, sometimes referring to a specific
> > address being wrong. In this case it is related to the device not having
> > a context or a IOMMU domain.
> >
> > Also note we got these errors for different devices/VFs. This was with a
> > DPDK app using several VFs.
> >
> >
> >
> >
> > >
> > > Since kernel 3.15, iommu=pt requires to use the internal kernel
> > > DMA API for attaching the device to the IOMMU 1:1 mapping, aka
> > > si_domain. Previous versions did attach the device to that
> > > domain when intel iommu notifier was called.
> >
> > Again, what is not working since 3.15?
> >
> >
> > This specific case, yes. With older kernels, when VFs are created, IOMMU
> > code is executed (notifier chain callback) and if iommu=pt, the VF is
> > attached to the si_domain, this is the 1:1 mapping. But this has changed
> > with newer kernels, and after VFs are created they have no IOMMU domain
> > at all. The kernel expects the driver to implicitly create such a domain
> > when the kernel DMA API is used.
>
> Thanks again for clarification.
> What will be the effect of your patch for kernel < 3.15, should your
> update be protected with a kernel version check, or is it safe for all?
>
>
It is harmless. If the device got an IOMMU domain, like when iommu=pt in
older kernels,
the allocation does nothing. Note that we do not use kernel DMA API with
DPDK apps at all, and this allocation is just for forcing the binding to a
specific IOMMU domain if there is not such a binding yet.

If iommu is enabled, but iommu=pt is not se

Re: [dpdk-dev] [PATCH] igb_uio: map dummy dma forcing iommu domain attachment

[Alejandro Lucero]

On Fri, Feb 10, 2017 at 7:06 PM, Ferruh Yigit 
wrote:

> On 2/10/2017 7:03 PM, Ferruh Yigit wrote:
> > On 2/8/2017 11:54 AM, Alejandro Lucero wrote:
> >> Hi Ferruh,
> >>
> >> On Tue, Feb 7, 2017 at 3:59 PM, Ferruh Yigit  >> > wrote:
> >>
> >> Hi Alejandro,
> >>
> >> On 1/18/2017 12:27 PM, Alejandro Lucero wrote:
> >> > For using a DPDK app when iommu is enabled, it requires to
> >> > add iommu=pt to the kernel command line. But using igb_uio driver
> >> > makes DMAR errors because the device has not an IOMMU domain.
> >>
> >> Please help to understand the scope of the problem,
> >>
> >>
> >> After reading your reply, I realize I could have explained it better.
> >> First of all, this is related to SRIOV, exactly when the VFs are
> created.
> >>
> >>
> >> 1- How can you re-produce the problem?
> >>
> >>
> >> Using a VF from a Intel card by a DPDK app in the host and a kernel >=
> >> 3.15. Although usually VFs are assigned to VMs, it could also be an
> >> option to use VFs by the host.
> >>
> >> BTW, I did not try to reproduce the problem with an Intel card. I
> >> triggered this problem with an NFP, but because the problem behind, I
> >> bet that is going to happen for an Intel one as well.
> >
> > I can able to reproduce the problem with ixgbe, by using VF on the host.
> >
> > And I verified your patch fixes it, it cause device attached to a vfio
> > group.
>
> I want to send this in a separate mail, since not directly related to
> your patch, but while I was testing with vfio-pci I get lower numbers
> comparing to the igb_uio, which is unexpected AFAIK.
>
> Most probably I am doing something wrong, but I would like to ask if are
> you observing same behavior?
>

Can you tell me which test are you running?

Although both, igb_uio and vfio, allow to work with IOMMU, the first one
requires iommu=pt. It implies a single IOMMU domain already created by the
system with the 1:1 mapping being used.  With VFIO, a specific per device
IOMMU domain is created. Depending on how are you measuring performance,
that specific IOMMU domain creation by the DPDK app could have an impact,
but I do not think that should be really significant. But with IOMMU you
have the same problem than with MMU, there is a IOTLB for IOMMU as there is
a TLB for MMU. Depending on the app, some IOMMU/IOTLB contention is likely.
I have done some experiments and still investigating this during my spare
time. It would be worth a talk about this in the next DPDK meeting.


>
> Thanks,
> ferruh
>
>

Re: [dpdk-dev] GSO/GRO support

[Hu, Jiayu]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Kiran KN
> Sent: Saturday, February 11, 2017 6:56 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] GSO/GRO support
> 
> We, at Juniper Opencontrail have added software support for TCP send
> offload and receive offload to DPDK.
> 
> If the community is interested, we can publish/upstream it.
> 
> Pl let us know what you think of it.
> 
> Thanks,
>  Kiran

Hi Kiran,

I am glad to hear this news. And Currently, I work on the design of GRO and GSO 
too.
After your codes or RFC is released, I am happy to join the discussion and do 
some
reviews.

Regards,
Jiayu 

Re: [dpdk-dev] [PATCH] doc: postpone ABI changes to 17.05

[Thomas Monjalon]

2017-02-13 12:05, Olivier Matz:
> Postpone the ABI changes for mempool and mbuf that were planned
> for 17.02 to 17.05.
> 
> Signed-off-by: Olivier Matz 

Applied, thanks

Re: [dpdk-dev] [PATCH] doc: remove announce of Tx preparation

[Thomas Monjalon]

2017-02-13 11:56, Thomas Monjalon:
> The feature is part of 17.02, so the ABI changes notice can be removed.
> 
> Fixes: 4fb7e803eb1a ("ethdev: add Tx preparation")
> 
> Signed-off-by: Thomas Monjalon 

Applied

[dpdk-dev] [PATCH] doc: postpone API change in ethdev

[Thomas Monjalon]

The change of _rte_eth_dev_callback_process has not been done in 17.02.
Let's postpone to 17.05.

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

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 3d72241..6532482 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -23,8 +23,8 @@ Deprecation Notices
   provide a way to handle device initialization currently being done in
   ``eth_driver``.
 
-* ethdev: an API change is planned for 17.02 for the function
-  ``_rte_eth_dev_callback_process``. In 17.02 the function will return an 
``int``
+* ethdev: an API change is planned for 17.05 for the function
+  ``_rte_eth_dev_callback_process``. In 17.05 the function will return an 
``int``
   instead of ``void`` and a fourth parameter ``void *ret_param`` will be added.
 
 * ABI changes are planned for 17.05 in the ``rte_mbuf`` structure: some fields
-- 
2.7.0

[dpdk-dev] [PATCH 2/7] vhost: vhost-user: Add MTU protocol feature support

[Maxime Coquelin]

This patch implements the vhost-user MTU protocol feature support.
When VIRTIO_NET_F_MTU is negotiated, QEMU notifies the vhost-user
backend with the configured MTU if dedicated protocol feature is
supported.

The value can be used by the application to ensure consistency with
value set by the user.

Signed-off-by: Maxime Coquelin 
---
 lib/librte_vhost/vhost.h  |  1 +
 lib/librte_vhost/vhost_user.c | 24 
 lib/librte_vhost/vhost_user.h |  5 -
 3 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
index 6a57bb3..549296f 100644
--- a/lib/librte_vhost/vhost.h
+++ b/lib/librte_vhost/vhost.h
@@ -170,6 +170,7 @@ struct virtio_net {
uint64_tlog_base;
uint64_tlog_addr;
struct ether_addr   mac;
+   uint16_tmtu;
 
uint32_tnr_guest_pages;
uint32_tmax_guest_pages;
diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
index cb2156a..69877a4 100644
--- a/lib/librte_vhost/vhost_user.c
+++ b/lib/librte_vhost/vhost_user.c
@@ -51,6 +51,9 @@
 #include "vhost.h"
 #include "vhost_user.h"
 
+#define VIRTIO_MIN_MTU 68
+#define VIRTIO_MAX_MTU 65535
+
 static const char *vhost_message_str[VHOST_USER_MAX] = {
[VHOST_USER_NONE] = "VHOST_USER_NONE",
[VHOST_USER_GET_FEATURES] = "VHOST_USER_GET_FEATURES",
@@ -72,6 +75,7 @@ static const char *vhost_message_str[VHOST_USER_MAX] = {
[VHOST_USER_GET_QUEUE_NUM]  = "VHOST_USER_GET_QUEUE_NUM",
[VHOST_USER_SET_VRING_ENABLE]  = "VHOST_USER_SET_VRING_ENABLE",
[VHOST_USER_SEND_RARP]  = "VHOST_USER_SEND_RARP",
+   [VHOST_USER_NET_SET_MTU]  = "VHOST_USER_NET_SET_MTU",
 };
 
 static uint64_t
@@ -865,6 +869,22 @@ vhost_user_send_rarp(struct virtio_net *dev, struct 
VhostUserMsg *msg)
return 0;
 }
 
+static int
+vhost_user_net_set_mtu(struct virtio_net *dev, struct VhostUserMsg *msg)
+{
+   if (msg->payload.u64 < VIRTIO_MIN_MTU ||
+   msg->payload.u64 > VIRTIO_MAX_MTU) {
+   RTE_LOG(ERR, VHOST_CONFIG, "Invalid MTU size (%lu)\n",
+   msg->payload.u64);
+
+   return -1;
+   }
+
+   dev->mtu = (uint16_t)msg->payload.u64;
+
+   return 0;
+}
+
 /* return bytes# of read on success or negative val on failure. */
 static int
 read_vhost_message(int sockfd, struct VhostUserMsg *msg)
@@ -1027,6 +1047,10 @@ vhost_user_msg_handler(int vid, int fd)
vhost_user_send_rarp(dev, &msg);
break;
 
+   case VHOST_USER_NET_SET_MTU:
+   ret = vhost_user_net_set_mtu(dev, &msg);
+   break;
+
default:
ret = -1;
break;
diff --git a/lib/librte_vhost/vhost_user.h b/lib/librte_vhost/vhost_user.h
index 179e441..838dec8 100644
--- a/lib/librte_vhost/vhost_user.h
+++ b/lib/librte_vhost/vhost_user.h
@@ -47,11 +47,13 @@
 #define VHOST_USER_PROTOCOL_F_LOG_SHMFD1
 #define VHOST_USER_PROTOCOL_F_RARP 2
 #define VHOST_USER_PROTOCOL_F_REPLY_ACK3
+#define VHOST_USER_PROTOCOL_F_NET_MTU 4
 
 #define VHOST_USER_PROTOCOL_FEATURES   ((1ULL << VHOST_USER_PROTOCOL_F_MQ) | \
 (1ULL << 
VHOST_USER_PROTOCOL_F_LOG_SHMFD) |\
 (1ULL << VHOST_USER_PROTOCOL_F_RARP) | 
\
-(1ULL << 
VHOST_USER_PROTOCOL_F_REPLY_ACK))
+(1ULL << 
VHOST_USER_PROTOCOL_F_REPLY_ACK) | \
+(1ULL << 
VHOST_USER_PROTOCOL_F_NET_MTU))
 
 typedef enum VhostUserRequest {
VHOST_USER_NONE = 0,
@@ -74,6 +76,7 @@ typedef enum VhostUserRequest {
VHOST_USER_GET_QUEUE_NUM = 17,
VHOST_USER_SET_VRING_ENABLE = 18,
VHOST_USER_SEND_RARP = 19,
+   VHOST_USER_NET_SET_MTU = 20,
VHOST_USER_MAX
 } VhostUserRequest;
 
-- 
2.9.3

[dpdk-dev] [PATCH 5/7] net/vhost: Implement mtu_set callback

[Maxime Coquelin]

This patch implements the eth_dev's mtu_set callback.

Signed-off-by: Maxime Coquelin 
---
 doc/guides/nics/features/vhost.ini |  1 +
 drivers/net/vhost/rte_eth_vhost.c  | 18 ++
 2 files changed, 19 insertions(+)

diff --git a/doc/guides/nics/features/vhost.ini 
b/doc/guides/nics/features/vhost.ini
index 23166fb..590dadb 100644
--- a/doc/guides/nics/features/vhost.ini
+++ b/doc/guides/nics/features/vhost.ini
@@ -11,3 +11,4 @@ Basic stats  = Y
 Extended stats   = Y
 x86-32   = Y
 x86-64   = Y
+MTU update   = Y
diff --git a/drivers/net/vhost/rte_eth_vhost.c 
b/drivers/net/vhost/rte_eth_vhost.c
index e98cffd..75feef1 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -575,6 +575,8 @@ new_device(int vid)
for (i = 0; i < rte_vhost_get_queue_num(vid) * VIRTIO_QNUM; i++)
rte_vhost_enable_guest_notification(vid, i, 0);
 
+   rte_vhost_mtu_get(vid, ð_dev->data->mtu);
+
eth_dev->data->dev_link.link_status = ETH_LINK_UP;
 
rte_atomic32_set(&internal->dev_attached, 1);
@@ -966,6 +968,21 @@ eth_link_update(struct rte_eth_dev *dev __rte_unused,
return 0;
 }
 
+static int
+eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
+{
+   if (dev->data->dev_link.link_status != ETH_LINK_UP)
+   return -EAGAIN;
+
+   if (!dev->data->mtu)
+   return -ENOTSUP;
+
+   if (dev->data->mtu != mtu)
+   return -EINVAL;
+
+   return 0;
+}
+
 /**
  * Disable features in feature_mask. Returns 0 on success.
  */
@@ -1002,6 +1019,7 @@ static const struct eth_dev_ops ops = {
.rx_queue_release = eth_queue_release,
.tx_queue_release = eth_queue_release,
.link_update = eth_link_update,
+   .mtu_set = eth_mtu_set,
.stats_get = eth_stats_get,
.stats_reset = eth_stats_reset,
.xstats_reset = vhost_dev_xstats_reset,
-- 
2.9.3

[dpdk-dev] [PATCH 7/7] app/testpmd: print MTU value in show port info

[Maxime Coquelin]

This patch adds MTU display to "show port info" command.

Signed-off-by: Maxime Coquelin 
---
 app/test-pmd/config.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 80491fc..73d9603 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -449,6 +449,7 @@ port_infos_display(portid_t port_id)
struct rte_mempool * mp;
static const char *info_border = "*";
portid_t pid;
+   uint16_t mtu;
 
if (port_id_is_invalid(port_id, ENABLED_WARN)) {
printf("Valid port range is [0");
@@ -480,6 +481,10 @@ port_infos_display(portid_t port_id)
printf("Link speed: %u Mbps\n", (unsigned) link.link_speed);
printf("Link duplex: %s\n", (link.link_duplex == ETH_LINK_FULL_DUPLEX) ?
   ("full-duplex") : ("half-duplex"));
+
+   if (!rte_eth_dev_get_mtu(port_id, &mtu))
+   printf("MTU: %u\n", mtu);
+
printf("Promiscuous mode: %s\n",
   rte_eth_promiscuous_get(port_id) ? "enabled" : "disabled");
printf("Allmulticast mode: %s\n",
-- 
2.9.3

[dpdk-dev] [PATCH 6/7] net/virtio: Add MTU feature support

[Maxime Coquelin]

This patch implements support for the Virtio MTU feature.
When negotiated, the host shares its maximum supported MTU,
which is used as initial MTU and as maximum MTU the application
can set.

Signed-off-by: Maxime Coquelin 
---
 doc/guides/nics/features/virtio.ini |  1 +
 drivers/net/virtio/virtio_ethdev.c  | 22 --
 drivers/net/virtio/virtio_ethdev.h  |  3 ++-
 drivers/net/virtio/virtio_pci.h |  3 +++
 4 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/doc/guides/nics/features/virtio.ini 
b/doc/guides/nics/features/virtio.ini
index 5164937..7bea075 100644
--- a/doc/guides/nics/features/virtio.ini
+++ b/doc/guides/nics/features/virtio.ini
@@ -24,3 +24,4 @@ ARMv8= Y
 x86-32   = Y
 x86-64   = Y
 Usage doc= Y
+MTU update   = Y
diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index d1ff234..ad3e6e1 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -721,10 +721,13 @@ virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
uint32_t ether_hdr_len = ETHER_HDR_LEN + VLAN_TAG_LEN +
 hw->vtnet_hdr_size;
uint32_t frame_size = mtu + ether_hdr_len;
+   uint32_t max_frame_size = hw->max_mtu + ether_hdr_len;
 
-   if (mtu < ETHER_MIN_MTU || frame_size > VIRTIO_MAX_RX_PKTLEN) {
+   max_frame_size = RTE_MIN(max_frame_size, VIRTIO_MAX_RX_PKTLEN);
+
+   if (mtu < ETHER_MIN_MTU || frame_size > max_frame_size) {
PMD_INIT_LOG(ERR, "MTU should be between %d and %d",
-   ETHER_MIN_MTU, VIRTIO_MAX_RX_PKTLEN - ether_hdr_len);
+   ETHER_MIN_MTU, max_frame_size - ether_hdr_len);
return -EINVAL;
}
return 0;
@@ -1392,6 +1395,21 @@ virtio_init_device(struct rte_eth_dev *eth_dev, uint64_t 
req_features)
 
hw->max_queue_pairs = config->max_virtqueue_pairs;
 
+   if (vtpci_with_feature(hw, VIRTIO_NET_F_MTU)) {
+   vtpci_read_dev_config(hw,
+   offsetof(struct virtio_net_config, mtu),
+   &config->mtu,
+   sizeof(config->mtu));
+
+   hw->max_mtu = config->mtu;
+   /* Set initial MTU to maximum one supported by vhost */
+   eth_dev->data->mtu = config->mtu;
+
+   } else {
+   hw->max_mtu = VIRTIO_MAX_RX_PKTLEN - ETHER_HDR_LEN -
+   VLAN_TAG_LEN - hw->vtnet_hdr_size;
+   }
+
PMD_INIT_LOG(DEBUG, "config->max_virtqueue_pairs=%d",
config->max_virtqueue_pairs);
PMD_INIT_LOG(DEBUG, "config->status=%d", config->status);
diff --git a/drivers/net/virtio/virtio_ethdev.h 
b/drivers/net/virtio/virtio_ethdev.h
index 777a14b..aa78adc 100644
--- a/drivers/net/virtio/virtio_ethdev.h
+++ b/drivers/net/virtio/virtio_ethdev.h
@@ -51,7 +51,7 @@
 #define VIRTIO_MAX_TX_QUEUES 128U
 #define VIRTIO_MAX_MAC_ADDRS 64
 #define VIRTIO_MIN_RX_BUFSIZE 64
-#define VIRTIO_MAX_RX_PKTLEN  9728
+#define VIRTIO_MAX_RX_PKTLEN  9728U
 
 /* Features desired/implemented by this driver. */
 #define VIRTIO_PMD_DEFAULT_GUEST_FEATURES  \
@@ -66,6 +66,7 @@
 1u << VIRTIO_NET_F_HOST_TSO4 | \
 1u << VIRTIO_NET_F_HOST_TSO6 | \
 1u << VIRTIO_NET_F_MRG_RXBUF | \
+1u << VIRTIO_NET_F_MTU | \
 1u << VIRTIO_RING_F_INDIRECT_DESC |\
 1ULL << VIRTIO_F_VERSION_1   | \
 1ULL << VIRTIO_F_IOMMU_PLATFORM)
diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h
index 59e45c4..771f5b1 100644
--- a/drivers/net/virtio/virtio_pci.h
+++ b/drivers/net/virtio/virtio_pci.h
@@ -106,6 +106,7 @@ struct virtnet_ctl;
 /* The feature bitmap for virtio net */
 #define VIRTIO_NET_F_CSUM  0   /* Host handles pkts w/ partial csum */
 #define VIRTIO_NET_F_GUEST_CSUM1   /* Guest handles pkts w/ 
partial csum */
+#define VIRTIO_NET_F_MTU   3   /* Initial MTU advice. */
 #define VIRTIO_NET_F_MAC   5   /* Host has given MAC address. */
 #define VIRTIO_NET_F_GUEST_TSO47   /* Guest can handle TSOv4 in. */
 #define VIRTIO_NET_F_GUEST_TSO68   /* Guest can handle TSOv6 in. */
@@ -251,6 +252,7 @@ struct virtio_hw {
uint64_treq_guest_features;
uint64_tguest_features;
uint32_tmax_queue_pairs;
+   uint16_tmax_mtu;
uint16_tvtnet_hdr_size;
uint8_t vlan_strip;
uint8_t use_msix;
@@ -296,6 +298,7 @@ struct virtio_net_config {
/* See VIRTIO_NET_F_STATUS and VIRTIO_NET_S_* above */
uint16_t   status;
uint16_t   max_virtqueue_pairs;
+   uint16_t   mtu;
 } __attribute__((packed));
 
 /*
-- 
2.9.3

[dpdk-dev] [PATCH 1/7] vhost: Enable VIRTIO_NET_F_MTU feature

[Maxime Coquelin]

This patch enables the new VIRTIO_NET_F_MTU feature,
which makes possible for the host to advise the guest
with its maximum supported MTU.

MTU value is set via QEMU parameters, either via Libvirt XML, or
directly in virtio-net device command line arguments.

Signed-off-by: Maxime Coquelin 
---
 lib/librte_vhost/vhost.c | 3 ++-
 lib/librte_vhost/vhost.h | 6 +-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
index e415093..3974087 100644
--- a/lib/librte_vhost/vhost.c
+++ b/lib/librte_vhost/vhost.c
@@ -66,7 +66,8 @@
(1ULL << VIRTIO_NET_F_GUEST_CSUM) | \
(1ULL << VIRTIO_NET_F_GUEST_TSO4) | \
(1ULL << VIRTIO_NET_F_GUEST_TSO6) | \
-   (1ULL << VIRTIO_RING_F_INDIRECT_DESC))
+   (1ULL << VIRTIO_RING_F_INDIRECT_DESC) | \
+   (1ULL << VIRTIO_NET_F_MTU))
 
 uint64_t VHOST_FEATURES = VHOST_SUPPORTED_FEATURES;
 
diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
index 22564f1..6a57bb3 100644
--- a/lib/librte_vhost/vhost.h
+++ b/lib/librte_vhost/vhost.h
@@ -110,11 +110,15 @@ struct vhost_virtqueue {
uint16_tshadow_used_idx;
 } __rte_cache_aligned;
 
-/* Old kernels have no such macro defined */
+/* Old kernels have no such macros defined */
 #ifndef VIRTIO_NET_F_GUEST_ANNOUNCE
  #define VIRTIO_NET_F_GUEST_ANNOUNCE 21
 #endif
 
+#ifndef VIRTIO_NET_F_MTU
+ #define VIRTIO_NET_F_MTU 3
+#endif
+
 
 /*
  * Make an extra wrapper for VIRTIO_NET_F_MQ and
-- 
2.9.3

Re: [dpdk-dev] [PATCH] doc: remove deprecation notice for rte_bus

[Thomas Monjalon]

2017-02-13 17:25, Shreyansh Jain:
> Signed-off-by: Shreyansh Jain 
> ---
> -* ABI/API changes are planned for 17.02: ``rte_device``, ``rte_driver`` will 
> be
> -  impacted because of introduction of a new ``rte_bus`` hierarchy. This would
> -  also impact the way devices are identified by EAL. A bus-device-driver 
> model
> -  will be introduced providing a hierarchical view of devices.

Applied, thanks

rte_device/rte_driver have not been impacted and should not be when implementing
the buses.

[dpdk-dev] [PATCH 4/7] vhost: Add API to get/set MTU value

[Maxime Coquelin]

This patch implements two functions for the application to
get/set the MTU value.

rte_vhost_mtu_get() set the mtu parameter with the MTU value
set in QEMU if VIRTIO_NET_F_MTU has been negotiated and returns 0,
-ENOTSUP otherwise.

rte_vhost_mtu_set() doesn't actually permit to change the MTU,
which can only be set once before feature negotiation, but the
function returns 0 if the MTU value the application tries to set
is the same that have been set in QEMU, -EINVAL if different and
-ENOTSUP if VIRTIO_NET_F_MTU hasn't been negotiated.

The two functions returns -EAGAIN if Virtio feature negotiation
didn't happened yet.

Signed-off-by: Maxime Coquelin 
---
 lib/librte_vhost/rte_virtio_net.h | 31 +++
 lib/librte_vhost/vhost.c  | 39 +++
 2 files changed, 70 insertions(+)

diff --git a/lib/librte_vhost/rte_virtio_net.h 
b/lib/librte_vhost/rte_virtio_net.h
index 926039c..8d84dbf 100644
--- a/lib/librte_vhost/rte_virtio_net.h
+++ b/lib/librte_vhost/rte_virtio_net.h
@@ -100,6 +100,37 @@ int rte_vhost_driver_callback_register(struct 
virtio_net_device_ops const * cons
 int rte_vhost_driver_session_start(void);
 
 /**
+ * Get the MTU value of the device if set in QEMU.
+ *
+ * @param vid
+ *  virtio-net device ID
+ * @param mtu
+ *  The variable to store the MTU value
+ *
+ * @return
+ *  0: success
+ *  -EAGAIN: device not yet started
+ *  -ENOTSUP: device does not support MTU feature
+ */
+int rte_vhost_mtu_get(int vid, uint16_t *mtu);
+
+/**
+ * Set the MTU value of the device.
+ *
+ * @param vid
+ *  virtio-net device ID
+ * @param mtu
+ *  The MTU value
+ *
+ * @return
+ *  0: success
+ *  -EAGAIN: device not yet started
+ *  -ENOTSUP: device does not support MTU feature
+ *  -EINVAL: MTU value different from the one set in QEMU
+ */
+int rte_vhost_mtu_set(int vid, uint16_t mtu);
+
+/**
  * Get the numa node from which the virtio net device's memory
  * is allocated.
  *
diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
index 3974087..20d0061 100644
--- a/lib/librte_vhost/vhost.c
+++ b/lib/librte_vhost/vhost.c
@@ -313,6 +313,45 @@ vhost_enable_dequeue_zero_copy(int vid)
 }
 
 int
+rte_vhost_mtu_get(int vid, uint16_t *mtu)
+{
+   struct virtio_net *dev = get_device(vid);
+
+   if (!dev)
+   return -ENODEV;
+
+   if (!(dev->flags & VIRTIO_DEV_READY))
+   return -EAGAIN;
+
+   if (!(dev->features & VIRTIO_NET_F_MTU))
+   return -ENOTSUP;
+
+   *mtu = dev->mtu;
+
+   return 0;
+}
+
+int
+rte_vhost_mtu_set(int vid, uint16_t mtu)
+{
+   struct virtio_net *dev = get_device(vid);
+
+   if (!dev)
+   return -ENODEV;
+
+   if (!(dev->flags & VIRTIO_DEV_READY))
+   return -EAGAIN;
+
+   if (!(dev->features & VIRTIO_NET_F_MTU))
+   return -ENOTSUP;
+
+   if (dev->mtu != mtu)
+   return -EINVAL;
+
+   return 0;
+}
+
+int
 rte_vhost_get_numa_node(int vid)
 {
 #ifdef RTE_LIBRTE_VHOST_NUMA
-- 
2.9.3

[dpdk-dev] [PATCH 3/7] vhost: Add new ready status flag

[Maxime Coquelin]

This patch adds a new status flag indicating the Virtio device
is ready to operate.

Signed-off-by: Maxime Coquelin 
---
 lib/librte_vhost/vhost.h  |  2 ++
 lib/librte_vhost/vhost_user.c | 20 +---
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
index 549296f..e8b7e44 100644
--- a/lib/librte_vhost/vhost.h
+++ b/lib/librte_vhost/vhost.h
@@ -46,6 +46,8 @@
 
 /* Used to indicate that the device is running on a data core */
 #define VIRTIO_DEV_RUNNING 1
+/* Used to indicate that the device is ready to operate */
+#define VIRTIO_DEV_READY 2
 
 /* Backend value set by guest. */
 #define VIRTIO_DEV_STOPPED -1
diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
index 69877a4..4726aaf 100644
--- a/lib/librte_vhost/vhost_user.c
+++ b/lib/librte_vhost/vhost_user.c
@@ -691,14 +691,18 @@ vhost_user_set_vring_kick(struct virtio_net *dev, struct 
VhostUserMsg *pmsg)
close(vq->kickfd);
vq->kickfd = file.fd;
 
-   if (virtio_is_ready(dev) && !(dev->flags & VIRTIO_DEV_RUNNING)) {
-   if (dev->dequeue_zero_copy) {
-   RTE_LOG(INFO, VHOST_CONFIG,
-   "dequeue zero copy is enabled\n");
-   }
+   if (virtio_is_ready(dev)) {
+   dev->flags |= VIRTIO_DEV_READY;
+
+   if (!(dev->flags & VIRTIO_DEV_RUNNING)) {
+   if (dev->dequeue_zero_copy) {
+   RTE_LOG(INFO, VHOST_CONFIG,
+   "dequeue zero copy is 
enabled\n");
+   }
 
-   if (notify_ops->new_device(dev->vid) == 0)
-   dev->flags |= VIRTIO_DEV_RUNNING;
+   if (notify_ops->new_device(dev->vid) == 0)
+   dev->flags |= VIRTIO_DEV_RUNNING;
+   }
}
 }
 
@@ -733,6 +737,8 @@ vhost_user_get_vring_base(struct virtio_net *dev,
notify_ops->destroy_device(dev->vid);
}
 
+   dev->flags &= ~VIRTIO_DEV_READY;
+
/* Here we are safe to get the last used index */
state->num = vq->last_used_idx;
 
-- 
2.9.3

[dpdk-dev] [PATCH 0/7] virtio/vhost: Add MTU feature support

[Maxime Coquelin]

This series adds support to new Virtio's MTU feature[1]. The MTU
value is set via QEMU parameters.

If the feature is negotiated (i.e supported by both host andcguest,
and valid MTU value is set in QEMU via its host_mtu parameter), QEMU
shares the configured MTU value throught dedicated Vhost protocol
feature.

On vhost side, the value is stored in the virtio_net structure, and
made available to the application thanks to new vhost lib's
rte_vhost_mtu_get() function.

rte_vhost_mtu_set() functions is implemented, but only succeed if the
application sets the same value as the one set in QEMU. Idea is that
it would be used for the application to ensure configured MTU value
is consistent, but maybe the mtu_get() API is enough, and mtu_set()
could just be dropped. Vhost PMD mtu_set callback is also implemented
in the same spirit.

To be able to set eth_dev's MTU value at the right time, i.e. to call
rte_vhost_mtu_get() just after Virtio features have been negotiated
and before the device is really started, a new vhost flag has been
introduced (VIRTIO_DEV_READY), because the VIRTIO_DEV_RUNNING flag is
set too late (after .new_device() ops is called).

Regarding valid MTU values, the maximum MTU value accepted on vhost
side is 65535 bytes, as defined in Virtio Spec and supported in
Virtio-net Kernel driver. But in Virtio PMD, current maximum frame
size is 9728 bytes (~9700 bytes MTU). So maximum MTU size accepted in
Virtio PMD is the minimum between ~9700 bytes and host's MTU.

Initially, we thought about disabling the rx-mergeable feature when
MTU value was low enough to ensure all received packets would fit in
receive buffers (when offloads are disabled). Doing this, we would
save one cache-miss in the receive path. Problem is that we don't
know the buffers size at Virtio feature neogotiation time.
It might be possible for the application to call the configure
callback again once the Rx queue is set up, but it seems a bit hacky.
So I decided to skip this optimization for now, even if feedback and
are of course appreciated.

Finally, this series also adds MTU value printing  in testpmd's
"show port info" command when non-zero.

This series target v17.05 release.

Cheers,
Maxime

Maxime Coquelin (7):
  vhost: Enable VIRTIO_NET_F_MTU feature
  vhost: vhost-user: Add MTU protocol feature support
  vhost: Add new ready status flag
  vhost: Add API to get/set MTU value
  net/vhost: Implement mtu_set callback
  net/virtio: Add MTU feature support
  app/testpmd: print MTU value in show port info

 app/test-pmd/config.c   |  5 +
 doc/guides/nics/features/vhost.ini  |  1 +
 doc/guides/nics/features/virtio.ini |  1 +
 drivers/net/vhost/rte_eth_vhost.c   | 18 +++
 drivers/net/virtio/virtio_ethdev.c  | 22 +--
 drivers/net/virtio/virtio_ethdev.h  |  3 ++-
 drivers/net/virtio/virtio_pci.h |  3 +++
 lib/librte_vhost/rte_virtio_net.h   | 31 ++
 lib/librte_vhost/vhost.c| 42 ++-
 lib/librte_vhost/vhost.h|  9 +++-
 lib/librte_vhost/vhost_user.c   | 44 +++--
 lib/librte_vhost/vhost_user.h   |  5 -
 12 files changed, 171 insertions(+), 13 deletions(-)

-- 
2.9.3

Re: [dpdk-dev] cryptodev - Session and queue pair relationship

[Akhil Goyal]

On 2/8/2017 2:22 AM, Declan Doherty wrote:

On 06/02/17 13:35, Akhil Goyal wrote:

Hi,


Hey Akhil, see my thoughts inline


I have some issues w.r.t the mapping sessions and queue pairs.

As per my understanding:
- Number of sessions may be large – they are independent of number of
queue pairs


Yes, cryptodev assumes no implicit connection between sessions and
queue pairs, the current PMDs just use the crypto session to store the
immutable data (keys etc) for a particular crypto transform or chain of
transforms in a format specific to that PMD with no statefull information.


- Queue pairs are L-core specific


Not exactly, queue pairs like ethdev queues are not thread safe, so we
assume that only a single l-core will be using a queue pair at any time
unless the application layer has introduce a locking mechanism to
provide thread safety.


- Depending on the implementation, one queue pair can be mapped to many
sessions. Or, Only one queue pair for every session- especially in the
systems having large number of queues (hw).


Currently none of the software crypto PMDs or Intel QuickAssist hardware
accelerated PMD make any assumptions regarding coupling/mapping of
sessions to queue pairs, so today a users could freely change the queue
pair which a session is processed on, or even go as far using the  ame
session for processing on different queue simultaneously as the sessions
are stateless, obviously this could introduce issues for statefull
higher level protocol using the cryptodev PMD service but the cryptodev
API doesn't prohibit this usage model.



- Sessions can be created on the fly – typical rekeying use-cases.
Generally done by the control threads.



Sure, there is no restriction on session creation other than an element
being free in the mempool which the session is being created on.


There seems to be no straight way for the underlying driver
implementation to know, what all sessions are mapped to a particular
queue pair. The session and queue pair information is first time exposed
in the enqueue command.

One of the NXP Crypto Hardware drivers uses per session data structures
(descriptors) which need to be configured for hardware queues.  Though
this information can be extracted from the first enqueue command for a
particular session, it will add checks in the data path. Also, it will
bring down the connection setup rate.


We haven't had to support this model of coupling sessions to queue pairs
in any PMDs before. If I understand correctly, in the hardware model you
need to support a queue pair can only be configured to support the
processing of a single session at any one time and it only supports that
session until it is reconfigured, is this correct? So if a session needs
to be re-keyed the queue pair would need to be reconfigured?

yes it is correct.




In the API rte_cryptodev_sym_session_create(), we create session on a
particular device, but there is no information of queue pair being
shared.

1. We want to propose to change the session create/config API to also
take queue pair id as argument.
struct rte_cryptodev_sym_session *
rte_cryptodev_sym_session_create(uint8_t dev_id,
  struct rte_crypto_sym_xform *xform) to
also take “uint16_t qp;”

This will also return “in-use” error, if the underlying hardware only
support 1 session/descriptor per qp.


I my mind the idea of coupling the session_create function to the queue
pair of a device doesn't feel right as it would certainly put
unnecessary constraint on all existing PMDs queue pairs.

One possible approach would be to extend the the queue_pair_setup
function to take an opaque parameter which would allow you to pass a
session through and would be  an approach more in keeping with the
cryptodev current model, but you would then still need to verify that
the operations being enqueued have the same session as the configured
device, assuming that the packet are being enqueued from the host.

If you need to re-key or change the session you could re-initialize the
queue pair while the device is still active, but stopping the queue pair.

Following a sequence something like:
stop_qp()
setup_qp()
start_qp()


Another option Fiona suggested would be to add 2 new APIs

rte_cryptodev_queue_pair_attach_sym_session/queue_pair_detach_sym_session this
would allow dynamic attaching of one or more sessions to device if it
supported this sort of static mapping of sessions to queue pairs.




2. Currently the application configures the *nb_descriptors* in the
*rte_cryptodev_queue_pair_setup*. Should we add the queue pair
capability API?



Regarding capabilities, I think this should be just propagated through
the device capabilities, something like a max number of session mapped
per queue pair, which would be zero for all/most current devices, and
could be 1 or greater for your device. This is assuming that all queue
pairs can all support the same crypto transforms capabilities and that
different queue pairs have differen

Re: [dpdk-dev] cryptodev - Session and queue pair relationship

[Trahe, Fiona]

Hi Akhil

> -Original Message-
> From: Akhil Goyal [mailto:akhil.go...@nxp.com]
> Sent: Monday, February 13, 2017 2:39 PM
> To: Doherty, Declan ; dev@dpdk.org; De Lara
> Guarch, Pablo ; Jain, Deepak K
> 
> Cc: hemant.agra...@nxp.com; Trahe, Fiona 
> Subject: Re: cryptodev - Session and queue pair relationship
> 
> On 2/8/2017 2:22 AM, Declan Doherty wrote:
> > On 06/02/17 13:35, Akhil Goyal wrote:
> >> Hi,
> >>
> > Hey Akhil, see my thoughts inline
> >
> >> I have some issues w.r.t the mapping sessions and queue pairs.
> >>
> >> As per my understanding:
> >> - Number of sessions may be large - they are independent of number of
> >> queue pairs
> >
> > Yes, cryptodev assumes no implicit connection between sessions and
> > queue pairs, the current PMDs just use the crypto session to store the
> > immutable data (keys etc) for a particular crypto transform or chain of
> > transforms in a format specific to that PMD with no statefull information.
> >
> >> - Queue pairs are L-core specific
> >
> > Not exactly, queue pairs like ethdev queues are not thread safe, so we
> > assume that only a single l-core will be using a queue pair at any time
> > unless the application layer has introduce a locking mechanism to
> > provide thread safety.
> >
> >> - Depending on the implementation, one queue pair can be mapped to
> many
> >> sessions. Or, Only one queue pair for every session- especially in the
> >> systems having large number of queues (hw).
> >
> > Currently none of the software crypto PMDs or Intel QuickAssist hardware
> > accelerated PMD make any assumptions regarding coupling/mapping of
> > sessions to queue pairs, so today a users could freely change the queue
> > pair which a session is processed on, or even go as far using the  ame
> > session for processing on different queue simultaneously as the sessions
> > are stateless, obviously this could introduce issues for statefull
> > higher level protocol using the cryptodev PMD service but the cryptodev
> > API doesn't prohibit this usage model.
> >
> >
> >> - Sessions can be created on the fly - typical rekeying use-cases.
> >> Generally done by the control threads.
> >>
> >
> > Sure, there is no restriction on session creation other than an element
> > being free in the mempool which the session is being created on.
> >
> >> There seems to be no straight way for the underlying driver
> >> implementation to know, what all sessions are mapped to a particular
> >> queue pair. The session and queue pair information is first time exposed
> >> in the enqueue command.
> >>
> >> One of the NXP Crypto Hardware drivers uses per session data structures
> >> (descriptors) which need to be configured for hardware queues.  Though
> >> this information can be extracted from the first enqueue command for a
> >> particular session, it will add checks in the data path. Also, it will
> >> bring down the connection setup rate.
> >
> > We haven't had to support this model of coupling sessions to queue pairs
> > in any PMDs before. If I understand correctly, in the hardware model you
> > need to support a queue pair can only be configured to support the
> > processing of a single session at any one time and it only supports that
> > session until it is reconfigured, is this correct? So if a session needs
> > to be re-keyed the queue pair would need to be reconfigured?
> yes it is correct.
> >
> >>
> >> In the API rte_cryptodev_sym_session_create(), we create session on a
> >> particular device, but there is no information of queue pair being
> >> shared.
> >>
> >> 1. We want to propose to change the session create/config API to also
> >> take queue pair id as argument.
> >> struct rte_cryptodev_sym_session *
> >> rte_cryptodev_sym_session_create(uint8_t dev_id,
> >>   struct rte_crypto_sym_xform *xform) to
> >> also take "uint16_t qp;"
> >>
> >> This will also return "in-use" error, if the underlying hardware only
> >> support 1 session/descriptor per qp.
> >
> > I my mind the idea of coupling the session_create function to the queue
> > pair of a device doesn't feel right as it would certainly put
> > unnecessary constraint on all existing PMDs queue pairs.
> >
> > One possible approach would be to extend the the queue_pair_setup
> > function to take an opaque parameter which would allow you to pass a
> > session through and would be  an approach more in keeping with the
> > cryptodev current model, but you would then still need to verify that
> > the operations being enqueued have the same session as the configured
> > device, assuming that the packet are being enqueued from the host.
> >
> > If you need to re-key or change the session you could re-initialize the
> > queue pair while the device is still active, but stopping the queue pair.
> >
> > Following a sequence something like:
> > stop_qp()
> > setup_qp()
> > start_qp()
> >
> >
> > Another option Fiona suggested would be to add 2 new APIs
> >
> >
> rte_cryptodev_queue_pair_attach_sy

Re: [dpdk-dev] [PATCH] doc: add deprecation note for rework of PCI in EAL

[Thomas Monjalon]

2017-02-13 17:30, Shreyansh Jain:
> On Monday 13 February 2017 05:25 PM, Shreyansh Jain wrote:
> > EAL PCI layer is planned to be restructured in 17.05 to unlink it from
> > generic structures like eth_driver, rte_cryptodev_driver, and also move
> > it into a PCI Bus.
> >
> > Signed-off-by: Shreyansh Jain 
> > ---
> >  doc/guides/rel_notes/deprecation.rst | 12 
> >  1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst 
> > b/doc/guides/rel_notes/deprecation.rst
> > index fbe2fcb..b12d435 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -13,10 +13,14 @@ Deprecation Notices
> >has exposed, like the way we have done with uio-pci-generic. This change
> >targets release 17.05.
> >
> > -* ``eth_driver`` is planned to be removed in 17.02. This currently serves 
> > as
> > -  a placeholder for PMDs to register themselves. Changes for ``rte_bus`` 
> > will
> > -  provide a way to handle device initialization currently being done in
> > -  ``eth_driver``.
> 
> Just to highlight, above statement was added by me in 16.11.
> As of now I plan to work on removing rte_pci_driver from eth_driver,
> rather than removing eth_driver all together (which, probably, was
> better idea).
> If someone still wishes to work on its complete removal, we can keep
> the above. (and probably remove the below).

Yes I think we should keep the original idea.
I will work on it with Jan Blunck and Stephen Hemminger I think.

> > +* ABI/API changes are planned for 17.05 for PCI subsystem. This is to
> > +  unlink EAL dependency on PCI and to move PCI devices to a PCI specific
> > +  bus.
> > +
> > +* ``rte_pci_driver`` is planned to be removed from ``eth_driver`` in 17.05.
> > +  This is to unlink the ethernet driver from PCI dependencies.
> > +  Similarly, ``rte_pci_driver`` in planned to be removed from
> > +  ``rte_cryptodev_driver`` in 17.05.

I am going to reword it in a v2.

Re: [dpdk-dev] cryptodev - Session and queue pair relationship

[Trahe, Fiona]

Hi Akhil, 

> -Original Message-
> From: Trahe, Fiona
> Sent: Monday, February 13, 2017 2:45 PM
> To: Akhil Goyal ; Doherty, Declan
> ; dev@dpdk.org; De Lara Guarch, Pablo
> ; Jain, Deepak K 
> Cc: hemant.agra...@nxp.com; Trahe, Fiona 
> Subject: RE: cryptodev - Session and queue pair relationship
> 
> Hi Akhil
> 
> > -Original Message-
> > From: Akhil Goyal [mailto:akhil.go...@nxp.com]
> > Sent: Monday, February 13, 2017 2:39 PM
> > To: Doherty, Declan ; dev@dpdk.org; De Lara
> > Guarch, Pablo ; Jain, Deepak K
> > 
> > Cc: hemant.agra...@nxp.com; Trahe, Fiona 
> > Subject: Re: cryptodev - Session and queue pair relationship
> >
> > On 2/8/2017 2:22 AM, Declan Doherty wrote:
> > > On 06/02/17 13:35, Akhil Goyal wrote:
> > >> Hi,
> > >>
> > > Hey Akhil, see my thoughts inline
> > >
> > >> I have some issues w.r.t the mapping sessions and queue pairs.
> > >>
> > >> As per my understanding:
> > >> - Number of sessions may be large - they are independent of number of
> > >> queue pairs
> > >
> > > Yes, cryptodev assumes no implicit connection between sessions and
> > > queue pairs, the current PMDs just use the crypto session to store the
> > > immutable data (keys etc) for a particular crypto transform or chain of
> > > transforms in a format specific to that PMD with no statefull information.
> > >
> > >> - Queue pairs are L-core specific
> > >
> > > Not exactly, queue pairs like ethdev queues are not thread safe, so we
> > > assume that only a single l-core will be using a queue pair at any time
> > > unless the application layer has introduce a locking mechanism to
> > > provide thread safety.
> > >
> > >> - Depending on the implementation, one queue pair can be mapped to
> > many
> > >> sessions. Or, Only one queue pair for every session- especially in the
> > >> systems having large number of queues (hw).
> > >
> > > Currently none of the software crypto PMDs or Intel QuickAssist hardware
> > > accelerated PMD make any assumptions regarding coupling/mapping of
> > > sessions to queue pairs, so today a users could freely change the queue
> > > pair which a session is processed on, or even go as far using the  ame
> > > session for processing on different queue simultaneously as the sessions
> > > are stateless, obviously this could introduce issues for statefull
> > > higher level protocol using the cryptodev PMD service but the cryptodev
> > > API doesn't prohibit this usage model.
> > >
> > >
> > >> - Sessions can be created on the fly - typical rekeying use-cases.
> > >> Generally done by the control threads.
> > >>
> > >
> > > Sure, there is no restriction on session creation other than an element
> > > being free in the mempool which the session is being created on.
> > >
> > >> There seems to be no straight way for the underlying driver
> > >> implementation to know, what all sessions are mapped to a particular
> > >> queue pair. The session and queue pair information is first time exposed
> > >> in the enqueue command.
> > >>
> > >> One of the NXP Crypto Hardware drivers uses per session data structures
> > >> (descriptors) which need to be configured for hardware queues.  Though
> > >> this information can be extracted from the first enqueue command for a
> > >> particular session, it will add checks in the data path. Also, it will
> > >> bring down the connection setup rate.
> > >
> > > We haven't had to support this model of coupling sessions to queue pairs
> > > in any PMDs before. If I understand correctly, in the hardware model you
> > > need to support a queue pair can only be configured to support the
> > > processing of a single session at any one time and it only supports that
> > > session until it is reconfigured, is this correct? So if a session needs
> > > to be re-keyed the queue pair would need to be reconfigured?
> > yes it is correct.
> > >
> > >>
> > >> In the API rte_cryptodev_sym_session_create(), we create session on a
> > >> particular device, but there is no information of queue pair being
> > >> shared.
> > >>
> > >> 1. We want to propose to change the session create/config API to also
> > >> take queue pair id as argument.
> > >> struct rte_cryptodev_sym_session *
> > >> rte_cryptodev_sym_session_create(uint8_t dev_id,
> > >>   struct rte_crypto_sym_xform *xform) to
> > >> also take "uint16_t qp;"
> > >>
> > >> This will also return "in-use" error, if the underlying hardware only
> > >> support 1 session/descriptor per qp.
> > >
> > > I my mind the idea of coupling the session_create function to the queue
> > > pair of a device doesn't feel right as it would certainly put
> > > unnecessary constraint on all existing PMDs queue pairs.
> > >
> > > One possible approach would be to extend the the queue_pair_setup
> > > function to take an opaque parameter which would allow you to pass a
> > > session through and would be  an approach more in keeping with the
> > > cryptodev current model, but you would then still need to verify that

Re: [dpdk-dev] [dpdk-techboard] decision process and DPDK scope

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen Hemminger
> Sent: Thursday, February 9, 2017 10:49 PM
> To: Richardson, Bruce 
> Cc: Thomas Monjalon ; dev@dpdk.org;
> techbo...@dpdk.org
> Subject: Re: [dpdk-dev] [dpdk-techboard] decision process and DPDK scope
> 
> On Thu, 9 Feb 2017 12:20:47 +
> Bruce Richardson  wrote:
> 
> > > I think we can use this case to avoid seeing it again in the future.
> > > I suggest that the technical board should check whether every new
> > > proposed features are explained, discussed and approved enough in the
> community.
> > > If needed, the technical board meeting minutes will give some lights
> > > to the threads which require more attention.
> > > Before adding a new library or adding a major API, there should be
> > > some strong reviews which include discussing the DPDK scope.
> > >
> >
> > The bigger question here is the default position of the DPDK community
> > - default accept, or default reject. Your statements above all are
> > very much keeping in the style of default reject i.e. every patch or
> > change suggested is assumed to be unfit for acceptance unless reviewed
> > in detail to prove beyond doubt otherwise.
> >
> > I believe that we should change this default position, as I think that
> > reject by default is hurting the community and will continue to do so.
> >
> > NOTE: I am not suggesting that we allow all code in with zero review,
> > but I am suggesting that if something has been reviewed and acked by
> > at least one reviewer it should be autom
> 
> I agree but in a more assertive manner. The maintainer should be the
> default and active reviewer of all submissions. Like other projects the
> maintainers job is to review and accept (or provide constructive
> feedback). Otherwise the job could just by done by some manager.
> 
> But recently, I have changed my mind. The current DPDK project model is
> not scaling well. After hearing some of the arguments in favor of a
> multiple committer model (see "Maintainers Don't Scale" ) https://kernel-
> recipes.org/en/2016/talks/maintainers-dont-scale/
> 
> And comments on lwn:
> https://lwn.net/Articles/703005/

Hi Stephen,

That is an interesting case study. Perhaps it is something we could trial in 
17.05 on one or more of the sub-trees.

John

[dpdk-dev] [PATCH v2] eventdev: clarify nb_links and nb_unlinks description

[Gage Eads]

This commit clarifies the usage of nb_links and nb_unlinks when passing
a NULL pointer as the queues argument.

Signed-off-by: Gage Eads 
---
Changes for v2:
  - Clarify nb_links as well

 lib/librte_eventdev/rte_eventdev.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eventdev/rte_eventdev.h 
b/lib/librte_eventdev/rte_eventdev.h
index c2f9310..eaf9dc6 100644
--- a/lib/librte_eventdev/rte_eventdev.h
+++ b/lib/librte_eventdev/rte_eventdev.h
@@ -1291,7 +1291,8 @@ rte_event_dequeue_burst(uint8_t dev_id, uint8_t port_id, 
struct rte_event ev[],
  *   with RTE_EVENT_DEV_PRIORITY_NORMAL servicing priority
  *
  * @param nb_links
- *   The number of links to establish
+ *   The number of links to establish. This parameter is ignored if queues is
+ *   NULL.
  *
  * @return
  * The number of links actually established. The return value can be less than
@@ -1336,7 +1337,8 @@ rte_event_port_link(uint8_t dev_id, uint8_t port_id,
  *   event queue(s) from the event port *port_id*.
  *
  * @param nb_unlinks
- *   The number of unlinks to establish
+ *   The number of unlinks to establish. This parameter is ignored if queues is
+ *   NULL.
  *
  * @return
  * The number of unlinks actually established. The return value can be less
-- 
2.7.4

Re: [dpdk-dev] [PATCH] igb_uio: map dummy dma forcing iommu domain attachment

[Ferruh Yigit]

On 2/13/2017 1:38 PM, Alejandro Lucero wrote:
> 
> 
> On Fri, Feb 10, 2017 at 7:06 PM, Ferruh Yigit  > wrote:
> 
> On 2/10/2017 7:03 PM, Ferruh Yigit wrote:
> > On 2/8/2017 11:54 AM, Alejandro Lucero wrote:
> >> Hi Ferruh,
> >>
> >> On Tue, Feb 7, 2017 at 3:59 PM, Ferruh Yigit  
> >> >> wrote:
> >>
> >> Hi Alejandro,
> >>
> >> On 1/18/2017 12:27 PM, Alejandro Lucero wrote:
> >> > For using a DPDK app when iommu is enabled, it requires to
> >> > add iommu=pt to the kernel command line. But using igb_uio driver
> >> > makes DMAR errors because the device has not an IOMMU domain.
> >>
> >> Please help to understand the scope of the problem,
> >>
> >>
> >> After reading your reply, I realize I could have explained it better.
> >> First of all, this is related to SRIOV, exactly when the VFs are 
> created.
> >>
> >>
> >> 1- How can you re-produce the problem?
> >>
> >>
> >> Using a VF from a Intel card by a DPDK app in the host and a kernel >=
> >> 3.15. Although usually VFs are assigned to VMs, it could also be an
> >> option to use VFs by the host.
> >>
> >> BTW, I did not try to reproduce the problem with an Intel card. I
> >> triggered this problem with an NFP, but because the problem behind, I
> >> bet that is going to happen for an Intel one as well.
> >
> > I can able to reproduce the problem with ixgbe, by using VF on the host.
> >
> > And I verified your patch fixes it, it cause device attached to a vfio
> > group.
> 
> I want to send this in a separate mail, since not directly related to
> your patch, but while I was testing with vfio-pci I get lower numbers
> comparing to the igb_uio, which is unexpected AFAIK.
> 
> Most probably I am doing something wrong, but I would like to ask if are
> you observing same behavior?
> 
> 
> Can you tell me which test are you running?
> 
> Although both, igb_uio and vfio, allow to work with IOMMU, the first one
> requires iommu=pt. It implies a single IOMMU domain already created by
> the system with the 1:1 mapping being used.  With VFIO, a specific per
> device IOMMU domain is created. Depending on how are you measuring
> performance, that specific IOMMU domain creation by the DPDK app could
> have an impact, but I do not think that should be really significant.
> But with IOMMU you have the same problem than with MMU, there is a IOTLB
> for IOMMU as there is a TLB for MMU. Depending on the app, some
> IOMMU/IOTLB contention is likely. I have done some experiments and still
> investigating this during my spare time. It would be worth a talk about
> this in the next DPDK meeting.

After spending a few hours on it, still not sure about source of the
problem, and assume it is specific to my platform, otherwise we would
hear before.

The performance drop is huge to suspect from IOTLB.

With igb_uio, I am getting 10G line rate for 64bytes, ~14Mpps. When
switch to vfio-pci, it is ~1,5Mppps.

I am testing with "iommu=pt intel_iommu=on" kernel params.

Tried with kernel versions:
* 4.9.8
* 4.4.14
* 4.0.4

Tested with dpdk version:
* 17.02-rc3
* 16.11

Tested vfio-pci with kernel option "iommu=on intel_iommu=on" with 4.0.4
kernel.

All above gives low performance with vfio_pci, which does not make sense
to me, most probably doing a stupid mistake ...

Thanks,
ferruh

>  
> 
> 
> Thanks,
> ferruh
> 
> 

Re: [dpdk-dev] [dpdk-techboard] decision process and DPDK scope

[Wiles, Keith]

> On Feb 13, 2017, at 9:21 AM, Mcnamara, John  wrote:
> 
> 
> 
>> -Original Message-
>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen Hemminger
>> Sent: Thursday, February 9, 2017 10:49 PM
>> To: Richardson, Bruce 
>> Cc: Thomas Monjalon ; dev@dpdk.org;
>> techbo...@dpdk.org
>> Subject: Re: [dpdk-dev] [dpdk-techboard] decision process and DPDK scope
>> 
>> On Thu, 9 Feb 2017 12:20:47 +
>> Bruce Richardson  wrote:
>> 
 I think we can use this case to avoid seeing it again in the future.
 I suggest that the technical board should check whether every new
 proposed features are explained, discussed and approved enough in the
>> community.
 If needed, the technical board meeting minutes will give some lights
 to the threads which require more attention.
 Before adding a new library or adding a major API, there should be
 some strong reviews which include discussing the DPDK scope.
 
>>> 
>>> The bigger question here is the default position of the DPDK community
>>> - default accept, or default reject. Your statements above all are
>>> very much keeping in the style of default reject i.e. every patch or
>>> change suggested is assumed to be unfit for acceptance unless reviewed
>>> in detail to prove beyond doubt otherwise.
>>> 
>>> I believe that we should change this default position, as I think that
>>> reject by default is hurting the community and will continue to do so.
>>> 
>>> NOTE: I am not suggesting that we allow all code in with zero review,
>>> but I am suggesting that if something has been reviewed and acked by
>>> at least one reviewer it should be autom
>> 
>> I agree but in a more assertive manner. The maintainer should be the
>> default and active reviewer of all submissions. Like other projects the
>> maintainers job is to review and accept (or provide constructive
>> feedback). Otherwise the job could just by done by some manager.
>> 
>> But recently, I have changed my mind. The current DPDK project model is
>> not scaling well. After hearing some of the arguments in favor of a
>> multiple committer model (see "Maintainers Don't Scale" ) https://kernel-
>> recipes.org/en/2016/talks/maintainers-dont-scale/
>> 
>> And comments on lwn:
>> https://lwn.net/Articles/703005/
> 
> Hi Stephen,
> 
> That is an interesting case study. Perhaps it is something we could trial in 
> 17.05 on one or more of the sub-trees.

+1 What sub-trees would be the best place to start and then who would be best 
suited to the role?

I was thinking net-next would be a good place to start.

> 
> John
> 
> 

Regards,
Keith

[dpdk-dev] doc: deprecation notice for ethdev ops?

[Dumitrescu, Cristian]

Hi Thomas,

When a new member (function pointer) is added to struct eth_dev_ops (as the 
last member), does it need to go through ABI chance process (e.g. chance notice 
one release before)?

IMO the answer is no: struct eth_dev_ops is marked as internal and its 
instances are only accessed through pointers, so the rte_eth_devices array 
should not be impacted by the ops structure expanding at its end. Unless there 
is something that I am missing?

My question is in the context of this patch under review for 17.5 release: 
http://www.dpdk.org/ml/archives/dev/2017-February/057367.html.

Thanks,
Cristian

Re: [dpdk-dev] [PATCH] doc: annouce ABI change for cryptodev ops structure

[Zhang, Roy Fan]

Hi Fiona,

Sorry for my bad English, I will try to explain better here.

"cryptodev_configure_t" is a function prototype with only "rte_cryptodev *dev"
as sole parameter. Structure ``rte_cryptodev_ops`` holds one function pointer
"dev_configure" of it. 

The patch involves in the announcement of adding a parameter of 
"struct rte_cryptodev_config" pointer so the function prototype could look like:

typedef int (*cryptodev_configure_t)(struct rte_cryptodev *dev, struct 
rte_cryptodev_config *config);

Without this parameter, a specific crypto PMD may not have enough information to
configure itself. Which may not be big problem as other Cryptodevs as all 
configures
are done in rte_cryptodev_configure(), but it is important for the scheduler 
PMD as it
needs this parameter to configure all its slaves. Currently the user have to 
configure
every slave one by one.

The problem is, although I want to change an API of the function prototype 
"cryptodev_configure_t",
but in order to do that I have to break the ABI of structure 
"rte_cryptodev_ops". Any help on the grammar
for stating this nicer would be appreciated.

Best regards,
Fan




> -Original Message-
> From: Trahe, Fiona
> Sent: Friday, February 10, 2017 2:00 PM
> To: Zhang, Roy Fan ; dev@dpdk.org
> Cc: De Lara Guarch, Pablo ; Trahe, Fiona
> 
> Subject: RE: [dpdk-dev] [PATCH] doc: annouce ABI change for cryptodev ops
> structure
> 
> Hi Fan,
> 
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Fan Zhang
> > Sent: Friday, February 10, 2017 11:39 AM
> > To: dev@dpdk.org
> > Cc: De Lara Guarch, Pablo 
> > Subject: [dpdk-dev] [PATCH] doc: annouce ABI change for cryptodev ops
> > structure
> >
> > Signed-off-by: Fan Zhang 
> > ---
> >  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 755dc65..564d93a 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -62,3 +62,7 @@ Deprecation Notices
> >PMDs that implement the latter.
> >Target release for removal of the legacy API will be defined once most
> >PMDs have switched to rte_flow.
> > +
> > +* ABI changes are planned for 17.05 in the ``rte_cryptodev_ops`` structure.
> > +  The field ``cryptodev_configure_t`` function prototype will be
> > +added a
> > +  parameter of a struct rte_cryptodev_config type pointer.
> > --
> > 2.7.4
> 
> Can you fix the grammar here please. I'm not sure what the change is?

Re: [dpdk-dev] doc: deprecation notice for ethdev ops?

[Thomas Monjalon]

2017-02-13 16:02, Dumitrescu, Cristian:
> Hi Thomas,
> 
> When a new member (function pointer) is added to struct eth_dev_ops (as the 
> last member), does it need to go through ABI chance process (e.g. chance 
> notice one release before)?
> 
> IMO the answer is no: struct eth_dev_ops is marked as internal and its 
> instances are only accessed through pointers, so the rte_eth_devices array 
> should not be impacted by the ops structure expanding at its end. Unless 
> there is something that I am missing?

You are right, it is an internal struct.
So no need of a deprecation notice.

We must clearly separate API and internal code in ethdev.

> My question is in the context of this patch under review for 17.5 release: 
> http://www.dpdk.org/ml/archives/dev/2017-February/057367.html.

I did not look at it yet. Will do after the release.

Re: [dpdk-dev] [PATCH] eventdev: Add rte_errno return values to the enqueue and dequeue functions

[Eads, Gage]

>  -Original Message-
>  From: Richardson, Bruce
>  Sent: Monday, February 13, 2017 6:08 AM
>  To: Jerin Jacob 
>  Cc: Eads, Gage ; dev@dpdk.org;
>  hemant.agra...@nxp.com; Van Haaren, Harry ;
>  nipun.gu...@nxp.com
>  Subject: Re: [PATCH] eventdev: Add rte_errno return values to the enqueue and
>  dequeue functions
>  
>  On Mon, Feb 13, 2017 at 05:18:11PM +0530, Jerin Jacob wrote:
>  > On Mon, Feb 13, 2017 at 10:38:55AM +, Bruce Richardson wrote:
>  > > On Fri, Feb 10, 2017 at 03:02:21PM -0600, Gage Eads wrote:
>  > > > This change allows user software to differentiate between an
>  > > > invalid argument (such as an invalid queue_id or sched_type in an
>  > > > enqueued event) and backpressure from the event device.
>  > > >
>  > > > The port and device ID checks are placed in
>  > > > RTE_LIBRTE_EVENTDEV_DEBUG header guards to avoid the performance
>  hit in non-debug execution.
>  > > >
>  > > > Signed-off-by: Gage Eads 
>  > > > ---
>  > >
>  > > Do we have some idea of the performance hit from these? It may be
>  > > too soon to know, given we don't have many drivers to test with, but
>  > > if there is no perf hit seen with the SW driver, I think we should
>  > > look to just always do this, rather than having it compile-time off.
>  > > If it does
>  >
>  > IMO, It is better put to under compile-time like ethdev. It is
>  > difficult predict the performance regression on wide range of cores
>  > that DPDK runs now. I think we need to add following additional checks
>  > based on Gage header file change
>  >
>  > 1) Per event queue ID is valid or not?
>  > 2) Per event's sched type doesn't match the capabilities of the destination
>  queue.
>  >
>  
>  Ok, if we are expanding the number of checks then I definitely think it 
> needs to
>  be compile-time selected.

My thinking is that, unlike checking the dev ID or port ID, per-event checks 
should be in the PMD itself since (presumably) it will loop over the events 
anyway. I also think it makes sense for the per-event error checking not to be 
compile-time selectable because a PMD needs to handle the invalid queue ID or 
sched_type case anyway.

>  
>  /Bruce
>  >
>  > > prove to be a performance problem we can look to #ifdef it out later.
>  > >
>  > > /Bruce

[dpdk-dev] [PATCH v2] doc: announce API changes to implement the bus model

[Thomas Monjalon]

The new bus model has been proposed in 17.02 without being used.
The big rework should happen in 17.05.

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

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index f0b5329..8b66407 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -13,10 +13,14 @@ Deprecation Notices
   has exposed, like the way we have done with uio-pci-generic. This change
   targets release 17.05.
 
-* ``eth_driver`` is planned to be removed in 17.02. This currently serves as
+* The PCI and VDEV subsystems will be converted as drivers of the new bus 
model.
+  It will imply some EAL API changes in 17.05.
+
+* ``eth_driver`` is planned to be removed in 17.05. This currently serves as
   a placeholder for PMDs to register themselves. Changes for ``rte_bus`` will
   provide a way to handle device initialization currently being done in
-  ``eth_driver``.
+  ``eth_driver``. Similarly, ``rte_pci_driver`` is planned to be removed from
+  ``rte_cryptodev_driver`` in 17.05.
 
 * ethdev: an API change is planned for 17.02 for the function
   ``_rte_eth_dev_callback_process``. In 17.02 the function will return an 
``int``
-- 
2.7.0

Re: [dpdk-dev] [PATCH v1] doc: add distributor library API change notice

[Thomas Monjalon]

2017-02-09 18:49, Thomas Monjalon:
> 2017-02-09 17:02, Hunt, David:
> > On 9/2/2017 2:20 PM, Ferruh Yigit wrote:
> > > On 2/6/2017 8:08 AM, David Hunt wrote:
> > >> +* lib: distributor library API will be changed to incorporate a burst-
> > >> +  oriented API. This will include a change to ``rte_distributor_create``
> > >> +  to specify which type of instance to create (single or burst), and
> > >> +  additional calls for ``rte_poll_pkt_burst`` and 
> > >> ``rte_return_pkt_burst``,
> > >> +  among others.
> > > Should new APIs (rte_poll_pkt_burst & rte_return_pkt_burst) have
> > > "rte_distributor_" name space? Apart from this:
> > >
> > > Acked-by: Ferruh Yigit 
> > 
> > Ferruh,
> >  Thanks for the third Ack.
> > 
> > Thomas,
> > Would you prefer me to re-spin the patch after inserting 
> > "_distributor" into
> > the two function names, or would you be so good as to do it during the 
> > merge?
> 
> I can do it Dave :)

Applied

Re: [dpdk-dev] doc: deprecation notice for ethdev ops?

[Ferruh Yigit]

On 2/13/2017 4:09 PM, Thomas Monjalon wrote:
> 2017-02-13 16:02, Dumitrescu, Cristian:
>> Hi Thomas,
>>
>> When a new member (function pointer) is added to struct eth_dev_ops (as the 
>> last member), does it need to go through ABI chance process (e.g. chance 
>> notice one release before)?
>>
>> IMO the answer is no: struct eth_dev_ops is marked as internal and its 
>> instances are only accessed through pointers, so the rte_eth_devices array 
>> should not be impacted by the ops structure expanding at its end. Unless 
>> there is something that I am missing?
> 
> You are right, it is an internal struct.
> So no need of a deprecation notice.

When dpdk compiled as dynamic library, application will load PMDs
dynamically as plugin.
Is this use case cause ABI compatibility issue?

I think drivers <--> libraries interface can cause ABI breakages for
dynamic library case, although not sure how common use case this is.


> 
> We must clearly separate API and internal code in ethdev.
> 
>> My question is in the context of this patch under review for 17.5 release: 
>> http://www.dpdk.org/ml/archives/dev/2017-February/057367.html.
> 
> I did not look at it yet. Will do after the release.
> 
> 

Re: [dpdk-dev] [PATCH] doc: postpone API change in ethdev

[Ferruh Yigit]

On 2/13/2017 2:26 PM, Thomas Monjalon wrote:
> The change of _rte_eth_dev_callback_process has not been done in 17.02.
> Let's postpone to 17.05.
> 
> Signed-off-by: Thomas Monjalon 

Acked-by: Ferruh Yigit 

Re: [dpdk-dev] doc: deprecation notice for ethdev ops?

[Dumitrescu, Cristian]

> -Original Message-
> From: Yigit, Ferruh
> Sent: Monday, February 13, 2017 4:46 PM
> To: Thomas Monjalon ; Dumitrescu, Cristian
> 
> Cc: dev@dpdk.org; Richardson, Bruce ; Wiles,
> Keith 
> Subject: Re: [dpdk-dev] doc: deprecation notice for ethdev ops?
> 
> On 2/13/2017 4:09 PM, Thomas Monjalon wrote:
> > 2017-02-13 16:02, Dumitrescu, Cristian:
> >> Hi Thomas,
> >>
> >> When a new member (function pointer) is added to struct eth_dev_ops
> (as the last member), does it need to go through ABI chance process (e.g.
> chance notice one release before)?
> >>
> >> IMO the answer is no: struct eth_dev_ops is marked as internal and its
> instances are only accessed through pointers, so the rte_eth_devices array
> should not be impacted by the ops structure expanding at its end. Unless
> there is something that I am missing?
> >
> > You are right, it is an internal struct.
> > So no need of a deprecation notice.
> 
> When dpdk compiled as dynamic library, application will load PMDs
> dynamically as plugin.
> Is this use case cause ABI compatibility issue?
> 
> I think drivers <--> libraries interface can cause ABI breakages for
> dynamic library case, although not sure how common use case this is.
> 

Do you have a specific example that might cause an issue when adding a new 
function at the end of the ethdev ops structure? I cannot think of any, given 
that the ops structure is marked as internal and it is only accessed through 
pointers.

> 
> >
> > We must clearly separate API and internal code in ethdev.
> >
> >> My question is in the context of this patch under review for 17.5 release:
> http://www.dpdk.org/ml/archives/dev/2017-February/057367.html.
> >
> > I did not look at it yet. Will do after the release.
> >
> >

Re: [dpdk-dev] [PATCH] doc: annouce ABI change for cryptodev ops structure

[Trahe, Fiona]

Thanks Fan, now it makes sense.

> -Original Message-
> From: Zhang, Roy Fan
> Sent: Monday, February 13, 2017 4:07 PM
> To: Trahe, Fiona ; dev@dpdk.org
> Cc: De Lara Guarch, Pablo 
> Subject: RE: [dpdk-dev] [PATCH] doc: annouce ABI change for cryptodev ops
> structure
> 
> Hi Fiona,
> 
> Sorry for my bad English, I will try to explain better here.
> 
> "cryptodev_configure_t" is a function prototype with only "rte_cryptodev
> *dev"
> as sole parameter. Structure ``rte_cryptodev_ops`` holds one function pointer
> "dev_configure" of it.
> 
> The patch involves in the announcement of adding a parameter of
> "struct rte_cryptodev_config" pointer so the function prototype could look
> like:
> 
> typedef int (*cryptodev_configure_t)(struct rte_cryptodev *dev, struct
> rte_cryptodev_config *config);
> 
> Without this parameter, a specific crypto PMD may not have enough
> information to
> configure itself. Which may not be big problem as other Cryptodevs as all
> configures
> are done in rte_cryptodev_configure(), but it is important for the scheduler
> PMD as it
> needs this parameter to configure all its slaves. Currently the user have to
> configure
> every slave one by one.
> 
> The problem is, although I want to change an API of the function prototype
> "cryptodev_configure_t",
> but in order to do that I have to break the ABI of structure
> "rte_cryptodev_ops". Any help on the grammar
> for stating this nicer would be appreciated.
> 
> Best regards,
> Fan
> 
> 
> 
> 
> > -Original Message-
> > From: Trahe, Fiona
> > Sent: Friday, February 10, 2017 2:00 PM
> > To: Zhang, Roy Fan ; dev@dpdk.org
> > Cc: De Lara Guarch, Pablo ; Trahe, Fiona
> > 
> > Subject: RE: [dpdk-dev] [PATCH] doc: annouce ABI change for cryptodev ops
> > structure
> >
> > Hi Fan,
> >
> > > -Original Message-
> > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Fan Zhang
> > > Sent: Friday, February 10, 2017 11:39 AM
> > > To: dev@dpdk.org
> > > Cc: De Lara Guarch, Pablo 
> > > Subject: [dpdk-dev] [PATCH] doc: annouce ABI change for cryptodev ops
> > > structure
> > >
> > > Signed-off-by: Fan Zhang 
> > > ---
> > >  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 755dc65..564d93a 100644
> > > --- a/doc/guides/rel_notes/deprecation.rst
> > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > @@ -62,3 +62,7 @@ Deprecation Notices
> > >PMDs that implement the latter.
> > >Target release for removal of the legacy API will be defined once most
> > >PMDs have switched to rte_flow.
> > > +
> > > +* ABI changes are planned for 17.05 in the ``rte_cryptodev_ops``
> structure.
> > > +  The field ``cryptodev_configure_t`` function prototype will be
> > > +added a
> > > +  parameter of a struct rte_cryptodev_config type pointer.
> > > --
> > > 2.7.4
> >
> > Can you fix the grammar here please. I'm not sure what the change is?

Re: [dpdk-dev] doc: deprecation notice for ethdev ops?

[Ferruh Yigit]

On 2/13/2017 5:21 PM, Dumitrescu, Cristian wrote:
> 
> 
>> -Original Message-
>> From: Yigit, Ferruh
>> Sent: Monday, February 13, 2017 4:46 PM
>> To: Thomas Monjalon ; Dumitrescu, Cristian
>> 
>> Cc: dev@dpdk.org; Richardson, Bruce ; Wiles,
>> Keith 
>> Subject: Re: [dpdk-dev] doc: deprecation notice for ethdev ops?
>>
>> On 2/13/2017 4:09 PM, Thomas Monjalon wrote:
>>> 2017-02-13 16:02, Dumitrescu, Cristian:
 Hi Thomas,

 When a new member (function pointer) is added to struct eth_dev_ops
>> (as the last member), does it need to go through ABI chance process (e.g.
>> chance notice one release before)?

 IMO the answer is no: struct eth_dev_ops is marked as internal and its
>> instances are only accessed through pointers, so the rte_eth_devices array
>> should not be impacted by the ops structure expanding at its end. Unless
>> there is something that I am missing?
>>>
>>> You are right, it is an internal struct.
>>> So no need of a deprecation notice.
>>
>> When dpdk compiled as dynamic library, application will load PMDs
>> dynamically as plugin.
>> Is this use case cause ABI compatibility issue?
>>
>> I think drivers <--> libraries interface can cause ABI breakages for
>> dynamic library case, although not sure how common use case this is.
>>
> 
> Do you have a specific example that might cause an issue when adding a new 
> function at the end of the ethdev ops structure? I cannot think of any, given 
> that the ops structure is marked as internal and it is only accessed through 
> pointers.

Adding at the end of the struct is probably safe.

> 
>>
>>>
>>> We must clearly separate API and internal code in ethdev.
>>>
 My question is in the context of this patch under review for 17.5 release:
>> http://www.dpdk.org/ml/archives/dev/2017-February/057367.html.
>>>
>>> I did not look at it yet. Will do after the release.
>>>
>>>
> 

Re: [dpdk-dev] doc: deprecation notice for ethdev ops?

[Thomas Monjalon]

2017-02-13 16:46, Ferruh Yigit:
> On 2/13/2017 4:09 PM, Thomas Monjalon wrote:
> > 2017-02-13 16:02, Dumitrescu, Cristian:
> >> Hi Thomas,
> >>
> >> When a new member (function pointer) is added to struct eth_dev_ops (as 
> >> the last member), does it need to go through ABI chance process (e.g. 
> >> chance notice one release before)?
> >>
> >> IMO the answer is no: struct eth_dev_ops is marked as internal and its 
> >> instances are only accessed through pointers, so the rte_eth_devices array 
> >> should not be impacted by the ops structure expanding at its end. Unless 
> >> there is something that I am missing?
> > 
> > You are right, it is an internal struct.
> > So no need of a deprecation notice.
> 
> When dpdk compiled as dynamic library, application will load PMDs
> dynamically as plugin.
> Is this use case cause ABI compatibility issue?
> 
> I think drivers <--> libraries interface can cause ABI breakages for
> dynamic library case, although not sure how common use case this is.

Yes it is a problem for drivers/library interface.
It is not an ABI, which is an application/library interface.

[dpdk-dev] [PATCH] doc: add ABI change notification for ring library

[Bruce Richardson]

Document proposed changes for the rings code in the next release.

Signed-off-by: Bruce Richardson 
---
 doc/guides/rel_notes/deprecation.rst | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index b49e0a0..e715fc7 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -8,6 +8,25 @@ API and ABI deprecation notices are to be posted here.
 Deprecation Notices
 ---
 
+* ring: Changes are planned to rte_ring APIs in release 17.05. Proposed
+  changes include:
+- Removing build time options for the ring:
+  CONFIG_RTE_RING_SPLIT_PROD_CONS
+  CONFIG_RTE_RING_PAUSE_REP_COUNT
+- Adding an additional parameter to enqueue functions to return the
+  amount of free space in the ring
+- Adding an additional parameter to dequeue functions to return the
+  number of remaining elements in the ring
+- Removing direct support for watermarks in the rings, since the
+  additional return value from the enqueue function makes it
+  unneeded
+- Adjusting the return values of the bulk() enq/deq functions to
+  make them consistent with the burst() equivalents. [Note, parameter
+  to these functions are changing too, per points above, so compiler
+  will flag them as needing update in legacy code]
+- Updates to some library functions e.g. rte_ring_get_memsize() to
+  allow for variably-sized ring elements.
+
 * igb_uio: iomem mapping and sysfs files created for iomem and ioport in
   igb_uio will be removed, because we are able to detect these from what Linux
   has exposed, like the way we have done with uio-pci-generic. This change
-- 
2.9.3

Re: [dpdk-dev] doc: deprecation notice for ethdev ops?

[Thomas Monjalon]

2017-02-13 17:36, Ferruh Yigit:
> On 2/13/2017 5:21 PM, Dumitrescu, Cristian wrote:
> > Do you have a specific example that might cause an issue when adding a new 
> > function at the end of the ethdev ops structure? I cannot think of any, 
> > given that the ops structure is marked as internal and it is only accessed 
> > through pointers.
> 
> Adding at the end of the struct is probably safe.

There is no guarantee in DPDK for drivers interface compatibility.
You can add your op anywhere relevant in the structure.

Re: [dpdk-dev] [PATCH 0/3] doc: update release notes

[Thomas Monjalon]

2017-02-09 09:31, Nelio Laranjeiro:
> Biggest change is in the first patch to provide a better visibility for users
> on which NIC has been tested on which platform.
> 
> Others two are just updates for Mellanox PMDs.
> 
> Nelio Laranjeiro (3):
>   doc: merge release notes sections
>   doc: update release notes for mlx4
>   doc: update release notes for mlx5

John, what do you think of this presentation?

If we cannot get an agreement shortly, I suggest to drop this part of
the release notes.

Re: [dpdk-dev] [PATCH v2] doc: announce API and ABI change for ethdev

[Thomas Monjalon]

2017-01-05 15:25, Bernard Iremonger:
> In 17.05 nine rte_eth_dev_* functions will be removed from
> librte_ether, renamed and moved to the ixgbe PMD.
> 
> Signed-off-by: Bernard Iremonger 

"ixgbe bypass" should be in the title and the description.
I'll reword to:

doc: announce move of ethdev bypass function to ixgbe API

In 17.05, nine rte_eth_dev_* functions for bypass control,
and implemented only in ixgbe, will be removed from ethdev,
renamed and moved to the ixgbe PMD-specific API.

Acked-by: Thomas Monjalon 

Re: [dpdk-dev] [PATCH] doc: announce API/ABI changes for vhost

[Thomas Monjalon]

2017-01-23 21:04, Yuanhan Liu:
> I made a vhost ABI/API refactoring at v16.04, meant to avoid such issue
> forever. Well, apparently, I lied.
> 
> People are looking for more vhost-user options now days, other than
> vhost-user net only. For example, SPDK (Storage Performance Development
> Kit) are looking for chance of vhost-user SCSI and vhost-user block.
> 
> Apparently, they also need a vhost-user backend, while DPDK already
> has a (mature enough) backend, they don't want to implement it again
> from scratch. They want to leverage the one DPDK provides.
> 
> However, the last refactoring hasn't done that right, at least it's
> not friendly for extending vhost-user to add more devices support.
> For example, different virtio devices has its own feature set, while
> APIs like rte_vhost_feature_disable(feature_mask) have no option to
> tell the device type. Thus, a more proper API should look like:
> 
> rte_vhost_feature_disable(device_type, feature_mask);
> 
> Besides that, few public files and structures should be renamed, to
> not let it bind to virtio-net. Specifically, they are:
> 
> - virtio_net_device_ops --> vhost_device_ops
> - rte_virtio_net.h  --> rte_vhost.h
> 
> Signed-off-by: Yuanhan Liu 

Acked-by: Thomas Monjalon 

Re: [dpdk-dev] [PATCH] doc: add tested platforms and nics and OSes

[Thomas Monjalon]

2017-02-09 09:42, Nélio Laranjeiro:
> Hi Yulong, John,
> 
> I would like to propose a modification on those section to improve
> readability and avoid confusion users can meet while reading it.
> They always think that all the combination written here have been
> tested, main idea is to avoid such situation.
> 
> You can find the proposition on series [1] and specially the patch [2].
> 
> Regards,
> 
> [1] http://dpdk.org/ml/archives/dev/2017-February/057154.html
> [2] http://dpdk.org/dev/patchwork/patch/20290/


I agree it is confusing.
It is different to test a Niantic on an Intel CPU with/without AVX512
or on an IBM POWER.

Re: [dpdk-dev] [PATCH 0/3] doc: update release notes

[Mcnamara, John]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
> Sent: Monday, February 13, 2017 5:49 PM
> To: Mcnamara, John 
> Cc: Nelio Laranjeiro ; dev@dpdk.org; Adrien
> Mazarguil ; Olga Shern 
> Subject: Re: [PATCH 0/3] doc: update release notes
> 
> 2017-02-09 09:31, Nelio Laranjeiro:
> > Biggest change is in the first patch to provide a better visibility
> > for users on which NIC has been tested on which platform.
> >
> > Others two are just updates for Mellanox PMDs.
> >
> > Nelio Laranjeiro (3):
> >   doc: merge release notes sections
> >   doc: update release notes for mlx4
> >   doc: update release notes for mlx5
> 
> John, what do you think of this presentation?
> 
> If we cannot get an agreement shortly, I suggest to drop this part of the
> release notes.


I think this is a better approach. I'm just concerned about whether we have 
time to make the change to the Intel data. I'll work with Yulong to see if we 
can revise 20162 in this format.

John

Re: [dpdk-dev] GSO/GRO support

[Kiran KN]

Hi All,

Glad to know that there is interest in this.

Currently the code as part of vrouter. But easily separable since its in 
separate files.

You can find the code for GRO here:
https://github.com/Juniper/contrail-vrouter/blob/master/dpdk/vr_dpdk_gro.c

GSO code is here:
https://github.com/Juniper/contrail-vrouter/blob/master/dpdk/vr_dpdk_gso.c

Will work on the RFC.

- Kiran



On 2/13/17, 5:58 AM, "Hu, Jiayu"  wrote:

>
>> -Original Message-
>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Kiran KN
>> Sent: Saturday, February 11, 2017 6:56 AM
>> To: dev@dpdk.org
>> Subject: [dpdk-dev] GSO/GRO support
>> 
>> We, at Juniper Opencontrail have added software support for TCP send
>> offload and receive offload to DPDK.
>> 
>> If the community is interested, we can publish/upstream it.
>> 
>> Pl let us know what you think of it.
>> 
>> Thanks,
>>  Kiran
>
>Hi Kiran,
>
>I am glad to hear this news. And Currently, I work on the design of GRO and 
>GSO too.
>After your codes or RFC is released, I am happy to join the discussion and do 
>some
>reviews.
>
>Regards,
>Jiayu 

Re: [dpdk-dev] [PATCH] cfgfile: fix uninitialized variable on load error

[Thomas Monjalon]

Ping Cristian

2017-02-07 05:51, Dmitriy Yakovlev:
> Uninitialized scalar variable. Using uninitialized value 
> cfg->sections[curr_section]->num_entries when calling rte_cfgfile_close.
> And memory in variables cfg->sections[curr_section], 
> sect->entries[curr_entry] maybe not equal NULL. We must decrement counters 
> curr_section, curr_entry when failed to realloc.
> 
> Fixes: eaafbad419bf ("cfgfile: library to interpret config files")
> 
> Signed-off-by: Dmitriy Yakovlev 

Re: [dpdk-dev] [PATCH 1/1] ethdev: fix typo in UDP tunnel add/delete description

[Thomas Monjalon]

2017-02-13 10:32, Andrew Rybchenko:
> Fixes: 1cbe755fef47 ("ethdev: rename UDP tunnel port functions")
> 
> Signed-off-by: Andrew Rybchenko 

Applied, thanks

Re: [dpdk-dev] [PATCH] eal: fix max number of interrupt request

[Thomas Monjalon]

2017-02-13 01:16, Zhang, Qi Z:
> Hi Thomas:
> 
> From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
> > 2017-02-09 14:59, Qi Zhang:
> > > The max number of interrupt request is possible be changed after
> > > rte_intr_callback_register, so in get_max_intr, we need to check if
> > > nessesary to update the max_intr.
> > 
> > So you are using rte_intr_enable() to update the max_intr field in the case 
> > of
> > VFIO_MSIX.
> > What about MSI, INTX and UIO cases?
> 
> My thought is, even without my fix, VFIO_MSIX is already the only case that 
> try to modify max_intr field 
> In get_max_intr, we have:
>   if (!src->intr_handle.max_intr)
> src->intr_handle.max_intr = 1;
> else if (src->intr_handle.max_intr > RTE_MAX_RXTX_INTR_VEC_ID)
> src->intr_handle.max_intr
> = RTE_MAX_RXTX_INTR_VEC_ID + 1;
> So my patch just follow this and fix some problem.
> 
> Another option is I can use a local variable that assigned by max_intr with 
> boundary check, so get_max_intr can be totally removed and max_intr in 
> intr_source will not be modified.
> 
> To me both fix are not perfect, I think the problem is in 
> rte_intr_callback_register we just save a copy of the pci_dev->intr_handle 
> but not the address point, so we are missing some mechanism to sync them.
> But since we have tight schedule on the 17.02 release and this issue does 
> cause some example code can't work, so we need to a fix it first, we may 
> consider improve the mechanism later.
> 
> Thanks
> Qi

Applied with this title: "vfio: fix maximum number of interrupt for MSI-X"

Please check how to document this behaviour and make it consistent
with other types of interrupts.

Re: [dpdk-dev] [PATCH v2] doc: announce API changes to implement the bus model

[Jan Blunck]

On Mon, Feb 13, 2017 at 5:20 PM, Thomas Monjalon
 wrote:
> The new bus model has been proposed in 17.02 without being used.
> The big rework should happen in 17.05.
>
> Suggested-by: Shreyansh Jain 
> Signed-off-by: Thomas Monjalon 
> ---
>  doc/guides/rel_notes/deprecation.rst | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst 
> b/doc/guides/rel_notes/deprecation.rst
> index f0b5329..8b66407 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -13,10 +13,14 @@ Deprecation Notices
>has exposed, like the way we have done with uio-pci-generic. This change
>targets release 17.05.
>
> -* ``eth_driver`` is planned to be removed in 17.02. This currently serves as
> +* The PCI and VDEV subsystems will be converted as drivers of the new bus 
> model.
> +  It will imply some EAL API changes in 17.05.
> +
> +* ``eth_driver`` is planned to be removed in 17.05. This currently serves as
>a placeholder for PMDs to register themselves. Changes for ``rte_bus`` will
>provide a way to handle device initialization currently being done in
> -  ``eth_driver``.
> +  ``eth_driver``. Similarly, ``rte_pci_driver`` is planned to be removed from
> +  ``rte_cryptodev_driver`` in 17.05.
>
>  * ethdev: an API change is planned for 17.02 for the function
>``_rte_eth_dev_callback_process``. In 17.02 the function will return an 
> ``int``
> --
> 2.7.0
>

Acked-by: Jan Blunck 

Re: [dpdk-dev] [PATCH] doc: add deprecation note for rework of PCI in EAL

[Jan Blunck]

On Mon, Feb 13, 2017 at 1:00 PM, Shreyansh Jain  wrote:
> On Monday 13 February 2017 05:25 PM, Shreyansh Jain wrote:
>>
>> EAL PCI layer is planned to be restructured in 17.05 to unlink it from
>> generic structures like eth_driver, rte_cryptodev_driver, and also move
>> it into a PCI Bus.
>>
>> Signed-off-by: Shreyansh Jain 
>> ---
>>  doc/guides/rel_notes/deprecation.rst | 12 
>>  1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/doc/guides/rel_notes/deprecation.rst
>> b/doc/guides/rel_notes/deprecation.rst
>> index fbe2fcb..b12d435 100644
>> --- a/doc/guides/rel_notes/deprecation.rst
>> +++ b/doc/guides/rel_notes/deprecation.rst
>> @@ -13,10 +13,14 @@ Deprecation Notices
>>has exposed, like the way we have done with uio-pci-generic. This
>> change
>>targets release 17.05.
>>
>> -* ``eth_driver`` is planned to be removed in 17.02. This currently serves
>> as
>> -  a placeholder for PMDs to register themselves. Changes for ``rte_bus``
>> will
>> -  provide a way to handle device initialization currently being done in
>> -  ``eth_driver``.
>
>
> Just to highlight, above statement was added by me in 16.11.
> As of now I plan to work on removing rte_pci_driver from eth_driver,
> rather than removing eth_driver all together (which, probably, was
> better idea).
> If someone still wishes to work on its complete removal, we can keep
> the above. (and probably remove the below).
>

There is no benefit in keeping eth_driver and removing rte_pci_driver
from it. Technically it isn't even needed today.

>
>> +* ABI/API changes are planned for 17.05 for PCI subsystem. This is to
>> +  unlink EAL dependency on PCI and to move PCI devices to a PCI specific
>> +  bus.
>> +
>> +* ``rte_pci_driver`` is planned to be removed from ``eth_driver`` in
>> 17.05.
>> +  This is to unlink the ethernet driver from PCI dependencies.
>> +  Similarly, ``rte_pci_driver`` in planned to be removed from
>> +  ``rte_cryptodev_driver`` in 17.05.
>>
>>  * In 17.02 ABI changes are planned: the ``rte_eth_dev`` structure will be
>>extended with new function pointer ``tx_pkt_prepare`` allowing
>> verification
>>
>

Re: [dpdk-dev] [PATCH v2] doc: announce API changes to implement the bus model

[Hemant Agrawal]

On 2/13/2017 3:53 PM, Jan Blunck wrote:

On Mon, Feb 13, 2017 at 5:20 PM, Thomas Monjalon
 wrote:

The new bus model has been proposed in 17.02 without being used.
The big rework should happen in 17.05.

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

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index f0b5329..8b66407 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -13,10 +13,14 @@ Deprecation Notices
   has exposed, like the way we have done with uio-pci-generic. This change
   targets release 17.05.

-* ``eth_driver`` is planned to be removed in 17.02. This currently serves as
+* The PCI and VDEV subsystems will be converted as drivers of the new bus 
model.
+  It will imply some EAL API changes in 17.05.
+
+* ``eth_driver`` is planned to be removed in 17.05. This currently serves as
   a placeholder for PMDs to register themselves. Changes for ``rte_bus`` will
   provide a way to handle device initialization currently being done in
-  ``eth_driver``.
+  ``eth_driver``. Similarly, ``rte_pci_driver`` is planned to be removed from
+  ``rte_cryptodev_driver`` in 17.05.

 * ethdev: an API change is planned for 17.02 for the function
   ``_rte_eth_dev_callback_process``. In 17.02 the function will return an 
``int``
--
2.7.0



Acked-by: Jan Blunck 


Acked-by: Hemant Agrawal 

Re: [dpdk-dev] [PATCH] eal: fix max number of interrupt request

[Zhang, Qi Z]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
> Sent: Tuesday, February 14, 2017 5:29 AM
> To: Zhang, Qi Z 
> Cc: dev@dpdk.org; Wu, Jingjing 
> Subject: Re: [PATCH] eal: fix max number of interrupt request
> 
> 2017-02-13 01:16, Zhang, Qi Z:
> > Hi Thomas:
> >
> > From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
> > > 2017-02-09 14:59, Qi Zhang:
> > > > The max number of interrupt request is possible be changed after
> > > > rte_intr_callback_register, so in get_max_intr, we need to check
> > > > if nessesary to update the max_intr.
> > >
> > > So you are using rte_intr_enable() to update the max_intr field in
> > > the case of VFIO_MSIX.
> > > What about MSI, INTX and UIO cases?
> >
> > My thought is, even without my fix, VFIO_MSIX is already the only case
> > that try to modify max_intr field In get_max_intr, we have:
> > if (!src->intr_handle.max_intr)
> > src->intr_handle.max_intr = 1;
> > else if (src->intr_handle.max_intr >
> RTE_MAX_RXTX_INTR_VEC_ID)
> > src->intr_handle.max_intr
> > = RTE_MAX_RXTX_INTR_VEC_ID +
> 1; So my
> > patch just follow this and fix some problem.
> >
> > Another option is I can use a local variable that assigned by max_intr with
> boundary check, so get_max_intr can be totally removed and max_intr in
> intr_source will not be modified.
> >
> > To me both fix are not perfect, I think the problem is in
> rte_intr_callback_register we just save a copy of the pci_dev->intr_handle
> but not the address point, so we are missing some mechanism to sync them.
> > But since we have tight schedule on the 17.02 release and this issue does
> cause some example code can't work, so we need to a fix it first, we may
> consider improve the mechanism later.
> >
> > Thanks
> > Qi
> 
> Applied with this title: "vfio: fix maximum number of interrupt for MSI-X"
> 
> Please check how to document this behaviour and make it consistent with
> other types of interrupts.

OK, I will check.

Thanks
Qi

Re: [dpdk-dev] [PATCH] doc: annouce ABI change for cryptodev ops structure

[Hemant Agrawal]

On 2/10/2017 7:59 AM, Trahe, Fiona wrote:

Hi Fan,


-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Fan Zhang
Sent: Friday, February 10, 2017 11:39 AM
To: dev@dpdk.org
Cc: De Lara Guarch, Pablo 
Subject: [dpdk-dev] [PATCH] doc: annouce ABI change for cryptodev ops
structure

Signed-off-by: Fan Zhang 
---
 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 755dc65..564d93a 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -62,3 +62,7 @@ Deprecation Notices
   PMDs that implement the latter.
   Target release for removal of the legacy API will be defined once most
   PMDs have switched to rte_flow.
+
+* ABI changes are planned for 17.05 in the ``rte_cryptodev_ops`` structure.
+  The field ``cryptodev_configure_t`` function prototype will be added a
+  parameter of a struct rte_cryptodev_config type pointer.
--
2.7.4


Can you fix the grammar here please. I'm not sure what the change is?

I also find it hard to understand it first. Not perfect, but I tried to 
reword it.


A new parameter ``struct rte_cryptodev_config *config`` will be added to 
the ``cryptodev_configure_t`` function pointer field.

Re: [dpdk-dev] [PATCH 1/3] doc: merge release notes sections

[Mcnamara, John]

> -Original Message-
> From: Nelio Laranjeiro [mailto:nelio.laranje...@6wind.com]
> Sent: Thursday, February 9, 2017 8:32 AM
> To: dev@dpdk.org; Mcnamara, John ; Thomas
> Monjalon 
> Cc: Adrien Mazarguil ; Olga Shern
> 
> Subject: [PATCH 1/3] doc: merge release notes sections
> 
> These sections do not provide the exact tests that were done nor whether
> specific NICs are supported by all platforms.
> 
> Signed-off-by: Nelio Laranjeiro 

Acked-by: John McNamara 

Re: [dpdk-dev] [PATCH 3/3] doc: update release notes for mlx5

[Mcnamara, John]

> -Original Message-
> From: Nelio Laranjeiro [mailto:nelio.laranje...@6wind.com]
> Sent: Thursday, February 9, 2017 8:32 AM
> To: dev@dpdk.org; Mcnamara, John ; Thomas
> Monjalon 
> Cc: Adrien Mazarguil ; Olga Shern
> 
> Subject: [PATCH 3/3] doc: update release notes for mlx5
> 
> Signed-off-by: Nelio Laranjeiro 

Acked-by: John McNamara 

Re: [dpdk-dev] [PATCH 2/3] doc: update release notes for mlx4

[Mcnamara, John]

> -Original Message-
> From: Nelio Laranjeiro [mailto:nelio.laranje...@6wind.com]
> Sent: Thursday, February 9, 2017 8:32 AM
> To: dev@dpdk.org; Mcnamara, John ; Thomas
> Monjalon 
> Cc: Adrien Mazarguil ; Olga Shern
> 
> Subject: [PATCH 2/3] doc: update release notes for mlx4
> 
> Signed-off-by: Nelio Laranjeiro 

Acked-by: John McNamara 

Re: [dpdk-dev] [PATCH] doc: add tested platforms and nics and OSes

[Mcnamara, John]

> -Original Message-
> From: Pei, Yulong
> Sent: Monday, January 23, 2017 8:38 AM
> To: dev@dpdk.org
> Cc: Mcnamara, John ; thomas.monja...@6wind.com;
> Pei, Yulong 
> Subject: [PATCH] doc: add tested platforms and nics and OSes
> 
> Add tested platforms and nics and OSes to the release notes.
> 
> Signed-off-by: Yulong Pei 


Could you reformat this patch into the format suggested by Nelio Laranjeiro,
like this:

Tested Platforms


#. Intel(R) platforms with Mellanox(R) NICs.

   * Platform details.

 * Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz
 * Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
 * Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz

 * OS:

   * CentOS 7.0
   * Fedora 23
   * Fedora 24
   * FreeBSD 10.3
   * Red Hat Enterprise Linux 7.2
   * SUSE Enterprise Linux 12
   * Ubuntu 14.04 LTS
   * Ubuntu 15.10
   * Ubuntu 16.04 LTS
   * Wind River Linux 8

   * MLNX_OFED: 4.0-1.0.1.0

   * NICs:

 * Mellanox(R) ConnectX(R)-3 Pro 40G MCX354A-FCC_Ax (2x40G)

   * Host interface: PCI Express 3.0 x8
   * Device ID: 15b3:1007
   * Firmware version: 2.40.5030

Re: [dpdk-dev] [PATCH] doc: add ABI change notification for ring library

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Bruce Richardson
> Sent: Monday, February 13, 2017 5:39 PM
> To: dev@dpdk.org
> Cc: Richardson, Bruce 
> Subject: [dpdk-dev] [PATCH] doc: add ABI change notification for ring
> library
> 
> Document proposed changes for the rings code in the next release.
> 
> Signed-off-by: Bruce Richardson 

Acked-by: John McNamara 

Re: [dpdk-dev] [PATCH v2] doc: announce API changes to implement the bus model

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Monday, February 13, 2017 4:21 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v2] doc: announce API changes to implement the
> bus model
> 
> The new bus model has been proposed in 17.02 without being used.
> The big rework should happen in 17.05.
> 
> Suggested-by: Shreyansh Jain 
> Signed-off-by: Thomas Monjalon 

Acked-by: John McNamara 

Re: [dpdk-dev] [PATCH] doc/contributing: add ack review descriptions

[Mcnamara, John]

> -Original Message-
> From: Van Haaren, Harry
> Sent: Wednesday, February 8, 2017 9:50 AM
> To: dev@dpdk.org
> Cc: thomas.monja...@6wind.com; iryz...@nfware.com; jons...@cisco.com;
> Mcnamara, John ; shreyansh.j...@nxp.com;
> Richardson, Bruce ; Van Haaren, Harry
> 
> Subject: [PATCH] doc/contributing: add ack review descriptions
> 
> This commit details what is meant by the various email tags that the DPDK
> community use regularly. The descriptions state what each tag means,
> drawing from the kernel's understanding[1], and the discussion on the DPDK
> mailing list[2].
> 
>...
>
> +``Acked-by:`` is a record that the a person named was not directly

s/the a/the/

>
> +``Suggested-by:`` indicates that the patch idea is suggested by the
> +person named and ensures credit to the person for the idea.  Please
> +note that this tag should not be added without the reporter’s

The apostrophe here is non-ascii.

Other than those minor issues:

Acked-by: John McNamara 

Re: [dpdk-dev] [PATCH] doc: add EAL bus support in release notes

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Shreyansh Jain
> Sent: Monday, February 13, 2017 11:30 AM
> To: dev@dpdk.org
> Cc: thomas.monja...@6wind.com; Shreyansh Jain 
> Subject: [dpdk-dev] [PATCH] doc: add EAL bus support in release notes
> 
> Signed-off-by: Shreyansh Jain 

Acked-by: John McNamara 

Re: [dpdk-dev] [PATCH] doc: deprecation note for renaming vfio symbols for exporting

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Shreyansh Jain
> Sent: Monday, February 13, 2017 12:02 PM
> To: dev@dpdk.org
> Cc: Burakov, Anatoly ;
> thomas.monja...@6wind.com; Shreyansh Jain 
> Subject: [dpdk-dev] [PATCH] doc: deprecation note for renaming vfio
> symbols for exporting
> 
> Some vfio symbols need to be exported outside librte_eal. For that, they
> need to be renamed to rte_* naming convention.
> 
> Signed-off-by: Shreyansh Jain 

Acked-by: John McNamara 

Re: [dpdk-dev] [PATCH v2] doc: announce API and ABI change for ethdev

[Jerin Jacob]

On Mon, Feb 13, 2017 at 06:57:20PM +0100, Thomas Monjalon wrote:
> 2017-01-05 15:25, Bernard Iremonger:
> > In 17.05 nine rte_eth_dev_* functions will be removed from
> > librte_ether, renamed and moved to the ixgbe PMD.
> > 
> > Signed-off-by: Bernard Iremonger 
> 
> "ixgbe bypass" should be in the title and the description.
> I'll reword to:
> 
> doc: announce move of ethdev bypass function to ixgbe API
> 
> In 17.05, nine rte_eth_dev_* functions for bypass control,
> and implemented only in ixgbe, will be removed from ethdev,
> renamed and moved to the ixgbe PMD-specific API.
> 
> Acked-by: Thomas Monjalon 

Acked-by: Jerin Jacob 

Re: [dpdk-dev] [PATCH] doc: announce ABI change for cloud filter

[Jerin Jacob]

On Fri, Jan 20, 2017 at 03:57:28PM +0100, Thomas Monjalon wrote:
> 2017-01-20 02:14, Lu, Wenzhuo:
> > Hi Adrien, Thomas, Yong,
> > 
> > > -Original Message-
> > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Adrien Mazarguil
> > > Sent: Friday, January 20, 2017 2:46 AM
> > > To: Thomas Monjalon
> > > Cc: Liu, Yong; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for cloud filter
> > > 
> > > On Thu, Jan 19, 2017 at 10:06:34AM +0100, Thomas Monjalon wrote:
> > > > 2017-01-19 13:34, Yong Liu:
> > > > > +* ABI changes are planned for 17.05: structure
> > > > > +``rte_eth_tunnel_filter_conf``
> > > > > +  will be extended with a new member ``vf_id`` in order to enable
> > > > > +cloud filter
> > > > > +  on VF device.
> > > >
> > > > I think we should stop rely on this API, and migrate to rte_flow 
> > > > instead.
> > > > Adrien any thought?
> > > 
> > > I'm all for using rte_flow in any case. I've already documented an 
> > > approach to
> > > convert TUNNEL filter rules to rte_flow rules [1], although it may be
> > > incomplete due to my limited experience with this filter type. We already
> > > know several tunnel item types must be added (currently only VXLAN is
> > > defined).
> > > 
> > > I understand ixgbe/i40e currently map rte_flow on top of the legacy
> > > framework, therefore extending this structure might still be needed in the
> > > meantime. Not sure we should prevent this change as long as such rules 
> > > can be
> > > configured through rte_flow as well.
> > > 
> > > [1] 
> > > http://dpdk.org/doc/guides/prog_guide/rte_flow.html#tunnel-to-eth-ipv4-
> > > ipv6-vxlan-or-other-queue
> > The problem is we haven't finished transferring all the functions from the 
> > regular filters to the generic filters. 
> > For example, igb, fm10k and enic haven't support generic filters yet. Ixgbe 
> > and i40e have supported the basic functions, but some advance features are 
> > not transferred to generic filters yet.
> > Seems it's not the time to remove the regular filters. Yong, I suggest to 
> > support both generic filter and regular filter in parallel.
> > So, we need to announce ABI change for the regular filter, until someday we 
> > remove the regular filter API. 
> 
> I disagree.
> There is a new API framework (rte_flow) and we must focus on this transition.
> It means we must stop any work on the legacy API.

I agree with Thomas here.

Re: [dpdk-dev] [PATCH] doc: announce API/ABI changes for vhost

[Jerin Jacob]

On Mon, Feb 13, 2017 at 07:02:56PM +0100, Thomas Monjalon wrote:
> 2017-01-23 21:04, Yuanhan Liu:
> > I made a vhost ABI/API refactoring at v16.04, meant to avoid such issue
> > forever. Well, apparently, I lied.
> > 
> > People are looking for more vhost-user options now days, other than
> > vhost-user net only. For example, SPDK (Storage Performance Development
> > Kit) are looking for chance of vhost-user SCSI and vhost-user block.
> > 
> > Apparently, they also need a vhost-user backend, while DPDK already
> > has a (mature enough) backend, they don't want to implement it again
> > from scratch. They want to leverage the one DPDK provides.
> > 
> > However, the last refactoring hasn't done that right, at least it's
> > not friendly for extending vhost-user to add more devices support.
> > For example, different virtio devices has its own feature set, while
> > APIs like rte_vhost_feature_disable(feature_mask) have no option to
> > tell the device type. Thus, a more proper API should look like:
> > 
> > rte_vhost_feature_disable(device_type, feature_mask);
> > 
> > Besides that, few public files and structures should be renamed, to
> > not let it bind to virtio-net. Specifically, they are:
> > 
> > - virtio_net_device_ops --> vhost_device_ops
> > - rte_virtio_net.h  --> rte_vhost.h
> > 
> > Signed-off-by: Yuanhan Liu 
> 
> Acked-by: Thomas Monjalon 

Acked-by: Jerin Jacob 

Re: [dpdk-dev] [PATCH] doc: add EAL bus support in release notes

[Jerin Jacob]

On Mon, Feb 13, 2017 at 04:59:48PM +0530, Shreyansh Jain wrote:
> Signed-off-by: Shreyansh Jain 
> ---
>  doc/guides/rel_notes/release_17_02.rst | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/release_17_02.rst 
> b/doc/guides/rel_notes/release_17_02.rst
> index ec9143c..b5bf0a9 100644
> --- a/doc/guides/rel_notes/release_17_02.rst
> +++ b/doc/guides/rel_notes/release_17_02.rst
> @@ -237,6 +237,16 @@ Resolved Issues
>  EAL
>  ~~~
>  
> +* **Added support for representing buses in EAL**
> +
> +  A new structure ``rte_bus`` is introduced in EAL. This allows for devices 
> to
> +  be represented by buses they are connected to. A new bus can be added to
> +  DPDK by extending the ``rte_bus`` structure and implementing the scan and
> +  probe functions. Once a new bus is registered using provided APIs, new
> +  devices can be detected and initialized using bus scan and probe callbacks.
> +
> +  With this change, devices other than PCI or VDEV type can also be 
> represented
> +  in DPDK framework.
>  
>  Drivers
>  ~~~

Acked-by: Jerin Jacob 

Re: [dpdk-dev] [PATCH] doc: add ABI change notification for ring library

[Jerin Jacob]

On Mon, Feb 13, 2017 at 05:38:30PM +, Bruce Richardson wrote:
> Document proposed changes for the rings code in the next release.
> 
> Signed-off-by: Bruce Richardson 
> ---
>  doc/guides/rel_notes/deprecation.rst | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst 
> b/doc/guides/rel_notes/deprecation.rst
> index b49e0a0..e715fc7 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -8,6 +8,25 @@ API and ABI deprecation notices are to be posted here.
>  Deprecation Notices
>  ---
>  
> +* ring: Changes are planned to rte_ring APIs in release 17.05. Proposed
> +  changes include:
> +- Removing build time options for the ring:
> +  CONFIG_RTE_RING_SPLIT_PROD_CONS
> +  CONFIG_RTE_RING_PAUSE_REP_COUNT
> +- Adding an additional parameter to enqueue functions to return the
> +  amount of free space in the ring
> +- Adding an additional parameter to dequeue functions to return the
> +  number of remaining elements in the ring
> +- Removing direct support for watermarks in the rings, since the
> +  additional return value from the enqueue function makes it
> +  unneeded
> +- Adjusting the return values of the bulk() enq/deq functions to
> +  make them consistent with the burst() equivalents. [Note, parameter
> +  to these functions are changing too, per points above, so compiler
> +  will flag them as needing update in legacy code]
> +- Updates to some library functions e.g. rte_ring_get_memsize() to
> +  allow for variably-sized ring elements.
> +
>  * igb_uio: iomem mapping and sysfs files created for iomem and ioport in
>igb_uio will be removed, because we are able to detect these from what 
> Linux
>has exposed, like the way we have done with uio-pci-generic. This change

Acked-by: Jerin Jacob 

Re: [dpdk-dev] [PATCH] doc: deprecation note for renaming vfio symbols for exporting

[Jerin Jacob]

On Mon, Feb 13, 2017 at 05:31:48PM +0530, Shreyansh Jain wrote:
> Some vfio symbols need to be exported outside librte_eal. For that, they
> need to be renamed to rte_* naming convention.
> 
> Signed-off-by: Shreyansh Jain 
> ---
>  doc/guides/rel_notes/deprecation.rst | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst 
> b/doc/guides/rel_notes/deprecation.rst
> index b12d435..092eb2e 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -61,3 +61,9 @@ Deprecation Notices
>PMDs that implement the latter.
>Target release for removal of the legacy API will be defined once most
>PMDs have switched to rte_flow.
> +
> +* Some vfio APIs are planned to be exported outside librte_eal in 17.05.
> +  vfio APIs like ``vfio_setup_device``, ``vfio_get_group_fd`` can be used by
> +  subsystem other than EAL/PCI. For that, these need to be exported symbols.
> +  Such APIs are planned to be renamed according to ``rte_*`` naming 
> convention
> +  and exported from librte_eal.

Acked-by: Jerin Jacob 

Re: [dpdk-dev] [PATCH v2] eventdev: clarify nb_links and nb_unlinks description

[Jerin Jacob]

On Mon, Feb 13, 2017 at 09:52:53AM -0600, Gage Eads wrote:
> This commit clarifies the usage of nb_links and nb_unlinks when passing
> a NULL pointer as the queues argument.
> 
> Signed-off-by: Gage Eads 

Acked-by: Jerin Jacob 

> ---
> Changes for v2:
>   - Clarify nb_links as well
> 
>  lib/librte_eventdev/rte_eventdev.h | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/librte_eventdev/rte_eventdev.h 
> b/lib/librte_eventdev/rte_eventdev.h
> index c2f9310..eaf9dc6 100644
> --- a/lib/librte_eventdev/rte_eventdev.h
> +++ b/lib/librte_eventdev/rte_eventdev.h
> @@ -1291,7 +1291,8 @@ rte_event_dequeue_burst(uint8_t dev_id, uint8_t 
> port_id, struct rte_event ev[],
>   *   with RTE_EVENT_DEV_PRIORITY_NORMAL servicing priority
>   *
>   * @param nb_links
> - *   The number of links to establish
> + *   The number of links to establish. This parameter is ignored if queues is
> + *   NULL.
>   *
>   * @return
>   * The number of links actually established. The return value can be less 
> than
> @@ -1336,7 +1337,8 @@ rte_event_port_link(uint8_t dev_id, uint8_t port_id,
>   *   event queue(s) from the event port *port_id*.
>   *
>   * @param nb_unlinks
> - *   The number of unlinks to establish
> + *   The number of unlinks to establish. This parameter is ignored if queues 
> is
> + *   NULL.
>   *
>   * @return
>   * The number of unlinks actually established. The return value can be less
> -- 
> 2.7.4
> 

Re: [dpdk-dev] [PATCH] eventdev: Add rte_errno return values to the enqueue and dequeue functions

[Jerin Jacob]

On Fri, Feb 10, 2017 at 03:02:21PM -0600, Gage Eads wrote:
> This change allows user software to differentiate between an invalid argument
> (such as an invalid queue_id or sched_type in an enqueued event) and
> backpressure from the event device.
> 
> The port and device ID checks are placed in RTE_LIBRTE_EVENTDEV_DEBUG header
> guards to avoid the performance hit in non-debug execution.
> 
> Signed-off-by: Gage Eads 
> ---
>  static inline uint16_t
> @@ -1127,6 +1133,21 @@ rte_event_enqueue_burst(uint8_t dev_id, uint8_t 
> port_id,
>  {
>   struct rte_eventdev *dev = &rte_eventdevs[dev_id];
>  
> + rte_errno = 0;

I don't think it is required.  If at all required, move this under
RTE_LIBRTE_EVENTDEV_DEBUG to save store to rte_errno cycles on fastpath

> +#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
> + if (rte_eventdevs[dev_id].attached == RTE_EVENTDEV_DETACHED) {
> + RTE_EDEV_LOG_DEBUG("Invalid dev_id=%d\n", dev_id);
> + rte_errno = -EINVAL;
> + return 0;
> + }
> +
> + if (port_id >= dev->data->nb_ports) {
> + RTE_EDEV_LOG_DEBUG("Invalid port_id=%d\n", port_id);
> + rte_errno = -EINVAL;
> + return 0;
> + }
> +#endif
> +
>   /*
>* Allow zero cost non burst mode routine invocation if application
>* requests nb_events as const one
> @@ -1235,6 +1256,21 @@ rte_event_dequeue_burst(uint8_t dev_id, uint8_t 
> port_id, struct rte_event ev[],
>  {
>   struct rte_eventdev *dev = &rte_eventdevs[dev_id];
>  
> +#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
> + rte_errno = 0;
> + if (rte_eventdevs[dev_id].attached == RTE_EVENTDEV_DETACHED) {
> + RTE_EDEV_LOG_DEBUG("Invalid dev_id=%d\n", dev_id);
> + rte_errno = -EINVAL;
> + return 0;
> + }
> +
> + if (port_id >= dev->data->nb_ports) {
> + RTE_EDEV_LOG_DEBUG("Invalid port_id=%d\n", port_id);
> + rte_errno = -EINVAL;
> + return 0;
> + }
> +#endif
> +
>   /*
>* Allow zero cost non burst mode routine invocation if application
>* requests nb_events as const one
> -- 
> 2.7.4
> 

Re: [dpdk-dev] [PATCH] doc: annouce ABI change for cryptodev ops structure

[Hemant Agrawal]

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Hemant Agrawal
> Sent: Monday, February 13, 2017 6:21 PM
> To: Trahe, Fiona ; Zhang, Roy Fan
> ; dev@dpdk.org
> Cc: De Lara Guarch, Pablo 
> Subject: Re: [dpdk-dev] [PATCH] doc: annouce ABI change for cryptodev ops
> structure
> 
> On 2/10/2017 7:59 AM, Trahe, Fiona wrote:
> > Hi Fan,
> >
> >> -Original Message-
> >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Fan Zhang
> >> Sent: Friday, February 10, 2017 11:39 AM
> >> To: dev@dpdk.org
> >> Cc: De Lara Guarch, Pablo 
> >> Subject: [dpdk-dev] [PATCH] doc: annouce ABI change for cryptodev ops
> >> structure
> >>
> >> Signed-off-by: Fan Zhang 
> >> ---
> >>  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 755dc65..564d93a 100644
> >> --- a/doc/guides/rel_notes/deprecation.rst
> >> +++ b/doc/guides/rel_notes/deprecation.rst
> >> @@ -62,3 +62,7 @@ Deprecation Notices
> >>PMDs that implement the latter.
> >>Target release for removal of the legacy API will be defined once most
> >>PMDs have switched to rte_flow.
> >> +
> >> +* ABI changes are planned for 17.05 in the ``rte_cryptodev_ops``
> structure.
> >> +  The field ``cryptodev_configure_t`` function prototype will be
> >> +added a
> >> +  parameter of a struct rte_cryptodev_config type pointer.
> >> --
> >> 2.7.4
> >
> > Can you fix the grammar here please. I'm not sure what the change is?
> >
> I also find it hard to understand it first. Not perfect, but I tried to 
> reword it.
> 
> A new parameter ``struct rte_cryptodev_config *config`` will be added to the
> ``cryptodev_configure_t`` function pointer field.
> 

In any case,
Acked-by: Hemant Agrawal 

Re: [dpdk-dev] [PATCH] doc: add deprecation note for rework of PCI in EAL

[Shreyansh Jain]

On Tuesday 14 February 2017 03:26 AM, Jan Blunck wrote:

On Mon, Feb 13, 2017 at 1:00 PM, Shreyansh Jain  wrote:

On Monday 13 February 2017 05:25 PM, Shreyansh Jain wrote:


EAL PCI layer is planned to be restructured in 17.05 to unlink it from
generic structures like eth_driver, rte_cryptodev_driver, and also move
it into a PCI Bus.

Signed-off-by: Shreyansh Jain 
---
 doc/guides/rel_notes/deprecation.rst | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst
b/doc/guides/rel_notes/deprecation.rst
index fbe2fcb..b12d435 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -13,10 +13,14 @@ Deprecation Notices
   has exposed, like the way we have done with uio-pci-generic. This
change
   targets release 17.05.

-* ``eth_driver`` is planned to be removed in 17.02. This currently serves
as
-  a placeholder for PMDs to register themselves. Changes for ``rte_bus``
will
-  provide a way to handle device initialization currently being done in
-  ``eth_driver``.



Just to highlight, above statement was added by me in 16.11.
As of now I plan to work on removing rte_pci_driver from eth_driver,
rather than removing eth_driver all together (which, probably, was
better idea).
If someone still wishes to work on its complete removal, we can keep
the above. (and probably remove the below).



There is no benefit in keeping eth_driver and removing rte_pci_driver
from it. Technically it isn't even needed today.


I agree with you.
I stopped working on it because I realized that removing it means making
pci_probe call eth_dev_init handlers directly. Or, restructure the whole
of pci probe stack - which, because of pending PCI bus implementation,
was slightly tentative.

Changes are already expected in EAL PCI code for bus movement, probably
this task can be combined with that.






+* ABI/API changes are planned for 17.05 for PCI subsystem. This is to
+  unlink EAL dependency on PCI and to move PCI devices to a PCI specific
+  bus.
+
+* ``rte_pci_driver`` is planned to be removed from ``eth_driver`` in
17.05.
+  This is to unlink the ethernet driver from PCI dependencies.
+  Similarly, ``rte_pci_driver`` in planned to be removed from
+  ``rte_cryptodev_driver`` in 17.05.

 * In 17.02 ABI changes are planned: the ``rte_eth_dev`` structure will be
   extended with new function pointer ``tx_pkt_prepare`` allowing
verification

Re: [dpdk-dev] [PATCH 2/3] net/cxgbe: remove unused variable usage

[Yuanhan Liu]

On Thu, Jan 26, 2017 at 11:05:22AM +, Ferruh Yigit wrote:
> On 1/26/2017 4:41 AM, Rahul Lakkireddy wrote:
> > On Wednesday, January 01/25/17, 2017 at 17:43:57 +0530, Ferruh Yigit wrote:
> >> On 1/24/2017 8:48 PM, Emmanuel Roullit wrote:
> >>> Found with clang static analysis:
> >>> drivers/net/cxgbe/sge.c:900:3: warning:
> >>> Value stored to 'in_use' is never read
> >>> in_use += q->size;
> >>> ^ ~~~
> >>>
> >>> Fixes: c167acb61278 ("net/cxgbe: use I/O device memory read/write API")
> > 
> > This fixes line seems to be wrong.  Should be:
> > 
> 
> > 
> >>>
> >>> Signed-off-by: Emmanuel Roullit 
> 
> > Fixes: 4a01078b4fd1 ("cxgbe: add Tx support")
> Cc: sta...@dpdk.org

I doubt the necessary of picking it to a stable release: it doesn't fix
a real bug after all. Therefore, I will drop it for v16.11.1.

--yliu 
> 
> Acked-by: Rahul Lakkireddy 
> 
> 
> Applied to dpdk-next-net/master, thanks.
> 
> (patch 2/3 and 3/3 merged)

Re: [dpdk-dev] [dpdk-stable] [PATCH] net/bonding: remove useless assignment

[Yuanhan Liu]

On Thu, Jan 26, 2017 at 11:08:29AM +, Ferruh Yigit wrote:
> On 1/25/2017 12:11 PM, Ferruh Yigit wrote:
> > On 1/24/2017 9:15 PM, Emmanuel Roullit wrote:
> >> Found with clang static analysis:
> >> drivers/net/bonding/rte_eth_bond_pmd.c:903:3:
> >> warning: Value stored to 'num_not_send' is never read
> >> num_not_send += slave_bufs_pkts[RTE_MAX_ETHPORTS] - num_send;
> >> ^   
> >>
> >> Fixes: 73db5badb042 ("net: align ethdev and eal driver names")
> >>
> >> Signed-off-by: Emmanuel Roullit 
> > 
> > Applied to dpdk-next-net/master, thanks.
> 
> Fixes: 06fe78b98ccd ("bond: add mode 6")
> Cc: sta...@dpdk.org

For the same reason (it didn't fix a real bug), I will drop it to a
stable release.

--yliu

[dpdk-dev] [PATCH v3] eventdev: amend comments for events limit and threshold

[Nipun Gupta]

Updated the comments on 'nb_events_limit' of 'struct rte_event_dev_config'
and 'new_event_threshold' of 'struct rte_event_port_conf'.

Signed-off-by: Nipun Gupta 
---
Changes for v2:
 - Fix errors reported by check-git-log.sh

Changes for v3:
 - Updated nb_events_limit comment for closed systems
 - Fixed grammatical mistake on comment for new_event_threshold

 lib/librte_eventdev/rte_eventdev.h | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/lib/librte_eventdev/rte_eventdev.h 
b/lib/librte_eventdev/rte_eventdev.h
index c2f9310..b619160 100644
--- a/lib/librte_eventdev/rte_eventdev.h
+++ b/lib/librte_eventdev/rte_eventdev.h
@@ -404,11 +404,12 @@ struct rte_event_dev_config {
 * @see RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT
 */
int32_t nb_events_limit;
-   /**< Applies to *closed system* event dev only. This field indicates a
-* limit to ethdev-like devices to limit the number of events injected
-* into the system to not overwhelm core-to-core events.
-* This value cannot exceed the *max_num_events* which previously
-* provided in rte_event_dev_info_get()
+   /**< In a *closed system* this field is the limit on maximum number of
+* events that can be inflight in the eventdev at a given time. The
+* limit is required to ensure that the finite space in a closed system
+* is not overwhelmed. The value cannot exceed the *max_num_events*
+* as provided by rte_event_dev_info_get().
+* This value should be set to -1 for *open system*.
 */
uint8_t nb_event_queues;
/**< Number of event queues to configure on this device.
@@ -633,7 +634,8 @@ struct rte_event_port_conf {
 * can have a lower threshold so as not to overwhelm the device,
 * while ports used for worker pools can have a higher threshold.
 * This value cannot exceed the *nb_events_limit*
-* which previously supplied to rte_event_dev_configure()
+* which was previously supplied to rte_event_dev_configure().
+* This should be set to '-1' for *open system*.
 */
uint8_t dequeue_depth;
/**< Configure number of bulk dequeues for this event port.
-- 
1.9.1

[dpdk-dev] [PATCH] doc: add deprecation note to add parameter in rte_cryptodev_info.sym

[akhil.goyal]

From: Akhil Goyal 

A new parameter is planned to be added in 17.05 release in
rte_cryptodev_info.sym - max_nb_sessions_per_qp.

This will allow applications to know the maximum number of session
which can be attached to queue_pairs of device.

Signed-off-by: Akhil Goyal 
---
 doc/guides/rel_notes/deprecation.rst | 5 +
 1 file changed, 5 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 97d87fd..487f798 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -56,3 +56,8 @@ Deprecation Notices
   to specify which type of instance to create (single or burst), and
   additional calls for ``rte_distributor_poll_pkt_burst`` and
   ``rte_distributor_return_pkt_burst``, among others.
+
+* cryptodev: A new parameter ``max_nb_sessions_per_qp`` will be added to
+  ``rte_cryptodev_info.sym``. Some drivers may support limited number of
+  sessions per queue_pair. With this new parameter application will know
+  how many sessions can be mapped to each queue_pair of a device.
-- 
2.9.3