Re: [dpdk-dev] [PATCH v1 1/3] drivers: introduce vDPA class

[Maxime Coquelin]

On 1/8/20 10:28 PM, Thomas Monjalon wrote:
> 07/01/2020 18:32, Maxime Coquelin:
>> Hi Matan,
>>
>> On 12/25/19 4:19 PM, Matan Azrad wrote:
>>> The vDPA (vhost data path acceleration) drivers provide support for
>>> the vDPA operations introduced by the rte_vhost library.
>>>
>>> Any driver which provides the vDPA operations should be moved\added to
>>> the vdpa class under drivers/vdpa/.
>>>
>>> Create the general files for vDPA class in drivers and in documentation.
>>>
>>> Signed-off-by: Matan Azrad 
>>> ---
>>>  doc/guides/index.rst  |  1 +
>>>  doc/guides/vdpadevs/index.rst | 13 +
>>>  drivers/Makefile  |  2 ++
>>>  drivers/meson.build   |  1 +
>>>  drivers/vdpa/Makefile |  8 
>>>  drivers/vdpa/meson.build  |  8 
>>>  6 files changed, 33 insertions(+)
>>>  create mode 100644 doc/guides/vdpadevs/index.rst
>>>  create mode 100644 drivers/vdpa/Makefile
>>>  create mode 100644 drivers/vdpa/meson.build
>>>
>>
>> Looks good to me. Just wondering if we need a dedicated maintainer for
>> this new class of devices?
> 
> We must create a new section in MAINTAINERS file for vDPA drivers.
> Maxime, are you OK to merge those drivers in dpdk-next-virtio tree?

Sure, I can do that.

Maxime

Re: [dpdk-dev] [PATCH v1 2/3] doc: add vDPA feature table

[Matan Azrad]

From: Tiwei Bie
> On Wed, Jan 08, 2020 at 10:42:48AM +, Matan Azrad wrote:
> > Hi all
> >
> > Thanks very much for the review.
> > Please see below.
> >
> > From: Andrew Rybchenko
> > > On 1/8/20 8:28 AM, Tiwei Bie wrote:
> > > > On Tue, Jan 07, 2020 at 06:39:36PM +0100, Maxime Coquelin wrote:
> > > >> On 12/25/19 4:19 PM, Matan Azrad wrote:
> > > >>> Add vDPA devices features table and explanation.
> > > >>>
> > > >>> Any vDPA driver can add its own supported features by ading a
> > > >>> new ini file to the features directory in
> doc/guides/vdpadevs/features.
> > > >>>
> > > >>> Signed-off-by: Matan Azrad 
> > > >>> ---
> > > >>>  doc/guides/conf.py|  5 +++
> > > >>>  doc/guides/vdpadevs/features/default.ini  | 55
> > > >>> ++
> > > doc/guides/vdpadevs/features_overview.rst | 65
> > > +++
> > > >>>  doc/guides/vdpadevs/index.rst |  1 +
> > > >>>  4 files changed, 126 insertions(+)  create mode 100644
> > > >>> doc/guides/vdpadevs/features/default.ini
> > > >>>  create mode 100644 doc/guides/vdpadevs/features_overview.rst
> > > >>>
> > > >>> diff --git a/doc/guides/conf.py b/doc/guides/conf.py index
> > > >>> 0892c06..c368fa5 100644
> > > >>> --- a/doc/guides/conf.py
> > > >>> +++ b/doc/guides/conf.py
> > > >>> @@ -401,6 +401,11 @@ def setup(app):
> > > >>>  'Features',
> > > >>>  'Features availability in compression 
> > > >>> drivers',
> > > >>>  'Feature')
> > > >>> +table_file = dirname(__file__) +
> > > '/vdpadevs/overview_feature_table.txt'
> > > >>> +generate_overview_table(table_file, 1,
> > > >>> +'Features',
> > > >>> +'Features availability in vDPA drivers',
> > > >>> +'Feature')
> > > >>>
> > > >>>  if LooseVersion(sphinx_version) < LooseVersion('1.3.1'):
> > > >>>  print('Upgrade sphinx to version >= 1.3.1 for '
> > > >>> diff --git a/doc/guides/vdpadevs/features/default.ini
> > > >>> b/doc/guides/vdpadevs/features/default.ini
> > > >>> new file mode 100644
> > > >>> index 000..a3e0bc7
> > > >>> --- /dev/null
> > > >>> +++ b/doc/guides/vdpadevs/features/default.ini
> > > >>> @@ -0,0 +1,55 @@
> > > >>> +;
> > > >>> +; Features of a default vDPA driver.
> > > >>> +;
> > > >>> +; This file defines the features that are valid for inclusion
> > > >>> +in ; the other driver files and also the order that they appear
> > > >>> +in ; the features table in the documentation. The feature
> > > >>> +description ; string should not exceed feature_str_len defined in
> conf.py.
> > > >>> +;
> > > >> I think some entries below could be removed for vDPA.
> > > > +1
> > > >
> > > >>> +[Features]
> > > >>> +csum =
> > > >>> +guest csum   =
> > > >>> +mac  =
> > > >>> +gso  =
> > > >>> +guest tso4   =
> > > >>> +guest tso6   =
> > > >>> +ecn  =
> > > >>> +ufo  =
> > > >>> +host tso4=
> > > >>> +host tso6=
> > > >>> +mrg rxbuf=
> > > >>> +ctrl vq  =
> > > >>> +ctrl rx  =
> > > >>> +any layout   =
> > > >>> +guest announce   =
> > > >>> +mq   =
> > > >>> +version 1=
> > > >>> +log all  =
> > > >>> +protocol features=
> > > > We may not need to list this. The proto * would imply it.
> >
> > So can you explain why this flag is exposed by the vhost features?
> 
> This feature is needed in vhost-user to allow master and slave to negotiate
> protocol features in a backward compatible way. Supports of any proto
> features would imply the support of this feature. If we want to shorten this
> list, it can be a good candidate for removal.
> 

Ok, will remove.

> > > >>> +indirect desc=
> > > >>> +event idx=
> > > >>> +mtu  =
> > > >>> +in_order =
> > > >>> +IOMMU platform   =
> > > >>> +packed   =
> > > >>> +proto mq =
> > > >>> +proto log shmfd  =
> > > >>> +proto rarp   =
> > > >>> +proto reply ack  =
> > > >>> +proto slave req  =
> > > > Ditto. This feature is to be used by other features.
> > > > Features like host notifier would imply it.
> >
> > So can you explain why this flag is exposed by the vhost protocol features?
> 
> This feature allows master and slave to setup a slave channel in a backward
> compatible way. Having a slave channel between master and slave without
> any other features using it isn't very useful. I.e. this feature is supposed 
> to be
> used by the features like pagefault, host notifier. And supports of these
> features would imply the support of this feature as well. So it can be a good
> candidate for removal to shorten this list.


Ok, will remove.

Thanks.

Re: [dpdk-dev] 18.11.6 (LTS) patches review and test

[Julien Meunier]

Hi,

I launched UT on my target which has a QAT VF device, binded to igb_uio.

 + TestCase [97] : test_null_auth_only_operation failed
 + TestCase [99] : test_null_cipher_auth_operation failed

When I did some debug, I saw that the content of the digest is 0.

If I revert ac0a49ed9258 ("crypto/qat: fix null auth when using VFIO"), 
all tests are OK.


This issue is not seen on master branch, because other UTs are executed 
for QAT PMDs in order to check NULL algo. UTs were a reworked, see 
af46a0bc0c5b ("test/crypto: add NULL algo to loop test mechanism")


My commit does not seem to add any specific regression.

Regards,

On 08/01/2020 19:34, Kevin Traynor wrote:

On 24/12/2019 10:07, Yu, PingX wrote:

Kevin,
Update the regression test result of Intel part. See the details as below.



Hi Yu Ping,

thanks for the report and the log files.


# Basic Intel(R) NIC testing
* PF(i40e): Pass
* PF(ixgbe): Pass
* VF: Pass
* Build or compile: 2 bugs are found.
1. [dpdk-stable 18.11.6-rc1] meson build failed on FreeBSD12.1(See freebsd 
12.1.log.txt)


I have a fix for this and another FreeBSD+meson issue that was hidden by
this.


2. [dpdk-stable 18.11.6-rc1] make build failed on fedora31.(See 
fedora31.log.txt)


I have fixes for this and some other issues I found with clang 9.0 and
gcc 9 on F31.


* Intel NIC single core/NIC performance: Pass
  
#Basic cryptodev and virtio testing

* vhost/virtio basic loopback, PVP and performance test: Pass.
* cryptodev: 2 bugs are found.
1. [dpdk-stable-18.11.6]Crypto: cryptodev_qat_autotest test failed. PS: issue 
passed on 18.11.3 and 18.11.5.


Looking at commits related to crypto/qat I see:

commit f7a7842ebec33c9cda3f5aac119adea4ce4f6999
Author: Hemant Agrawal 
Date:   Wed Dec 18 10:15:27 2019 +0530

 test/crypto: fix session init failure for wireless case

 [ upstream commit 2967612f44b9726cb14242ae61658f2c944188d2 ]

commit 2674667aac56448c8bd151bc082e64ef4c88b649
Author: Arek Kusztal 
Date:   Tue Oct 22 16:22:25 2019 +0200

 crypto/qat: fix AES CMAC mininum digest size

 [ upstream commit a7f8087bbdbe9a69fdd0bbc77237dd3a2014ce71 ]


commit ac0a49ed92588f961b1f5e659d27c70f078eea13
Author: Damian Nowak 
Date:   Fri Aug 9 11:29:01 2019 +0200

 crypto/qat: fix null auth when using VFIO

 [ upstream commit 65beb9abca6dbb2167a53ab31d79e03f0857357b ]


commit cde0c9ce68d3a5975a57ef09a28252c44cfe4ac6
Author: Fiona Trahe 
Date:   Tue Sep 10 17:32:10 2019 +0100

 crypto/qat: fix digest length in XCBC capability

 [ upstream commit 0996ed0d5ad65b6419e3ce66a420199c3ed45ca9 ]

commit 8db57afd7ab9a3c12d73f1f5461415690b8c173c
Author: Julien Meunier 
Date:   Wed Oct 16 13:21:11 2019 +0300

 cryptodev: fix checks related to device id

 [ upstream commit 3dd4435cf473f5d10b99282098821fb40b72380f ]

commit 8dec9eab6ac4eca67cb8df2dcdd5a09eaf86bc8e
Author: Julien Meunier 
Date:   Wed Aug 7 11:39:23 2019 +0300

 cryptodev: fix initialization on multi-process

 [ upstream commit 1a60db7f354a52add0c1ea66e55ba7beba1a9716 ]


2. [dpdk-stable-18.11.6]Crypto: cryptodev_aesni_mb_autotest. Fail on 
18.11.2~18.11.6 with latest configuration.



As you can see from that, I don't think the UT were ever really stable
and a lot of the stabilisation work came after 18.11. If the
maintainers/authors (cc) want to investigate, I can take patches or
revert if required. Otherwise, I won't investigate further or block the
release on UT fails.

thanks,
Kevin.


Regards,
Yu Ping


-Original Message-
From: Kevin Traynor [mailto:ktray...@redhat.com]
Sent: Wednesday, December 18, 2019 7:42 PM
To: sta...@dpdk.org
Cc: dev@dpdk.org; Abhishek Marathe ;
Akhil Goyal ; Ali Alnubani ;
Walker, Benjamin ; David Christensen
; Hemant Agrawal ;
Stokes, Ian ; Jerin Jacob ;
Mcnamara, John ; Ju-Hyoung Lee
; Kevin Traynor ; Luca
Boccassi ; Pei Zhang ; Yu, PingX
; Xu, Qian Q ; Raslan Darawsheh
; Thomas Monjalon ; Peng,
Yuan ; Chen, Zhaoyan 
Subject: 18.11.6 (LTS) patches review and test

Hi all,

Here is a list of patches targeted for LTS release 18.11.6.

The planned date for the final release is 31st January.

Please help with testing and validation of your use cases and report any
issues/results with reply-all to this mail. For the final release the fixes and
reported validations will be added to the release notes.

A release candidate tarball can be found at:

 https://dpdk.org/browse/dpdk-stable/tag/?id=v18.11.6-rc1

These patches are located at branch 18.11 of dpdk-stable repo:
 https://dpdk.org/browse/dpdk-stable/

Thanks.

Kevin.

---
Aaron Conole (1):
   test/interrupt: account for race with callback

Abhishek Sachan (1):
   net/af_packet: fix stale sockets

Adrian Moreno (4):
   vhost: fix vring memory partially mapped
   vhost: translate incoming log address to GPA
   vhost: prevent zero copy mode if IOMMU is on
   vhost: convert buffer addresses to GPA for logging

Ajit Khaparde (9):
   net/bnxt: fix setting max RSS contexts
 

Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device drivers

[Thomas Monjalon]

09/01/2020 03:27, Xu, Rosen:
> Hi,
> 
> From: Thomas Monjalon 
> > 08/01/2020 13:39, Xu, Rosen:
> > > From: Matan Azrad 
> > > > From: Xu, Rosen
> > > > > Did you think about OVS DPDK?
> > > > > vDPA is a basic module for OVS, currently it will take some
> > > > > exception path packet processing for OVS, so it still needs to 
> > > > > integrate
> > eth_dev.
> > > >
> > > > I don't understand your question.
> > > >
> > > > What do you mean by "integrate eth_dev"?
> > >
> > > My questions is in OVS DPDK scenario vDPA device implements eth_dev
> > > ops, so create a new class and move ifc code to this new class is not ok.
> > 
> > 1/ I don't understand the relation with OVS.
> >
> > 2/ no, vDPA device implements vDPA ops.
> > If it implements ethdev ops, it is an ethdev device.
> > 
> > Please show an example of what you claim.
> 
> Answers of 1 and 2.
> 
> In OVS DPDK, each network device(such as NIC, vHost etc) of DPDK needs to be 
> implemented
> as rte_eth_dev and provides eth_dev_ops such as packet TX/RX for OVS.

No, OVS is also using the vhost API for vhost port.

> Take vHost(Virtio back end) for example, OVS startups vHost interface like 
> this:
> ovs-vsctl add-port br0 vhost-user-1 -- set Interface vhost-user-1 
> type=dpdkvhostuser
> drivers/net/vhost implements vHost as rte_eth_dev and integrated in OVS.
> OVS can send/receive packets to/from VM with rte_eth_tx_burst()  
> rte_eth_rx_burst()
> which call eth_dev_ops implementation of drivers/net/vhost.

No, it is using rte_vhost_dequeue_burst() and rte_vhost_enqueue_burst()
which are not in ethdev.

> vDPA is also Virtio back end and works like vHost, same as vHost,
> it will be implemented as rte_eth_dev and also be integrated into OVS.

No, vDPA is not "implemented as rte_eth_dev".

> So, it's not ok to move ifc code from drivers/net.

drivers/net/ifc has no ethdev implementation at all.


Rosen, I'm sorry, these arguments look irrelevant,
so I won't consider them as blocking the integration of this patch.

Re: [dpdk-dev] [dpdk-stable] [PATCH] net/mlx5: fix ConnectX-4LX Tx burst routines set

[Slava Ovsiienko]

> -Original Message-
> From: Ferruh Yigit 
> Sent: Wednesday, January 8, 2020 17:55
> To: Slava Ovsiienko ; dev@dpdk.org
> Cc: Matan Azrad ; Raslan Darawsheh
> ; Ori Kam ; sta...@dpdk.org;
> Thomas Monjalon 
> Subject: Re: [dpdk-stable] [PATCH] net/mlx5: fix ConnectX-4LX Tx burst
> routines set
> 
> On 1/8/2020 3:50 PM, Slava Ovsiienko wrote:
> > Hi, Ferruh
> >
> >> -Original Message-
> >> From: Ferruh Yigit 
> >> Sent: Wednesday, January 8, 2020 16:55
> >> To: Slava Ovsiienko ; dev@dpdk.org
> >> Cc: Matan Azrad ; Raslan Darawsheh
> >> ; Ori Kam ;
> >> sta...@dpdk.org; Thomas Monjalon 
> >> Subject: Re: [dpdk-stable] [PATCH] net/mlx5: fix ConnectX-4LX Tx
> >> burst routines set
> >>
> >> On 1/8/2020 2:53 PM, Ferruh Yigit wrote:
> >>> On 12/20/2019 10:48 AM, Viacheslav Ovsiienko wrote:
>  The tx_burst routine supporting multi-segment packets with legacy
>  MPW and without inline was missed, and there was no valid selection
>  for these options, patch adds the missing routine.
> 
>  Fixes: 82e75f8323bf ("net/mlx5: fix legacy multi-packet Tx
>  descriptors")
>  Cc: sta...@dpdk.org
> 
>  Signed-off-by: Viacheslav Ovsiienko 
> 
> <...>
> 
>  @@ -5297,6 +5305,7 @@ enum mlx5_txcmp_code {
>   DRV_LOG(DEBUG, "port %u has no selected Tx function"
>  " for requested offloads %04X",
>   dev->data->port_id, olx);
>  +assert(false);
> 
> <...>
> 
> >
> >>
> >>>
> >>> I think we should avoid PMDs calling the assert unconditionally,
> >>> specially in a code that debug level log is printed.
> >>>
>   return NULL;
>   }
>   DRV_LOG(DEBUG, "port %u has selected Tx function"
> >
> > Yes, I agree. We just do not have the check for the result returned by
> > mlx5_select_tx_function(). I think we should check against NULL and
> > report an error.  "assert" is a temporary solution till this upgrade
> > (in debug mode we have a lot of messages and break on assert helps to
> > locate the problem quickly, reporting error will do the same).
> >
> 
> Can it be possible to drop the patch from mlx tree and prepare a new version
> without 'assert'?
The selection routine error handling is rather generic and is not merely 
related to ConnectX-4LX.
I propose to prepare the dedicated patch, what do you  think?

With best regards, Slava

Re: [dpdk-dev] [PATCH v2 01/10] app/testpmd: parse flow command line for ESP

[Iremonger, Bernard]

Hi Ori,



> > Subject: RE: [dpdk-dev] [PATCH v2 01/10] app/testpmd: parse flow
> > command line for ESP
> >
> > Hi Ori,
> >
> > Thanks for the review.
> >
> > 
> >
> > > Subject: RE: [dpdk-dev] [PATCH v2 01/10] app/testpmd: parse flow
> > > command line for ESP
> > >
> > > Hi just small comment inside.
> > > Thanks,
> > > Ori
> > >
> > > > -Original Message-
> > > > From: dev  On Behalf Of Bernard Iremonger
> > > > Sent: Tuesday, December 17, 2019 12:16 PM
> > > > To: dev@dpdk.org; beilei.x...@intel.com; qi.z.zh...@intel.com;
> > > > declan.dohe...@intel.com
> > > > Cc: konstantin.anan...@intel.com; bernard.iremon...@intel.com
> > > > Subject: [dpdk-dev] [PATCH v2 01/10] app/testpmd: parse flow
> > command
> > > > line for ESP
> > > >
> > > > add ITEM_ESP
> > > > add ITEM_ESP_SPI
> > > > add debug to cmdline_flow.c
> > > >
> > > > Signed-off-by: Bernard Iremonger 
> > > > ---
> > > >  app/test-pmd/cmdline_flow.c | 37
> > > > ++---
> > > >  1 file changed, 34 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/app/test-pmd/cmdline_flow.c b/app/test-
> > pmd/cmdline_flow.c
> > > > index 99dade7..f1b0610 100644
> > > > --- a/app/test-pmd/cmdline_flow.c
> > > > +++ b/app/test-pmd/cmdline_flow.c
> > > > @@ -213,6 +213,8 @@ enum index {
> > > > ITEM_TAG,
> > > > ITEM_TAG_DATA,
> > > > ITEM_TAG_INDEX,
> > > > +   ITEM_ESP,
> > > > +   ITEM_ESP_SPI,
> > > >
> > > > /* Validate/create actions. */
> > > > ACTIONS,
> > > > @@ -746,6 +748,7 @@ static const enum index next_item[] = {
> > > > ITEM_PPPOE_PROTO_ID,
> > > > ITEM_HIGIG2,
> > > > ITEM_TAG,
> > > > +   ITEM_ESP,
> > > > END_SET,
> > > > ZERO,
> > > >  };
> > > > @@ -1017,6 +1020,12 @@ static const enum index item_higig2[] = {
> > > > ZERO,
> > > >  };
> > > >
> > > > +static const enum index item_esp[] = {
> > > > +   ITEM_ESP_SPI,
> > > > +   ITEM_NEXT,
> > > > +   ZERO,
> > > > +};
> > > > +
> > > >  static const enum index next_set_raw[] = {
> > > > SET_RAW_INDEX,
> > > > ITEM_ETH,
> > > > @@ -2593,6 +2602,20 @@ static const struct token token_list[] = {
> > > >  NEXT_ENTRY(ITEM_PARAM_IS)),
> > > > .args = ARGS(ARGS_ENTRY(struct rte_flow_item_tag,
> > > index)),
> > > > },
> > > > +   [ITEM_ESP] = {
> > > > +   .name = "esp",
> > > > +   .help = "match ESP header",
> > > > +   .priv = PRIV_ITEM(ESP, sizeof(struct 
> > > > rte_flow_item_esp)),
> > > > +   .next = NEXT(item_esp),
> > > > +   .call = parse_vc,
> > > > +   },
> > > > +   [ITEM_ESP_SPI] = {
> > > > +   .name = "spi",
> > > > +   .help = "security policy index",
> > > > +   .next = NEXT(item_esp, NEXT_ENTRY(UNSIGNED),
> > > > item_param),
> > > > +   .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_esp,
> > > > +   hdr.spi)),
> > > > +   },
> > > > /* Validate/create actions. */
> > > > [ACTIONS] = {
> > > > .name = "actions",
> > > > @@ -6052,6 +6075,9 @@ cmd_flow_tok(cmdline_parse_token_hdr_t
> > > **hdr,
> > > > static void  cmd_flow_parsed(const struct buffer *in)  {
> > > > +   printf("Flow command line parsed successfully for
> > > > command=%d.\n",
> > > > +   in->command);
> > > > +
> > >
> > > Why adding this printf?
> >
> > It is useful to know that the parsing of the flow command line is
> > successful before going into the PMD code.
> > I will remove in the v3 if you think it is too verbose.
> >
> 
> I think it is to verbose, due to the fact that in normal case the parsing will
> succeed, Which means there will be a lot of print (In our testing we can have
> more then 200K commands).
> So I prefer to remove it, but if you think it is critical you can use the
> verbose_level with high value.
> If you remove it feel free to add my ack on v3.

I will remove it and add your ack in v3.


> > >
> > > > switch (in->command) {
> > > > case VALIDATE:
> > > > port_flow_validate(in->port, &in->args.vc.attr, @@ 
> > > > -6230,14
> > > > +6256,15 @@ flow_item_default_mask(const struct rte_flow_item
> > *item)
> > > > case RTE_FLOW_ITEM_TYPE_GTP:
> > > > mask = &rte_flow_item_gtp_mask;
> > > > break;
> > > > -   case RTE_FLOW_ITEM_TYPE_ESP:
> > > > -   mask = &rte_flow_item_esp_mask;
> > > > -   break;
> > > > case RTE_FLOW_ITEM_TYPE_GTP_PSC:
> > > > mask = &rte_flow_item_gtp_psc_mask;
> > > > break;
> > > > case RTE_FLOW_ITEM_TYPE_PPPOE_PROTO_ID:
> > > > mask = &rte_flow_item_pppoe_proto_id_mask;
> > > > +   break;
> > > > +   case RTE_FLOW_ITEM_TYPE_ESP:
> > > > +   mask = &rte_

Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device drivers

[Maxime Coquelin]

On 1/9/20 9:41 AM, Thomas Monjalon wrote:
> 09/01/2020 03:27, Xu, Rosen:
>> Hi,
>>
>> From: Thomas Monjalon 
>>> 08/01/2020 13:39, Xu, Rosen:
 From: Matan Azrad 
> From: Xu, Rosen
>> Did you think about OVS DPDK?
>> vDPA is a basic module for OVS, currently it will take some
>> exception path packet processing for OVS, so it still needs to integrate
>>> eth_dev.
>
> I don't understand your question.
>
> What do you mean by "integrate eth_dev"?

 My questions is in OVS DPDK scenario vDPA device implements eth_dev
 ops, so create a new class and move ifc code to this new class is not ok.
>>>
>>> 1/ I don't understand the relation with OVS.
>>>
>>> 2/ no, vDPA device implements vDPA ops.
>>> If it implements ethdev ops, it is an ethdev device.
>>>
>>> Please show an example of what you claim.
>>
>> Answers of 1 and 2.
>>
>> In OVS DPDK, each network device(such as NIC, vHost etc) of DPDK needs to be 
>> implemented
>> as rte_eth_dev and provides eth_dev_ops such as packet TX/RX for OVS.
> 
> No, OVS is also using the vhost API for vhost port.
> 
>> Take vHost(Virtio back end) for example, OVS startups vHost interface like 
>> this:
>> ovs-vsctl add-port br0 vhost-user-1 -- set Interface vhost-user-1 
>> type=dpdkvhostuser
>> drivers/net/vhost implements vHost as rte_eth_dev and integrated in OVS.
>> OVS can send/receive packets to/from VM with rte_eth_tx_burst()  
>> rte_eth_rx_burst()
>> which call eth_dev_ops implementation of drivers/net/vhost.
> 
> No, it is using rte_vhost_dequeue_burst() and rte_vhost_enqueue_burst()
> which are not in ethdev.
> 
>> vDPA is also Virtio back end and works like vHost, same as vHost,
>> it will be implemented as rte_eth_dev and also be integrated into OVS.
> 
> No, vDPA is not "implemented as rte_eth_dev".
> 
>> So, it's not ok to move ifc code from drivers/net.
> 
> drivers/net/ifc has no ethdev implementation at all.
> 
> 
> Rosen, I'm sorry, these arguments look irrelevant,
> so I won't consider them as blocking the integration of this patch.
> 
> 

I agree with Thomas, the vDPA drivers do not implement the ethdev ops.
And OVS does not use the Vhost PMD for the Vhost-user ports, but
directly call the librte_vhost APIs.

Regards,
Maxime

Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device drivers

[Xu, Rosen]

> -Original Message-
> From: Maxime Coquelin 
> Sent: Thursday, January 09, 2020 17:24
> To: Thomas Monjalon ; Xu, Rosen
> 
> Cc: Matan Azrad ; Bie, Tiwei ;
> Wang, Zhihong ; Wang, Xiao W
> ; Yigit, Ferruh ;
> dev@dpdk.org; Pei, Andy 
> Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device
> drivers
> 
> 
> 
> On 1/9/20 9:41 AM, Thomas Monjalon wrote:
> > 09/01/2020 03:27, Xu, Rosen:
> >> Hi,
> >>
> >> From: Thomas Monjalon 
> >>> 08/01/2020 13:39, Xu, Rosen:
>  From: Matan Azrad 
> > From: Xu, Rosen
> >> Did you think about OVS DPDK?
> >> vDPA is a basic module for OVS, currently it will take some
> >> exception path packet processing for OVS, so it still needs to
> >> integrate
> >>> eth_dev.
> >
> > I don't understand your question.
> >
> > What do you mean by "integrate eth_dev"?
> 
>  My questions is in OVS DPDK scenario vDPA device implements eth_dev
>  ops, so create a new class and move ifc code to this new class is not ok.
> >>>
> >>> 1/ I don't understand the relation with OVS.
> >>>
> >>> 2/ no, vDPA device implements vDPA ops.
> >>> If it implements ethdev ops, it is an ethdev device.
> >>>
> >>> Please show an example of what you claim.
> >>
> >> Answers of 1 and 2.
> >>
> >> In OVS DPDK, each network device(such as NIC, vHost etc) of DPDK
> >> needs to be implemented as rte_eth_dev and provides eth_dev_ops such
> as packet TX/RX for OVS.
> >
> > No, OVS is also using the vhost API for vhost port.
> >
> >> Take vHost(Virtio back end) for example, OVS startups vHost interface like
> this:
> >> ovs-vsctl add-port br0 vhost-user-1 -- set Interface vhost-user-1
> >> type=dpdkvhostuser drivers/net/vhost implements vHost as rte_eth_dev
> and integrated in OVS.
> >> OVS can send/receive packets to/from VM with rte_eth_tx_burst()
> >> rte_eth_rx_burst() which call eth_dev_ops implementation of
> drivers/net/vhost.
> >
> > No, it is using rte_vhost_dequeue_burst() and
> > rte_vhost_enqueue_burst() which are not in ethdev.
> >
> >> vDPA is also Virtio back end and works like vHost, same as vHost, it
> >> will be implemented as rte_eth_dev and also be integrated into OVS.
> >
> > No, vDPA is not "implemented as rte_eth_dev".
> >
> >> So, it's not ok to move ifc code from drivers/net.
> >
> > drivers/net/ifc has no ethdev implementation at all.
> >
> >
> > Rosen, I'm sorry, these arguments look irrelevant, so I won't consider
> > them as blocking the integration of this patch.
> >
> >
> 
> I agree with Thomas, the vDPA drivers do not implement the ethdev ops.

For OVS hasn't integrated vDPA, it doesn't implement ethdev ops, but there are 
many
discussions in OVS community about vDPA, it seems vDPA will be supported in OVS 
in
the near feature.

> And OVS does not use the Vhost PMD for the Vhost-user ports, but directly
> call the librte_vhost APIs.

I'm afraid you are wrong, pls read these documents which introduce how to use 
vHost-user PMD in OVS:
http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/
http://docs.openvswitch.org/en/latest/topics/dpdk/pmd/

> Regards,
> Maxime

Re: [dpdk-dev] [PATCH v2 0/10] dpdk: introduce __rte_internal tag

[David Marchand]

Hello Neil,

On Tue, Aug 6, 2019 at 2:22 PM Neil Horman  wrote:
>
> On Tue, Aug 06, 2019 at 12:03:38PM +0200, Thomas Monjalon wrote:
> > I think it would be good to rebase and send at the beginning of the 19.11 
> > cycle.
> > Thank you
> >
> I'm on PTO for the next 10 days or so, but yes, I'll take care of that asap.

Looks like your PTO were a bit longer than 10 days ;-).
Do you have some cycles to resurrect this series?


--
David Marchand

Re: [dpdk-dev] [PATCH v1] net/axgbe: Add a HW quirk for register definitions

[Ferruh Yigit]

On 1/9/2020 7:15 AM, Sebastian, Selwin wrote:
> [AMD Official Use Only - Internal Distribution Only]
> 
> Hi Ferruh,
>   I submitted v2 of the patch as per your guidelines. I checked 
> sub-device ids and they are also the same. I am not aware of a better way to 
> address this issue and even Linux driver is handling it using the same quirk. 

Unfortunately HW quirks are happens. As a last try, can there be any FW version,
PHY/MAC type, any specific register value to differentiate the device?
to prevent accessing the pci device list...

> Yes,  root complex device will always be the first device.
> 
> Thanks and Regards
> Selwin Sebastian
>  
> -Original Message-
> From: Ferruh Yigit  
> Sent: Tuesday, January 7, 2020 7:28 PM
> To: Sebastian, Selwin ; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v1] net/axgbe: Add a HW quirk for register 
> definitions
> 
> [CAUTION: External Email]
> 
> On 12/17/2019 6:44 AM, Sebastian, Selwin wrote:
>> [AMD Official Use Only - Internal Distribution Only]
>>
>> Hi Ferruh,
>>   Current driver was developed for EPYC 3000 processors. New processors 
>> V1000/R1000 is also using the same PCI id for axgbe but register definitions 
>> for determining the window settings for indirect PCS access is changed. In 
>> order to identify processor, we are adding a quirk.
>> 15d0 is the pci id for V1000/R1000/Raven root complex( 
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpci-ids.ucw.cz%2Fread%2FPC%2F1022&data=02%7C01%7CSelwin.Sebastian%40amd.com%7C2730af7407924ee8bea308d793798ebb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637140022603089567&sdata=myGZCIkcjEOI31SLvkVvqdDww0AbpxZrsr47LpBiDHA%3D&reserved=0
>>  ). Hence read pci-id of root complex  to determine which processor and set 
>> the registers accordingly.
>>
> 
> Got it, it is better to add a define for 0x15d0 with an explanation, and for 
> the root complex device use a more descriptive variable name that 'pdev'.
> 
> But still it is not really good idea to access the pci device list, isn't 
> there any other way to differentiate the devices, sub-device id etc? And how 
> does linux driver manages this?
> 
> And is it guaranteed that root complex device always will be the first device?
> 
> 
>> Thanks and Regards
>> Selwin Sebastian
>>
>>
>> -Original Message-
>> From: Ferruh Yigit 
>> Sent: Wednesday, December 11, 2019 5:12 PM
>> To: Sebastian, Selwin ; dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v1] net/axgbe: Add a HW quirk for 
>> register definitions
>>
>> [CAUTION: External Email]
>>
>> On 12/10/2019 3:29 PM, Selwin Sebastian wrote:
>>> V1000/R1000 processors are using the same PCI ids for the network 
>>> device but has altered register definitions for determining the 
>>> window settings for the indirect PCS access.Add support to check for 
>>> this hardware and if found use the new register values
>>
>> How they are differentiated, subdevice ids?
>> If so should we add subdevice fields check into DPDK?
>>
>>>
>>> Signed-off-by: Selwin Sebastian 
>>> ---
>>>  drivers/net/axgbe/axgbe_common.h |  2 ++ 
>>> drivers/net/axgbe/axgbe_ethdev.c | 18 +++---
>>>  2 files changed, 17 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/axgbe/axgbe_common.h
>>> b/drivers/net/axgbe/axgbe_common.h
>>> index 34f60f156..4a3fbac16 100644
>>> --- a/drivers/net/axgbe/axgbe_common.h
>>> +++ b/drivers/net/axgbe/axgbe_common.h
>>> @@ -841,6 +841,8 @@
>>>  #define PCS_V1_WINDOW_SELECT 0x03fc
>>>  #define PCS_V2_WINDOW_DEF0x9060
>>>  #define PCS_V2_WINDOW_SELECT 0x9064
>>> +#define PCS_V2_RV_WINDOW_DEF 0x1060
>>> +#define PCS_V2_RV_WINDOW_SELECT  0x1064
>>>
>>>  /* PCS register entry bit positions and sizes */
>>>  #define PCS_V2_WINDOW_DEF_OFFSET_INDEX   6
>>> diff --git a/drivers/net/axgbe/axgbe_ethdev.c
>>> b/drivers/net/axgbe/axgbe_ethdev.c
>>> index d1f160e79..25e182b8d 100644
>>> --- a/drivers/net/axgbe/axgbe_ethdev.c
>>> +++ b/drivers/net/axgbe/axgbe_ethdev.c
>>> @@ -31,6 +31,7 @@ static int  axgbe_dev_info_get(struct rte_eth_dev *dev,
>>>  #define AMD_PCI_VENDOR_ID   0x1022
>>>  #define AMD_PCI_AXGBE_DEVICE_V2A 0x1458  #define 
>>> AMD_PCI_AXGBE_DEVICE_V2B 0x1459
>>> +extern struct rte_pci_bus rte_pci_bus;
>>
>> Not sure about accessing the bus device list from a PMD...
>>
>>>
>>>  int axgbe_logtype_init;
>>>  int axgbe_logtype_driver;
>>> @@ -585,6 +586,7 @@ eth_axgbe_dev_init(struct rte_eth_dev *eth_dev)
>>>   struct rte_pci_device *pci_dev;
>>>   uint32_t reg, mac_lo, mac_hi;
>>>   int ret;
>>> + struct rte_pci_device *pdev;
>>>
>>>   eth_dev->dev_ops = &axgbe_eth_dev_ops;
>>>   eth_dev->rx_pkt_burst = &axgbe_recv_pkts; @@ -605,6 +607,17 @@ 
>>> eth_axgbe_dev_init(struct rte_eth_dev *eth_dev)
>>>   pci_dev = RTE_DEV_TO_PCI(eth_dev->device);
>>>   pdata->pci_dev = pci_dev;
>>>
>>> + pdev = TAILQ_FIRST(&rte_pci_bus.device_list);
>>
>> Can you please describe what this 

Re: [dpdk-dev] l2fwd application are not sending continuous packets .

[satyavalli rama]

Thanks Stephen,
We've tried to debug issue in couple of ways, please correct us whether
these approaches or right not wrong?
1. We have increased the MAX_PKT_BURST from 32 to 64 and
MEMEPOOL_CAHCE_SIZE 256 to 512
2. Keeping IGB_UIO as the only driver module.
3. Resetting the RX queues.
But still we are seeing the issue, as mentioned above
> > * Debugging and Observations :-=*
> > When I tried to debug this issue , I could see that
> > 1) In problematic state, rx queue of VM-3 is not getting packets, but
VM-2
> > is sending packets properly. I checked this by using pdump of rx queue.
> > 2) Just before problematic state in VM-3, I could see that  previous
> > packet(only one packet) instead of going to VM-4, it is coming back to
> > again in rx queue of VM-3 and after wards I did not get any packets in
rx
> > queue.


On Thu, Jan 9, 2020, 11:42 Stephen Hemminger 
wrote:

> On Thu, 9 Jan 2020 07:25:45 +0530
> satyavalli rama  wrote:
>
> > Can anyone please help us with this?
> >
> >
> > On Mon, Jan 6, 2020, 11:25 satyavalli rama 
> > wrote:
> >
> > >
> > >
> > >
> > > Hello Dpdk Team,
> > >
> > > I'm facing issue while forwarding packets in DPDK's l2fwd application.
> > > While sending 1 Lac packets from Scapy, I could see sometimes packets
> are
> > > sending from one VM to another VM.
> > > Before explaining issue let me explain topology.
> > >
> > >
> > >
> > > *Topology :-===*1) I am having 4 VMs(Virtual Machines) in same
> host.
> > > All these VM are running on Ubuntu 16.04.1.
> > > 2) VM-1 is used as Scapy to forward packets (Scapy version 2.4.3) .
> While
> > > creating packets I am giving destination mac(d-mac) address of VM-1.
> > > 3) In VM-2 am running L2 forwarding application.
> > > In this l2fwd application, I am doing simple packet forwarding by
> > > statically keeping mac address of VM-3.
> > > Code :-
> > >  l2fwd_mac_updating () {
> > >...
> > >..
> > >...
> > >   *((uint64_t *)tmp) = 0xddccbbaa/*VM-3 mac address*/ +
> > > ((uint64_t)dest_portid << 40);
> > >  }
> > > 4) Also in VM-3, I am doing same like VM-2, but I kept mac address of
> VM-4
> > > 5) In VM-4, I am using wireshark to see packets coming from VM-3.
> > > 6) In VM-2 and VM-3, I kept promiscuous mode off by commenting out
> > > rte_eth_promiscuous_enable().
> > >
> > >---
>  -
> > >  --
> > > 
> > >|VM-1  |  -->|   VM-2 |
> > > >   | VM-3|   --> |
> VM-4
> > >  |
> > >---
>  -
> > >  --
> > > 
> > > Scapy  Simple L2 forwarding
> > > Simple L2 forwardingWireshark
> > > used for sending packetsSending all packets to
> > >  Sending all packets to
> > > VM-3
> > > VM-4
> > >   (DPDK)
> > >  (DPDK)
> > >
> > >
> > > *Problem :- ==*==
> > > From scapy VM, I am sending 1 lac packets with rate of 100 packets per
> > > second. *During problematic condition I could see packets are not
> getting
> > > forward from VM-3.**Problematic state is happening anytime after
> sending
> > > 1k packets.*
> > > This issue is not consistence but I could see this issue 8 out of 10
> times.
> > >
> > >
> > > * Debugging and Observations :-=*
> > > When I tried to debug this issue , I could see that
> > > 1) In problematic state, rx queue of VM-3 is not getting packets, but
> VM-2
> > > is sending packets properly. I checked this by using pdump of rx queue.
> > > 2) Just before problematic state in VM-3, I could see that  previous
> > > packet(only one packet) instead of going to VM-4, it is coming back to
> > > again in rx queue of VM-3 and after wards I did not get any packets in
> rx
> > > queue.
> > > 3) I have changed rate of packet forward 10packets per second. but
> still
> > > see the issue.
> > >
> > >
> > > *Can anyone please help to solve this problem ? I need it urgently .*
> > > Thanks,
> > > Satya
> > >
>
> Sorry, you need to dig inside the forwarding application and instrument
> what is coming in and how packets are being processed. You usually can't
> treat DPDK as a black box.
>

[dpdk-dev] [PATCH v7 1/4] net/i40e: cleanup Tx buffers

[Chenxu Di]

Add support to the i40e driver for the API rte_eth_tx_done_cleanup
to force free consumed buffers on Tx ring.

Signed-off-by: Chenxu Di 
---
 drivers/net/i40e/i40e_ethdev.c|   3 +
 drivers/net/i40e/i40e_ethdev_vf.c |   3 +
 drivers/net/i40e/i40e_rxtx.c  | 151 ++
 drivers/net/i40e/i40e_rxtx.h  |   8 ++
 4 files changed, 165 insertions(+)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 5999c964b..e0b071891 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -522,6 +522,7 @@ static const struct eth_dev_ops i40e_eth_dev_ops = {
.mac_addr_set = i40e_set_default_mac_addr,
.mtu_set  = i40e_dev_mtu_set,
.tm_ops_get   = i40e_tm_ops_get,
+   .tx_done_cleanup  = i40e_tx_done_cleanup,
 };
 
 /* store statistics names and its offset in stats structure */
@@ -1358,6 +1359,8 @@ eth_i40e_dev_init(struct rte_eth_dev *dev, void 
*init_params __rte_unused)
dev->tx_pkt_burst = i40e_xmit_pkts;
dev->tx_pkt_prepare = i40e_prep_pkts;
 
+   i40e_set_tx_done_cleanup_func(i40e_tx_done_cleanup_scalar);
+
/* for secondary processes, we don't initialise any further as primary
 * has already done this work. Only check we don't need a different
 * RX function */
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index 5dba0928b..3dcc9434c 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -215,6 +215,7 @@ static const struct eth_dev_ops i40evf_eth_dev_ops = {
.rss_hash_conf_get= i40evf_dev_rss_hash_conf_get,
.mtu_set  = i40evf_dev_mtu_set,
.mac_addr_set = i40evf_set_default_mac_addr,
+   .tx_done_cleanup  = i40e_tx_done_cleanup,
 };
 
 /*
@@ -1473,6 +1474,8 @@ i40evf_dev_init(struct rte_eth_dev *eth_dev)
eth_dev->rx_pkt_burst = &i40e_recv_pkts;
eth_dev->tx_pkt_burst = &i40e_xmit_pkts;
 
+   i40e_set_tx_done_cleanup_func(i40e_tx_done_cleanup_scalar);
+
/*
 * For secondary processes, we don't initialise any further as primary
 * has already done this work.
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 17dc8c78f..dfbca06b6 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -2455,6 +2455,154 @@ i40e_tx_queue_release_mbufs(struct i40e_tx_queue *txq)
}
 }
 
+static i40e_tx_done_cleanup_t i40e_tx_done_cleanup_op;
+
+int
+i40e_tx_done_cleanup_scalar(struct i40e_tx_queue *txq,
+   uint32_t free_cnt)
+{
+   uint32_t pkt_cnt;
+   uint16_t i;
+   uint16_t tx_last;
+   uint16_t tx_id;
+   uint16_t nb_tx_to_clean;
+   uint16_t nb_tx_free_last;
+   struct i40e_tx_entry *swr_ring = txq->sw_ring;
+
+   /* Start free mbuf from the next of tx_tail */
+   tx_last = txq->tx_tail;
+   tx_id  = swr_ring[tx_last].next_id;
+
+   if (txq->nb_tx_free == 0)
+   if (i40e_xmit_cleanup(txq))
+   return 0;
+
+   nb_tx_to_clean = txq->nb_tx_free;
+   nb_tx_free_last = txq->nb_tx_free;
+   if (!free_cnt)
+   free_cnt = txq->nb_tx_desc;
+
+   /* Loop through swr_ring to count the amount of
+* freeable mubfs and packets.
+*/
+   for (pkt_cnt = 0; pkt_cnt < free_cnt; ) {
+   for (i = 0; i < nb_tx_to_clean &&
+   pkt_cnt < free_cnt &&
+   tx_id != tx_last; i++) {
+   if (swr_ring[tx_id].mbuf != NULL) {
+   rte_pktmbuf_free_seg(swr_ring[tx_id].mbuf);
+   swr_ring[tx_id].mbuf = NULL;
+
+   /*
+* last segment in the packet,
+* increment packet count
+*/
+   pkt_cnt += (swr_ring[tx_id].last_id == tx_id);
+   }
+
+   tx_id = swr_ring[tx_id].next_id;
+   }
+
+   if (tx_id == tx_last || txq->tx_rs_thresh
+   > txq->nb_tx_desc - txq->nb_tx_free)
+   break;
+
+   if (pkt_cnt < free_cnt) {
+   if (i40e_xmit_cleanup(txq))
+   break;
+
+   nb_tx_to_clean = txq->nb_tx_free - nb_tx_free_last;
+   nb_tx_free_last = txq->nb_tx_free;
+   }
+   }
+
+   PMD_TX_FREE_LOG(DEBUG,
+   "Free %u Packets successfully "
+   "(port=%d queue=%d)",
+   pkt_cnt, txq->port_id, txq->queue_id);
+
+   return (int)pkt_cnt;
+}
+
+int
+i40e_tx_done_cleanup_simple(struct i40e_tx_queue *txq,
+   uint32_t free_cnt)
+{
+   uint16_t i;
+  

[dpdk-dev] [PATCH v7 0/4] drivers/net: cleanup Tx buffers

[Chenxu Di]

Add support to the drivers inclulding i40e, ice, ixgbe 
and igb vf for the API rte_eth_tx_done_cleanup to force
 free consumed buffers on Tx ring.

---
v7:
changed the design of code, reuse exist function.

Chenxu Di (4):
  net/i40e: cleanup Tx buffers
  net/ice: cleanup Tx buffers
  net/ixgbe: cleanup Tx buffers
  net/e1000: cleanup Tx buffers

 drivers/net/e1000/igb_ethdev.c|   1 +
 drivers/net/i40e/i40e_ethdev.c|   3 +
 drivers/net/i40e/i40e_ethdev_vf.c |   3 +
 drivers/net/i40e/i40e_rxtx.c  | 151 +
 drivers/net/i40e/i40e_rxtx.h  |   8 ++
 drivers/net/ice/ice_ethdev.c  |   3 +
 drivers/net/ice/ice_rxtx.c| 155 +
 drivers/net/ice/ice_rxtx.h|  11 +++
 drivers/net/ixgbe/ixgbe_ethdev.c  |   4 +
 drivers/net/ixgbe/ixgbe_rxtx.c| 156 +-
 drivers/net/ixgbe/ixgbe_rxtx.h|  10 ++
 11 files changed, 504 insertions(+), 1 deletion(-)

-- 
2.17.1

[dpdk-dev] [PATCH v7 2/4] net/ice: cleanup Tx buffers

[Chenxu Di]

Add support to the ice driver for the API rte_eth_tx_done_cleanup
to force free consumed buffers on Tx ring.

Signed-off-by: Chenxu Di 
---
 drivers/net/ice/ice_ethdev.c |   3 +
 drivers/net/ice/ice_rxtx.c   | 155 +++
 drivers/net/ice/ice_rxtx.h   |  11 +++
 3 files changed, 169 insertions(+)

diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index de189daba..3d586fede 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -220,6 +220,7 @@ static const struct eth_dev_ops ice_eth_dev_ops = {
.filter_ctrl  = ice_dev_filter_ctrl,
.udp_tunnel_port_add  = ice_dev_udp_tunnel_port_add,
.udp_tunnel_port_del  = ice_dev_udp_tunnel_port_del,
+   .tx_done_cleanup  = ice_tx_done_cleanup,
 };
 
 /* store statistics names and its offset in stats structure */
@@ -2137,6 +2138,8 @@ ice_dev_init(struct rte_eth_dev *dev)
dev->tx_pkt_burst = ice_xmit_pkts;
dev->tx_pkt_prepare = ice_prep_pkts;
 
+   ice_set_tx_done_cleanup_func(ice_tx_done_cleanup_scalar);
+
/* for secondary processes, we don't initialise any further as primary
 * has already done this work.
 */
diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c
index 2db174456..db531d0fc 100644
--- a/drivers/net/ice/ice_rxtx.c
+++ b/drivers/net/ice/ice_rxtx.c
@@ -863,6 +863,9 @@ ice_fdir_tx_queue_stop(struct rte_eth_dev *dev, uint16_t 
tx_queue_id)
return 0;
 }
 
+
+
+
 int
 ice_rx_queue_setup(struct rte_eth_dev *dev,
   uint16_t queue_idx,
@@ -2643,6 +2646,155 @@ ice_tx_free_bufs(struct ice_tx_queue *txq)
return txq->tx_rs_thresh;
 }
 
+static ice_tx_done_cleanup_t ice_tx_done_cleanup_op;
+
+int
+ice_tx_done_cleanup_scalar(struct ice_tx_queue *txq,
+   uint32_t free_cnt)
+{
+   uint32_t pkt_cnt;
+   uint16_t i;
+   uint16_t tx_last;
+   uint16_t tx_id;
+   uint16_t nb_tx_to_clean;
+   uint16_t nb_tx_free_last;
+   struct ice_tx_entry *swr_ring = txq->sw_ring;
+
+   /* Start free mbuf from the next of tx_tail */
+   tx_last = txq->tx_tail;
+   tx_id  = swr_ring[tx_last].next_id;
+
+   if (txq->nb_tx_free == 0)
+   if (ice_xmit_cleanup(txq))
+   return 0;
+
+   nb_tx_to_clean = txq->nb_tx_free;
+   nb_tx_free_last = txq->nb_tx_free;
+   if (!free_cnt)
+   free_cnt = txq->nb_tx_desc;
+
+   /* Loop through swr_ring to count the amount of
+* freeable mubfs and packets.
+*/
+   for (pkt_cnt = 0; pkt_cnt < free_cnt; ) {
+   for (i = 0; i < nb_tx_to_clean &&
+   pkt_cnt < free_cnt &&
+   tx_id != tx_last; i++) {
+   if (swr_ring[tx_id].mbuf != NULL) {
+   rte_pktmbuf_free_seg(swr_ring[tx_id].mbuf);
+   swr_ring[tx_id].mbuf = NULL;
+
+   /*
+* last segment in the packet,
+* increment packet count
+*/
+   pkt_cnt += (swr_ring[tx_id].last_id == tx_id);
+   }
+
+   tx_id = swr_ring[tx_id].next_id;
+   }
+
+   if (tx_id == tx_last || txq->tx_rs_thresh
+   > txq->nb_tx_desc - txq->nb_tx_free)
+   break;
+
+   if (pkt_cnt < free_cnt) {
+   if (ice_xmit_cleanup(txq))
+   break;
+
+   nb_tx_to_clean = txq->nb_tx_free - nb_tx_free_last;
+   nb_tx_free_last = txq->nb_tx_free;
+   }
+   }
+
+   PMD_TX_FREE_LOG(DEBUG,
+   "Free %u Packets successfully "
+   "(port=%d queue=%d)",
+   pkt_cnt, txq->port_id, txq->queue_id);
+
+   return (int)pkt_cnt;
+}
+
+int
+ice_tx_done_cleanup_vec(struct ice_tx_queue *txq __rte_unused,
+   uint32_t free_cnt __rte_unused)
+{
+   return -ENOTSUP;
+}
+
+int
+ice_tx_done_cleanup_simple(struct ice_tx_queue *txq,
+   uint32_t free_cnt)
+{
+   uint16_t i;
+   uint16_t tx_first;
+   uint16_t tx_id;
+   uint32_t pkt_cnt;
+   struct ice_tx_entry *swr_ring = txq->sw_ring;
+
+   /* Start free mbuf from tx_first */
+   tx_first = txq->tx_next_dd - (txq->tx_rs_thresh - 1);
+   tx_id  = tx_first;
+
+   /* while free_cnt is 0,
+* suppose one mbuf per packet,
+* try to free packets as many as possible
+*/
+   if (free_cnt == 0)
+   free_cnt = txq->nb_tx_desc;
+
+   /* Loop through swr_ring to count freeable packets */
+   for (pkt_cnt = 0; pkt_cnt < free_cnt; ) {
+   if (txq->nb_tx_desc - txq->nb_tx_free < txq->tx_rs_thresh)

[dpdk-dev] [PATCH v7 3/4] net/ixgbe: cleanup Tx buffers

[Chenxu Di]

Add support to the ixgbe driver for the API rte_eth_tx_done_cleanup
to force free consumed buffers on Tx ring.

Signed-off-by: Chenxu Di 
---
 drivers/net/ixgbe/ixgbe_ethdev.c |   4 +
 drivers/net/ixgbe/ixgbe_rxtx.c   | 156 ++-
 drivers/net/ixgbe/ixgbe_rxtx.h   |  10 ++
 3 files changed, 169 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 2c6fd0f13..668c36188 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -601,6 +601,7 @@ static const struct eth_dev_ops ixgbe_eth_dev_ops = {
.udp_tunnel_port_add  = ixgbe_dev_udp_tunnel_port_add,
.udp_tunnel_port_del  = ixgbe_dev_udp_tunnel_port_del,
.tm_ops_get   = ixgbe_tm_ops_get,
+   .tx_done_cleanup  = ixgbe_tx_done_cleanup,
 };
 
 /*
@@ -649,6 +650,7 @@ static const struct eth_dev_ops ixgbevf_eth_dev_ops = {
.reta_query   = ixgbe_dev_rss_reta_query,
.rss_hash_update  = ixgbe_dev_rss_hash_update,
.rss_hash_conf_get= ixgbe_dev_rss_hash_conf_get,
+   .tx_done_cleanup  = ixgbe_tx_done_cleanup,
 };
 
 /* store statistics names and its offset in stats structure */
@@ -1101,6 +1103,7 @@ eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev, void 
*init_params __rte_unused)
eth_dev->rx_pkt_burst = &ixgbe_recv_pkts;
eth_dev->tx_pkt_burst = &ixgbe_xmit_pkts;
eth_dev->tx_pkt_prepare = &ixgbe_prep_pkts;
+   ixgbe_set_tx_done_cleanup_func(ixgbe_tx_done_cleanup_scalar);
 
/*
 * For secondary processes, we don't initialise any further as primary
@@ -1580,6 +1583,7 @@ eth_ixgbevf_dev_init(struct rte_eth_dev *eth_dev)
eth_dev->dev_ops = &ixgbevf_eth_dev_ops;
eth_dev->rx_pkt_burst = &ixgbe_recv_pkts;
eth_dev->tx_pkt_burst = &ixgbe_xmit_pkts;
+   ixgbe_set_tx_done_cleanup_func(ixgbe_tx_done_cleanup_scalar);
 
/* for secondary processes, we don't initialise any further as primary
 * has already done this work. Only check we don't need a different
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index fa572d184..122dae425 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -92,6 +92,8 @@ uint16_t ixgbe_xmit_fixed_burst_vec(void *tx_queue, struct 
rte_mbuf **tx_pkts,
uint16_t nb_pkts);
 #endif
 
+static ixgbe_tx_done_cleanup_t ixgbe_tx_done_cleanup_op;
+
 /*
  *
  *  TX functions
@@ -2306,6 +2308,152 @@ ixgbe_tx_queue_release_mbufs(struct ixgbe_tx_queue *txq)
}
 }
 
+int
+ixgbe_tx_done_cleanup_scalar(struct ixgbe_tx_queue *txq, uint32_t free_cnt)
+{
+   uint32_t pkt_cnt;
+   uint16_t i;
+   uint16_t tx_last;
+   uint16_t tx_id;
+   uint16_t nb_tx_to_clean;
+   uint16_t nb_tx_free_last;
+   struct ixgbe_tx_entry *swr_ring = txq->sw_ring;
+
+   /* Start free mbuf from the next of tx_tail */
+   tx_last = txq->tx_tail;
+   tx_id  = swr_ring[tx_last].next_id;
+
+   if (txq->nb_tx_free == 0)
+   if (ixgbe_xmit_cleanup(txq))
+   return 0;
+
+   nb_tx_to_clean = txq->nb_tx_free;
+   nb_tx_free_last = txq->nb_tx_free;
+   if (!free_cnt)
+   free_cnt = txq->nb_tx_desc;
+
+   /* Loop through swr_ring to count the amount of
+* freeable mubfs and packets.
+*/
+   for (pkt_cnt = 0; pkt_cnt < free_cnt; ) {
+   for (i = 0; i < nb_tx_to_clean &&
+   pkt_cnt < free_cnt &&
+   tx_id != tx_last; i++) {
+   if (swr_ring[tx_id].mbuf != NULL) {
+   rte_pktmbuf_free_seg(swr_ring[tx_id].mbuf);
+   swr_ring[tx_id].mbuf = NULL;
+
+   /*
+* last segment in the packet,
+* increment packet count
+*/
+   pkt_cnt += (swr_ring[tx_id].last_id == tx_id);
+   }
+
+   tx_id = swr_ring[tx_id].next_id;
+   }
+
+   if (tx_id == tx_last || txq->tx_rs_thresh
+   > txq->nb_tx_desc - txq->nb_tx_free)
+   break;
+
+   if (pkt_cnt < free_cnt) {
+   if (ixgbe_xmit_cleanup(txq))
+   break;
+
+   nb_tx_to_clean = txq->nb_tx_free - nb_tx_free_last;
+   nb_tx_free_last = txq->nb_tx_free;
+   }
+   }
+
+   PMD_TX_FREE_LOG(DEBUG,
+   "Free %u Packets successfully "
+   "(port=%d queue=%d)",
+   pkt_cnt, txq->port_id, txq->queue_id);
+
+   return (int)pkt_cnt;
+}
+
+int
+ixgbe_tx_done_cleanup_vec(struct ixgbe_tx_queu

[dpdk-dev] [PATCH v7 4/4] net/e1000: cleanup Tx buffers

[Chenxu Di]

Add support to the igb vf for the API rte_eth_tx_done_cleanup
 to force free consumed buffers on Tx ring.

Signed-off-by: Chenxu Di 
---
 drivers/net/e1000/igb_ethdev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index a3e30dbe5..647d5504f 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -446,6 +446,7 @@ static const struct eth_dev_ops igbvf_eth_dev_ops = {
.tx_descriptor_status = eth_igb_tx_descriptor_status,
.tx_queue_setup   = eth_igb_tx_queue_setup,
.tx_queue_release = eth_igb_tx_queue_release,
+   .tx_done_cleanup  = eth_igb_tx_done_cleanup,
.set_mc_addr_list = eth_igb_set_mc_addr_list,
.rxq_info_get = igb_rxq_info_get,
.txq_info_get = igb_txq_info_get,
-- 
2.17.1

Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device drivers

[Maxime Coquelin]

On 1/9/20 10:49 AM, Xu, Rosen wrote:
> 
> 
>> -Original Message-
>> From: Maxime Coquelin 
>> Sent: Thursday, January 09, 2020 17:24
>> To: Thomas Monjalon ; Xu, Rosen
>> 
>> Cc: Matan Azrad ; Bie, Tiwei ;
>> Wang, Zhihong ; Wang, Xiao W
>> ; Yigit, Ferruh ;
>> dev@dpdk.org; Pei, Andy 
>> Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device
>> drivers
>>
>>
>>
>> On 1/9/20 9:41 AM, Thomas Monjalon wrote:
>>> 09/01/2020 03:27, Xu, Rosen:
 Hi,

 From: Thomas Monjalon 
> 08/01/2020 13:39, Xu, Rosen:
>> From: Matan Azrad 
>>> From: Xu, Rosen
 Did you think about OVS DPDK?
 vDPA is a basic module for OVS, currently it will take some
 exception path packet processing for OVS, so it still needs to
 integrate
> eth_dev.
>>>
>>> I don't understand your question.
>>>
>>> What do you mean by "integrate eth_dev"?
>>
>> My questions is in OVS DPDK scenario vDPA device implements eth_dev
>> ops, so create a new class and move ifc code to this new class is not ok.
>
> 1/ I don't understand the relation with OVS.
>
> 2/ no, vDPA device implements vDPA ops.
> If it implements ethdev ops, it is an ethdev device.
>
> Please show an example of what you claim.

 Answers of 1 and 2.

 In OVS DPDK, each network device(such as NIC, vHost etc) of DPDK
 needs to be implemented as rte_eth_dev and provides eth_dev_ops such
>> as packet TX/RX for OVS.
>>>
>>> No, OVS is also using the vhost API for vhost port.
>>>
 Take vHost(Virtio back end) for example, OVS startups vHost interface like
>> this:
 ovs-vsctl add-port br0 vhost-user-1 -- set Interface vhost-user-1
 type=dpdkvhostuser drivers/net/vhost implements vHost as rte_eth_dev
>> and integrated in OVS.
 OVS can send/receive packets to/from VM with rte_eth_tx_burst()
 rte_eth_rx_burst() which call eth_dev_ops implementation of
>> drivers/net/vhost.
>>>
>>> No, it is using rte_vhost_dequeue_burst() and
>>> rte_vhost_enqueue_burst() which are not in ethdev.
>>>
 vDPA is also Virtio back end and works like vHost, same as vHost, it
 will be implemented as rte_eth_dev and also be integrated into OVS.
>>>
>>> No, vDPA is not "implemented as rte_eth_dev".
>>>
 So, it's not ok to move ifc code from drivers/net.
>>>
>>> drivers/net/ifc has no ethdev implementation at all.
>>>
>>>
>>> Rosen, I'm sorry, these arguments look irrelevant, so I won't consider
>>> them as blocking the integration of this patch.
>>>
>>>
>>
>> I agree with Thomas, the vDPA drivers do not implement the ethdev ops.
> 
> For OVS hasn't integrated vDPA, it doesn't implement ethdev ops, but there 
> are many
> discussions in OVS community about vDPA, it seems vDPA will be supported in 
> OVS in
> the near feature.

I agree with this statement, but if you look at Mellanox series being
reviewed, it is defining a new type of port and not use the regular DPDK
port type.

>> And OVS does not use the Vhost PMD for the Vhost-user ports, but directly
>> call the librte_vhost APIs.
> 
> I'm afraid you are wrong, pls read these documents which introduce how to use 
> vHost-user PMD in OVS:
> http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/
> http://docs.openvswitch.org/en/latest/topics/dpdk/pmd/

I can confirm that below command to add ports is not using Vhost PMD but
directly the  librte_vhost API:

$ ovs-vsctl add-port br0 dpdkvhostclient0 \
-- set Interface dpdkvhostclient0 type=dpdkvhostuserclient \
   options:vhost-server-path=/tmp/dpdkvhostclient0

Please check the OVS source code.

It is possible  to use the Vhost PMD as a regular DPDK port, but this is
not with above command, and not the recommended way.

>> Regards,
>> Maxime
> 

Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device drivers

[Maxime Coquelin]

On 1/9/20 10:49 AM, Xu, Rosen wrote:
> 
> 
>> -Original Message-
>> From: Maxime Coquelin 
>> Sent: Thursday, January 09, 2020 17:24
>> To: Thomas Monjalon ; Xu, Rosen
>> 
>> Cc: Matan Azrad ; Bie, Tiwei ;
>> Wang, Zhihong ; Wang, Xiao W
>> ; Yigit, Ferruh ;
>> dev@dpdk.org; Pei, Andy 
>> Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device
>> drivers
>>
>>
>>
>> On 1/9/20 9:41 AM, Thomas Monjalon wrote:
>>> 09/01/2020 03:27, Xu, Rosen:
 Hi,

 From: Thomas Monjalon 
> 08/01/2020 13:39, Xu, Rosen:
>> From: Matan Azrad 
>>> From: Xu, Rosen
 Did you think about OVS DPDK?
 vDPA is a basic module for OVS, currently it will take some
 exception path packet processing for OVS, so it still needs to
 integrate
> eth_dev.
>>>
>>> I don't understand your question.
>>>
>>> What do you mean by "integrate eth_dev"?
>>
>> My questions is in OVS DPDK scenario vDPA device implements eth_dev
>> ops, so create a new class and move ifc code to this new class is not ok.
>
> 1/ I don't understand the relation with OVS.
>
> 2/ no, vDPA device implements vDPA ops.
> If it implements ethdev ops, it is an ethdev device.
>
> Please show an example of what you claim.

 Answers of 1 and 2.

 In OVS DPDK, each network device(such as NIC, vHost etc) of DPDK
 needs to be implemented as rte_eth_dev and provides eth_dev_ops such
>> as packet TX/RX for OVS.
>>>
>>> No, OVS is also using the vhost API for vhost port.
>>>
 Take vHost(Virtio back end) for example, OVS startups vHost interface like
>> this:
 ovs-vsctl add-port br0 vhost-user-1 -- set Interface vhost-user-1
 type=dpdkvhostuser drivers/net/vhost implements vHost as rte_eth_dev
>> and integrated in OVS.
 OVS can send/receive packets to/from VM with rte_eth_tx_burst()
 rte_eth_rx_burst() which call eth_dev_ops implementation of
>> drivers/net/vhost.
>>>
>>> No, it is using rte_vhost_dequeue_burst() and
>>> rte_vhost_enqueue_burst() which are not in ethdev.
>>>
 vDPA is also Virtio back end and works like vHost, same as vHost, it
 will be implemented as rte_eth_dev and also be integrated into OVS.
>>>
>>> No, vDPA is not "implemented as rte_eth_dev".
>>>
 So, it's not ok to move ifc code from drivers/net.
>>>
>>> drivers/net/ifc has no ethdev implementation at all.
>>>
>>>
>>> Rosen, I'm sorry, these arguments look irrelevant, so I won't consider
>>> them as blocking the integration of this patch.
>>>
>>>
>>
>> I agree with Thomas, the vDPA drivers do not implement the ethdev ops.
> 
> For OVS hasn't integrated vDPA, it doesn't implement ethdev ops, but there 
> are many
> discussions in OVS community about vDPA, it seems vDPA will be supported in 
> OVS in
> the near feature.

I agree with this statement, but if you look at Mellanox series being
reviewed, it is defining a new type of port and not use the regular DPDK
port type.

>> And OVS does not use the Vhost PMD for the Vhost-user ports, but directly
>> call the librte_vhost APIs.
> 
> I'm afraid you are wrong, pls read these documents which introduce how to use 
> vHost-user PMD in OVS:
> http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/
> http://docs.openvswitch.org/en/latest/topics/dpdk/pmd/

I can confirm that below command to add ports is not using Vhost PMD but
directly the  librte_vhost API:

$ ovs-vsctl add-port br0 dpdkvhostclient0 \
-- set Interface dpdkvhostclient0 type=dpdkvhostuserclient \
   options:vhost-server-path=/tmp/dpdkvhostclient0

Please check the OVS source code.

It is possible  to use the Vhost PMD as a regular DPDK port, but this is
not with above command, and not the recommended way.

>> Regards,
>> Maxime
> 

Re: [dpdk-dev] [dpdk-stable] [PATCH] net/mlx5: fix ConnectX-4LX Tx burst routines set

[Ferruh Yigit]

On 1/9/2020 9:03 AM, Slava Ovsiienko wrote:
>> -Original Message-
>> From: Ferruh Yigit 
>> Sent: Wednesday, January 8, 2020 17:55
>> To: Slava Ovsiienko ; dev@dpdk.org
>> Cc: Matan Azrad ; Raslan Darawsheh
>> ; Ori Kam ; sta...@dpdk.org;
>> Thomas Monjalon 
>> Subject: Re: [dpdk-stable] [PATCH] net/mlx5: fix ConnectX-4LX Tx burst
>> routines set
>>
>> On 1/8/2020 3:50 PM, Slava Ovsiienko wrote:
>>> Hi, Ferruh
>>>
 -Original Message-
 From: Ferruh Yigit 
 Sent: Wednesday, January 8, 2020 16:55
 To: Slava Ovsiienko ; dev@dpdk.org
 Cc: Matan Azrad ; Raslan Darawsheh
 ; Ori Kam ;
 sta...@dpdk.org; Thomas Monjalon 
 Subject: Re: [dpdk-stable] [PATCH] net/mlx5: fix ConnectX-4LX Tx
 burst routines set

 On 1/8/2020 2:53 PM, Ferruh Yigit wrote:
> On 12/20/2019 10:48 AM, Viacheslav Ovsiienko wrote:
>> The tx_burst routine supporting multi-segment packets with legacy
>> MPW and without inline was missed, and there was no valid selection
>> for these options, patch adds the missing routine.
>>
>> Fixes: 82e75f8323bf ("net/mlx5: fix legacy multi-packet Tx
>> descriptors")
>> Cc: sta...@dpdk.org
>>
>> Signed-off-by: Viacheslav Ovsiienko 
>>
>> <...>
>>
>> @@ -5297,6 +5305,7 @@ enum mlx5_txcmp_code {
>>  DRV_LOG(DEBUG, "port %u has no selected Tx function"
>> " for requested offloads %04X",
>>  dev->data->port_id, olx);
>> +assert(false);
>>
>> <...>
>>
>>>

>
> I think we should avoid PMDs calling the assert unconditionally,
> specially in a code that debug level log is printed.
>
>>  return NULL;
>>  }
>>  DRV_LOG(DEBUG, "port %u has selected Tx function"
>>>
>>> Yes, I agree. We just do not have the check for the result returned by
>>> mlx5_select_tx_function(). I think we should check against NULL and
>>> report an error.  "assert" is a temporary solution till this upgrade
>>> (in debug mode we have a lot of messages and break on assert helps to
>>> locate the problem quickly, reporting error will do the same).
>>>
>>
>> Can it be possible to drop the patch from mlx tree and prepare a new version
>> without 'assert'?
> The selection routine error handling is rather generic and is not merely 
> related to ConnectX-4LX.
> I propose to prepare the dedicated patch, what do you  think?
> 

My concern is with the assert, the error handling can be another patch, but can
we have this change without an assert? Or perhaps a RTE_ASSERT() which is for 
debug.

Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device drivers

[Xu, Rosen]

> -Original Message-
> From: Thomas Monjalon 
> Sent: Thursday, January 09, 2020 16:41
> To: Xu, Rosen 
> Cc: Matan Azrad ; Maxime Coquelin
> ; Bie, Tiwei ; Wang,
> Zhihong ; Wang, Xiao W
> ; Yigit, Ferruh ;
> dev@dpdk.org; Pei, Andy 
> Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device
> drivers
> 
> 09/01/2020 03:27, Xu, Rosen:
> > Hi,
> >
> > From: Thomas Monjalon 
> > > 08/01/2020 13:39, Xu, Rosen:
> > > > From: Matan Azrad 
> > > > > From: Xu, Rosen
> > > > > > Did you think about OVS DPDK?
> > > > > > vDPA is a basic module for OVS, currently it will take some
> > > > > > exception path packet processing for OVS, so it still needs to
> > > > > > integrate
> > > eth_dev.
> > > > >
> > > > > I don't understand your question.
> > > > >
> > > > > What do you mean by "integrate eth_dev"?
> > > >
> > > > My questions is in OVS DPDK scenario vDPA device implements
> > > > eth_dev ops, so create a new class and move ifc code to this new class
> is not ok.
> > >
> > > 1/ I don't understand the relation with OVS.
> > >
> > > 2/ no, vDPA device implements vDPA ops.
> > > If it implements ethdev ops, it is an ethdev device.
> > >
> > > Please show an example of what you claim.
> >
> > Answers of 1 and 2.
> >
> > In OVS DPDK, each network device(such as NIC, vHost etc) of DPDK needs
> > to be implemented as rte_eth_dev and provides eth_dev_ops such as
> packet TX/RX for OVS.
> 
> No, OVS is also using the vhost API for vhost port.

Yes, vhost pmd is not a good example.

> > Take vHost(Virtio back end) for example, OVS startups vHost interface like
> this:
> > ovs-vsctl add-port br0 vhost-user-1 -- set Interface vhost-user-1
> > type=dpdkvhostuser drivers/net/vhost implements vHost as rte_eth_dev
> and integrated in OVS.
> > OVS can send/receive packets to/from VM with rte_eth_tx_burst()
> > rte_eth_rx_burst() which call eth_dev_ops implementation of
> drivers/net/vhost.
>
> No, it is using rte_vhost_dequeue_burst() and rte_vhost_enqueue_burst()
> which are not in ethdev.
>
> > vDPA is also Virtio back end and works like vHost, same as vHost, it
> > will be implemented as rte_eth_dev and also be integrated into OVS.
> 
> No, vDPA is not "implemented as rte_eth_dev".

Currently, vDPA isn't integrated with OVS.
 
> > So, it's not ok to move ifc code from drivers/net.
> 
> drivers/net/ifc has no ethdev implementation at all.

For OVS hasn't integrated vDPA, it doesn't implement rte_eth_dev,
but there are many discussions in OVS community about vDPA,
some are from Mellanox, it seems vDPA port will be implemented
as rte_eth_dev port in OVS in the near feature.
https://patchwork.ozlabs.org/patch/1178474/

Matan,
Could you clarify how OVS integrates vDPA in Mellanox patch?

> 
> Rosen, I'm sorry, these arguments look irrelevant, so I won't consider them
> as blocking the integration of this patch.

What I mentioned is not blocking the integration of this patch, I just want to 
get
clarification from Matan how to integrate vDPA port in OVS.

[dpdk-dev] [PATCH v2 1/4] net/mlx5: move Tx complete request routine

[Viacheslav Ovsiienko]

The complete request flag is set once per Tx burst call,
the code of appropriate routine moved to the end of sending
loop. This is preparation step to remove WQE reserved field
usage to store index of elts to free.

Signed-off-by: Viacheslav Ovsiienko 
Acked-by: Matan Azrad 
---
 drivers/net/mlx5/mlx5_rxtx.c | 26 --
 1 file changed, 4 insertions(+), 22 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index 25a2952..ee6d5fc 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -2145,9 +2145,6 @@ enum mlx5_txcmp_code {
  *   Pointer to TX queue structure.
  * @param loc
  *   Pointer to burst routine local context.
- * @param multi,
- *   Routine is called from multi-segment sending loop,
- *   do not correct the elts_head according to the pkts_copy.
  * @param olx
  *   Configured Tx offloads mask. It is fully defined at
  *   compile time and may be used for optimization.
@@ -2155,13 +2152,12 @@ enum mlx5_txcmp_code {
 static __rte_always_inline void
 mlx5_tx_request_completion(struct mlx5_txq_data *restrict txq,
   struct mlx5_txq_local *restrict loc,
-  bool multi,
   unsigned int olx)
 {
uint16_t head = txq->elts_head;
unsigned int part;
 
-   part = (MLX5_TXOFF_CONFIG(INLINE) || multi) ?
+   part = MLX5_TXOFF_CONFIG(INLINE) ?
   0 : loc->pkts_sent - loc->pkts_copy;
head += part;
if ((uint16_t)(head - txq->elts_comp) >= MLX5_TX_COMP_THRESH ||
@@ -3120,8 +3116,6 @@ enum mlx5_txcmp_code {
wqe->cseg.sq_ds = rte_cpu_to_be_32(txq->qp_num_8s | ds);
txq->wqe_ci += (ds + 3) / 4;
loc->wqe_free -= (ds + 3) / 4;
-   /* Request CQE generation if limits are reached. */
-   mlx5_tx_request_completion(txq, loc, true, olx);
return MLX5_TXCMP_CODE_MULTI;
 }
 
@@ -3230,8 +3224,6 @@ enum mlx5_txcmp_code {
} while (true);
txq->wqe_ci += (ds + 3) / 4;
loc->wqe_free -= (ds + 3) / 4;
-   /* Request CQE generation if limits are reached. */
-   mlx5_tx_request_completion(txq, loc, true, olx);
return MLX5_TXCMP_CODE_MULTI;
 }
 
@@ -3388,8 +3380,6 @@ enum mlx5_txcmp_code {
wqe->cseg.sq_ds = rte_cpu_to_be_32(txq->qp_num_8s | ds);
txq->wqe_ci += (ds + 3) / 4;
loc->wqe_free -= (ds + 3) / 4;
-   /* Request CQE generation if limits are reached. */
-   mlx5_tx_request_completion(txq, loc, true, olx);
return MLX5_TXCMP_CODE_MULTI;
 }
 
@@ -3599,8 +3589,6 @@ enum mlx5_txcmp_code {
--loc->elts_free;
++loc->pkts_sent;
--pkts_n;
-   /* Request CQE generation if limits are reached. */
-   mlx5_tx_request_completion(txq, loc, false, olx);
if (unlikely(!pkts_n || !loc->elts_free || !loc->wqe_free))
return MLX5_TXCMP_CODE_EXIT;
loc->mbuf = *pkts++;
@@ -3750,7 +3738,7 @@ enum mlx5_txcmp_code {
   struct mlx5_txq_local *restrict loc,
   unsigned int ds,
   unsigned int slen,
-  unsigned int olx)
+  unsigned int olx __rte_unused)
 {
assert(!MLX5_TXOFF_CONFIG(INLINE));
 #ifdef MLX5_PMD_SOFT_COUNTERS
@@ -3765,8 +3753,6 @@ enum mlx5_txcmp_code {
loc->wqe_last->cseg.sq_ds = rte_cpu_to_be_32(txq->qp_num_8s | ds);
txq->wqe_ci += (ds + 3) / 4;
loc->wqe_free -= (ds + 3) / 4;
-   /* Request CQE generation if limits are reached. */
-   mlx5_tx_request_completion(txq, loc, false, olx);
 }
 
 /*
@@ -3809,8 +3795,6 @@ enum mlx5_txcmp_code {
loc->wqe_last->cseg.sq_ds = rte_cpu_to_be_32(txq->qp_num_8s | len);
txq->wqe_ci += (len + 3) / 4;
loc->wqe_free -= (len + 3) / 4;
-   /* Request CQE generation if limits are reached. */
-   mlx5_tx_request_completion(txq, loc, false, olx);
 }
 
 /**
@@ -4011,8 +3995,6 @@ enum mlx5_txcmp_code {
txq->wqe_ci += (2 + part + 3) / 4;
loc->wqe_free -= (2 + part + 3) / 4;
pkts_n -= part;
-   /* Request CQE generation if limits are reached. */
-   mlx5_tx_request_completion(txq, loc, false, olx);
if (unlikely(!pkts_n || !loc->elts_free || !loc->wqe_free))
return MLX5_TXCMP_CODE_EXIT;
loc->mbuf = *pkts++;
@@ -4496,8 +4478,6 @@ enum mlx5_txcmp_code {
}
++loc->pkts_sent;
--pkts_n;
-   /* Request CQE generation if limits are reached. */
-   mlx5_tx_request_completion(txq, loc, false, olx);
if (unlikely(!pkts_n || !loc->elts_free || !loc->wqe_free))
return MLX5_TXCMP_CODE_EXIT;
loc->mbuf = *pkts++;
@@ -4776,6 +4756,8 @@ enum mlx5_txcmp_code {
/* Take a shortcut if nothing is sen

[dpdk-dev] [PATCH v2 0/4] net/mlx5: remove Tx descriptor reserved field usage

[Viacheslav Ovsiienko]

The current Tx datapath implementation in mlx5 PMD uses the
16-bit reserved field within transmit descriptor to store
the indices of the elts array keeping the mbuf pointers to be
freed on transmit completion. On completion PMD fetches the
descriptor index, then fetches the elts array index from
reserved field and frees the mbufs.

The new ConnectX-6DX NIC might use this reserved descriptor
field and existing implementation might not work in intended way.
To resolve this issue the dedicated buffer is introduced to
store indices to instead of descriptor field.

Signed-off-by: Viacheslav Ovsiienko 

Viacheslav Ovsiienko (4):
  net/mlx5: move Tx complete request routine
  net/mlx5: update Tx error handling routine
  net/mlx5: add free on completion queue
  net/mlx5: engage free on completion queue

 drivers/net/mlx5/mlx5_rxtx.c | 153 ---
 drivers/net/mlx5/mlx5_rxtx.h |  13 ++--
 drivers/net/mlx5/mlx5_txq.c  |  19 +-
 3 files changed, 94 insertions(+), 91 deletions(-)

--
v1: http://patches.dpdk.org/cover/64293/
v2: resolve minor compilation per patch issues

1.8.3.1

[dpdk-dev] [PATCH v2 3/4] net/mlx5: add free on completion queue

[Viacheslav Ovsiienko]

The new software manged entity is introduced in Tx datapath
- free on completion queue. This queue keeps the information
how many buffers stored in elts array must freed on send
comletion. Each element of the queue contains transmitting
descriptor index to be in synch with completion entries (in
debug build only) and the index in elts array to free buffers.

Signed-off-by: Viacheslav Ovsiienko 
Acked-by: Matan Azrad 
---
 drivers/net/mlx5/mlx5_rxtx.h |  5 +
 drivers/net/mlx5/mlx5_txq.c  | 15 +++
 2 files changed, 20 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_rxtx.h b/drivers/net/mlx5/mlx5_rxtx.h
index 8a2185a..ee1895b 100644
--- a/drivers/net/mlx5/mlx5_rxtx.h
+++ b/drivers/net/mlx5/mlx5_rxtx.h
@@ -297,6 +297,11 @@ struct mlx5_txq_data {
struct mlx5_mr_ctrl mr_ctrl; /* MR control descriptor. */
struct mlx5_wqe *wqes; /* Work queue. */
struct mlx5_wqe *wqes_end; /* Work queue array limit. */
+#ifdef NDEBUG
+   uint32_t *fcqs; /* Free completion queue. */
+#else
+   uint32_t *fcqs; /* Free completion queue (debug extended). */
+#endif
volatile struct mlx5_cqe *cqes; /* Completion queue. */
volatile uint32_t *qp_db; /* Work queue doorbell. */
volatile uint32_t *cq_db; /* Completion queue doorbell. */
diff --git a/drivers/net/mlx5/mlx5_txq.c b/drivers/net/mlx5/mlx5_txq.c
index abe0947..aee0970 100644
--- a/drivers/net/mlx5/mlx5_txq.c
+++ b/drivers/net/mlx5/mlx5_txq.c
@@ -724,6 +724,17 @@ struct mlx5_txq_obj *
txq_data->wqe_pi = 0;
txq_data->wqe_comp = 0;
txq_data->wqe_thres = txq_data->wqe_s / MLX5_TX_COMP_THRESH_INLINE_DIV;
+   txq_data->fcqs = rte_calloc_socket(__func__,
+  txq_data->cqe_s,
+  sizeof(*txq_data->fcqs),
+  RTE_CACHE_LINE_SIZE,
+  txq_ctrl->socket);
+   if (!txq_data->fcqs) {
+   DRV_LOG(ERR, "port %u Tx queue %u cannot allocate memory (FCQ)",
+   dev->data->port_id, idx);
+   rte_errno = ENOMEM;
+   goto error;
+   }
 #ifdef HAVE_IBV_FLOW_DV_SUPPORT
/*
 * If using DevX need to query and store TIS transport domain value.
@@ -772,6 +783,8 @@ struct mlx5_txq_obj *
claim_zero(mlx5_glue->destroy_cq(tmpl.cq));
if (tmpl.qp)
claim_zero(mlx5_glue->destroy_qp(tmpl.qp));
+   if (txq_data && txq_data->fcqs)
+   rte_free(txq_data->fcqs);
if (txq_obj)
rte_free(txq_obj);
priv->verbs_alloc_ctx.type = MLX5_VERBS_ALLOC_TYPE_NONE;
@@ -826,6 +839,8 @@ struct mlx5_txq_obj *
} else {
claim_zero(mlx5_glue->destroy_qp(txq_obj->qp));
claim_zero(mlx5_glue->destroy_cq(txq_obj->cq));
+   if (txq_obj->txq_ctrl->txq.fcqs)
+   rte_free(txq_obj->txq_ctrl->txq.fcqs);
}
LIST_REMOVE(txq_obj, next);
rte_free(txq_obj);
-- 
1.8.3.1

[dpdk-dev] [PATCH v2 4/4] net/mlx5: engage free on completion queue

[Viacheslav Ovsiienko]

The free on completion queue keeps the indices of elts array,
all mbuf stored below this index should be freed on arrival
of normal send completion. In debug version it also contains
an index of completed transmitting descriptor (WQE) to check
queues synchronization.

Signed-off-by: Viacheslav Ovsiienko 
Acked-by: Matan Azrad 
---
 drivers/net/mlx5/mlx5_rxtx.c | 33 +
 drivers/net/mlx5/mlx5_rxtx.h |  6 ++
 drivers/net/mlx5/mlx5_txq.c  |  2 --
 3 files changed, 19 insertions(+), 22 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index b7b40ac..b11c5eb 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -2043,8 +2043,7 @@ enum mlx5_txcmp_code {
uint16_t tail;
 
txq->wqe_pi = rte_be_to_cpu_16(last_cqe->wqe_counter);
-   tail = ((volatile struct mlx5_wqe_cseg *)
-   (txq->wqes + (txq->wqe_pi & txq->wqe_m)))->misc;
+   tail = txq->fcqs[(txq->cq_ci - 1) & txq->cqe_m];
if (likely(tail != txq->elts_tail)) {
mlx5_tx_free_elts(txq, tail, olx);
assert(tail == txq->elts_tail);
@@ -2095,6 +2094,7 @@ enum mlx5_txcmp_code {
 * here, before we might perform SQ reset.
 */
rte_wmb();
+   txq->cq_ci = ci;
ret = mlx5_tx_error_cqe_handle
(txq, (volatile struct mlx5_err_cqe *)cqe);
if (unlikely(ret < 0)) {
@@ -2108,17 +2108,18 @@ enum mlx5_txcmp_code {
/*
 * We are going to fetch all entries with
 * MLX5_CQE_SYNDROME_WR_FLUSH_ERR status.
+* The send queue is supposed to be empty.
 */
++ci;
+   txq->cq_pi = ci;
+   last_cqe = NULL;
continue;
}
/* Normal transmit completion. */
+   assert(ci != txq->cq_pi);
+   assert((txq->fcqs[ci & txq->cqe_m] >> 16) == cqe->wqe_counter);
++ci;
last_cqe = cqe;
-#ifndef NDEBUG
-   if (txq->cq_pi)
-   --txq->cq_pi;
-#endif
/*
 * We have to restrict the amount of processed CQEs
 * in one tx_burst routine call. The CQ may be large
@@ -2127,7 +2128,7 @@ enum mlx5_txcmp_code {
 * multiple iterations may introduce significant
 * latency.
 */
-   if (--count == 0)
+   if (likely(--count == 0))
break;
} while (true);
if (likely(ci != txq->cq_ci)) {
@@ -2177,15 +2178,15 @@ enum mlx5_txcmp_code {
/* Request unconditional completion on last WQE. */
last->cseg.flags = RTE_BE32(MLX5_COMP_ALWAYS <<
MLX5_COMP_MODE_OFFSET);
-   /* Save elts_head in unused "immediate" field of WQE. */
-   last->cseg.misc = head;
-   /*
-* A CQE slot must always be available. Count the
-* issued CEQ "always" request instead of production
-* index due to here can be CQE with errors and
-* difference with ci may become inconsistent.
-*/
-   assert(txq->cqe_s > ++txq->cq_pi);
+   /* Save elts_head in dedicated free on completion queue. */
+#ifdef NDEBUG
+   txq->fcqs[txq->cq_pi++ & txq->cqe_m] = head;
+#else
+   txq->fcqs[txq->cq_pi++ & txq->cqe_m] = head |
+   (last->cseg.opcode >> 8) << 16;
+#endif
+   /* A CQE slot must always be available. */
+   assert((txq->cq_pi - txq->cq_ci) <= txq->cqe_s);
}
 }
 
diff --git a/drivers/net/mlx5/mlx5_rxtx.h b/drivers/net/mlx5/mlx5_rxtx.h
index ee1895b..e362b4a 100644
--- a/drivers/net/mlx5/mlx5_rxtx.h
+++ b/drivers/net/mlx5/mlx5_rxtx.h
@@ -273,9 +273,7 @@ struct mlx5_txq_data {
uint16_t wqe_thres; /* WQE threshold to request completion in CQ. */
/* WQ related fields. */
uint16_t cq_ci; /* Consumer index for completion queue. */
-#ifndef NDEBUG
-   uint16_t cq_pi; /* Counter of issued CQE "always" requests. */
-#endif
+   uint16_t cq_pi; /* Production index for completion queue. */
uint16_t cqe_s; /* Number of CQ elements. */
uint16_t cqe_m; /* Mask for CQ indices. */
/* CQ related fields. */
@@ -298,7 +296,7 @@ struct mlx5_txq_data {
struct mlx5_wqe *wqes; /* Work queue. */
struct mlx5_wqe *wqes_end; /* Work queue array limit. */
 #ifdef NDEBUG
-   uint32_t *fcqs; /* Free completion queue. */
+   uint16_t *fcqs; /* Free completi

[dpdk-dev] [PATCH v2 2/4] net/mlx5: update Tx error handling routine

[Viacheslav Ovsiienko]

This is preparation step, we are going to store the index
of elts to free on completion in the dedicated free on
completion queue, this patch updates the elts freeing routine
and updates Tx error handling routine to be synched with
coming new queue.

Signed-off-by: Viacheslav Ovsiienko 
Acked-by: Matan Azrad 
---
 drivers/net/mlx5/mlx5_rxtx.c | 98 +++-
 drivers/net/mlx5/mlx5_rxtx.h |  4 +-
 drivers/net/mlx5/mlx5_txq.c  |  2 +-
 3 files changed, 54 insertions(+), 50 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index ee6d5fc..b7b40ac 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -654,10 +654,10 @@ enum mlx5_txcmp_code {
  *   Pointer to the error CQE.
  *
  * @return
- *   Negative value if queue recovery failed,
- *   the last Tx buffer element to free otherwise.
+ *   Negative value if queue recovery failed, otherwise
+ *   the error completion entry is handled successfully.
  */
-int
+static int
 mlx5_tx_error_cqe_handle(struct mlx5_txq_data *restrict txq,
 volatile struct mlx5_err_cqe *err_cqe)
 {
@@ -701,18 +701,14 @@ enum mlx5_txcmp_code {
 */
txq->stats.oerrors += ((txq->wqe_ci & wqe_m) -
new_wqe_pi) & wqe_m;
-   if (tx_recover_qp(txq_ctrl) == 0) {
-   txq->cq_ci++;
-   /* Release all the remaining buffers. */
-   return txq->elts_head;
+   if (tx_recover_qp(txq_ctrl)) {
+   /* Recovering failed - retry later on the same WQE. */
+   return -1;
}
-   /* Recovering failed - try again later on the same WQE. */
-   return -1;
-   } else {
-   txq->cq_ci++;
+   /* Release all the remaining buffers. */
+   txq_free_elts(txq_ctrl);
}
-   /* Do not release buffers. */
-   return txq->elts_tail;
+   return 0;
 }
 
 /**
@@ -2034,8 +2030,6 @@ enum mlx5_txcmp_code {
  *   Pointer to TX queue structure.
  * @param valid CQE pointer
  *   if not NULL update txq->wqe_pi and flush the buffers
- * @param itail
- *   if not negative - flush the buffers till this index.
  * @param olx
  *   Configured Tx offloads mask. It is fully defined at
  *   compile time and may be used for optimization.
@@ -2043,25 +2037,18 @@ enum mlx5_txcmp_code {
 static __rte_always_inline void
 mlx5_tx_comp_flush(struct mlx5_txq_data *restrict txq,
   volatile struct mlx5_cqe *last_cqe,
-  int itail,
   unsigned int olx __rte_unused)
 {
-   uint16_t tail;
-
if (likely(last_cqe != NULL)) {
+   uint16_t tail;
+
txq->wqe_pi = rte_be_to_cpu_16(last_cqe->wqe_counter);
tail = ((volatile struct mlx5_wqe_cseg *)
(txq->wqes + (txq->wqe_pi & txq->wqe_m)))->misc;
-   } else if (itail >= 0) {
-   tail = (uint16_t)itail;
-   } else {
-   return;
-   }
-   rte_compiler_barrier();
-   *txq->cq_db = rte_cpu_to_be_32(txq->cq_ci);
-   if (likely(tail != txq->elts_tail)) {
-   mlx5_tx_free_elts(txq, tail, olx);
-   assert(tail == txq->elts_tail);
+   if (likely(tail != txq->elts_tail)) {
+   mlx5_tx_free_elts(txq, tail, olx);
+   assert(tail == txq->elts_tail);
+   }
}
 }
 
@@ -2085,6 +2072,7 @@ enum mlx5_txcmp_code {
 {
unsigned int count = MLX5_TX_COMP_MAX_CQE;
volatile struct mlx5_cqe *last_cqe = NULL;
+   uint16_t ci = txq->cq_ci;
int ret;
 
static_assert(MLX5_CQE_STATUS_HW_OWN < 0, "Must be negative value");
@@ -2092,8 +2080,8 @@ enum mlx5_txcmp_code {
do {
volatile struct mlx5_cqe *cqe;
 
-   cqe = &txq->cqes[txq->cq_ci & txq->cqe_m];
-   ret = check_cqe(cqe, txq->cqe_s, txq->cq_ci);
+   cqe = &txq->cqes[ci & txq->cqe_m];
+   ret = check_cqe(cqe, txq->cqe_s, ci);
if (unlikely(ret != MLX5_CQE_STATUS_SW_OWN)) {
if (likely(ret != MLX5_CQE_STATUS_ERR)) {
/* No new CQEs in completion queue. */
@@ -2109,31 +2097,49 @@ enum mlx5_txcmp_code {
rte_wmb();
ret = mlx5_tx_error_cqe_handle
(txq, (volatile struct mlx5_err_cqe *)cqe);
+   if (unlikely(ret < 0)) {
+   /*
+* Some error occurred on queue error
+* handling, we do not advance the index
+* here, allowing to retry on next call.
+*/
+   r

[dpdk-dev] [PATCH v2 0/3] Introduce new class for vDPA device drivers

[Matan Azrad]

As discussed and as described in RFC "[RFC] net: new vdpa PMD for Mellanox 
devices", new vDPA driver is going to be added for Mellanox devices - vDPA mlx5 
and more.

The only vDPA driver now is the IFC driver that is located in net directory.

The IFC driver and the new vDPA mlx5 driver provide the vDPA ops introduced in 
librte_vhost and not the eth-dev ops.
All the others drivers in net class provide the eth-dev ops.
The set of features is also different.

Create a new class for vDPA drivers and move IFC to this class.
Later, all the new drivers that implement the vDPA ops will be added to the 
vDPA class.

Also, a vDPA device driver features list was added to vDPA documentation.

Please review the features list and the series.

Later on, I'm going to send the vDPA mlx5 driver.

Thanks.

v2:
Apply comments from Maxime Coquelin, Andrew Rybchenko and Tiwei Bie.


Matan Azrad (3):
  drivers: introduce vDPA class
  doc: add vDPA feature table
  drivers: move ifc driver to the vDPA class

 MAINTAINERS   |   19 +-
 doc/guides/conf.py|5 +
 doc/guides/index.rst  |1 +
 doc/guides/nics/features/ifcvf.ini|8 -
 doc/guides/nics/ifc.rst   |  106 ---
 doc/guides/nics/index.rst |1 -
 doc/guides/vdpadevs/features/default.ini  |   50 ++
 doc/guides/vdpadevs/features/ifcvf.ini|8 +
 doc/guides/vdpadevs/features_overview.rst |   74 ++
 doc/guides/vdpadevs/ifc.rst   |  106 +++
 doc/guides/vdpadevs/index.rst |   15 +
 drivers/Makefile  |2 +
 drivers/meson.build   |1 +
 drivers/net/Makefile  |3 -
 drivers/net/ifc/Makefile  |   34 -
 drivers/net/ifc/base/ifcvf.c  |  329 
 drivers/net/ifc/base/ifcvf.h  |  162 
 drivers/net/ifc/base/ifcvf_osdep.h|   52 --
 drivers/net/ifc/ifcvf_vdpa.c  | 1280 -
 drivers/net/ifc/meson.build   |9 -
 drivers/net/ifc/rte_pmd_ifc_version.map   |3 -
 drivers/net/meson.build   |1 -
 drivers/vdpa/Makefile |   14 +
 drivers/vdpa/ifc/Makefile |   34 +
 drivers/vdpa/ifc/base/ifcvf.c |  329 
 drivers/vdpa/ifc/base/ifcvf.h |  162 
 drivers/vdpa/ifc/base/ifcvf_osdep.h   |   52 ++
 drivers/vdpa/ifc/ifcvf_vdpa.c | 1280 +
 drivers/vdpa/ifc/meson.build  |9 +
 drivers/vdpa/ifc/rte_pmd_ifc_version.map  |3 +
 drivers/vdpa/meson.build  |8 +
 31 files changed, 2164 insertions(+), 1996 deletions(-)
 delete mode 100644 doc/guides/nics/features/ifcvf.ini
 delete mode 100644 doc/guides/nics/ifc.rst
 create mode 100644 doc/guides/vdpadevs/features/default.ini
 create mode 100644 doc/guides/vdpadevs/features/ifcvf.ini
 create mode 100644 doc/guides/vdpadevs/features_overview.rst
 create mode 100644 doc/guides/vdpadevs/ifc.rst
 create mode 100644 doc/guides/vdpadevs/index.rst
 delete mode 100644 drivers/net/ifc/Makefile
 delete mode 100644 drivers/net/ifc/base/ifcvf.c
 delete mode 100644 drivers/net/ifc/base/ifcvf.h
 delete mode 100644 drivers/net/ifc/base/ifcvf_osdep.h
 delete mode 100644 drivers/net/ifc/ifcvf_vdpa.c
 delete mode 100644 drivers/net/ifc/meson.build
 delete mode 100644 drivers/net/ifc/rte_pmd_ifc_version.map
 create mode 100644 drivers/vdpa/Makefile
 create mode 100644 drivers/vdpa/ifc/Makefile
 create mode 100644 drivers/vdpa/ifc/base/ifcvf.c
 create mode 100644 drivers/vdpa/ifc/base/ifcvf.h
 create mode 100644 drivers/vdpa/ifc/base/ifcvf_osdep.h
 create mode 100644 drivers/vdpa/ifc/ifcvf_vdpa.c
 create mode 100644 drivers/vdpa/ifc/meson.build
 create mode 100644 drivers/vdpa/ifc/rte_pmd_ifc_version.map
 create mode 100644 drivers/vdpa/meson.build

-- 
1.8.3.1

[dpdk-dev] [PATCH v2 1/3] drivers: introduce vDPA class

[Matan Azrad]

The vDPA (vhost data path acceleration) drivers provide support for
the vDPA operations introduced by the rte_vhost library.

Any driver which provides the vDPA operations should be moved\added to
the vdpa class under drivers/vdpa/.

Create the general files for vDPA class in drivers and in documentation.

The management tree for vDPA drivers is
git://dpdk.org/next/dpdk-next-virtio.

Signed-off-by: Matan Azrad 
---
 MAINTAINERS   |  5 +
 doc/guides/index.rst  |  1 +
 doc/guides/vdpadevs/index.rst | 13 +
 drivers/Makefile  |  2 ++
 drivers/meson.build   |  1 +
 drivers/vdpa/Makefile |  8 
 drivers/vdpa/meson.build  |  8 
 7 files changed, 38 insertions(+)
 create mode 100644 doc/guides/vdpadevs/index.rst
 create mode 100644 drivers/vdpa/Makefile
 create mode 100644 drivers/vdpa/meson.build

diff --git a/MAINTAINERS b/MAINTAINERS
index 9b5c80f..17c2df7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1089,6 +1089,11 @@ F: doc/guides/compressdevs/zlib.rst
 F: doc/guides/compressdevs/features/zlib.ini
 
 
+vDPA Drivers
+
+T: git://dpdk.org/next/dpdk-next-virtio
+
+
 Eventdev Drivers
 
 M: Jerin Jacob 
diff --git a/doc/guides/index.rst b/doc/guides/index.rst
index 8a1601b..988c6ea 100644
--- a/doc/guides/index.rst
+++ b/doc/guides/index.rst
@@ -19,6 +19,7 @@ DPDK documentation
bbdevs/index
cryptodevs/index
compressdevs/index
+   vdpadevs/index
eventdevs/index
rawdevs/index
mempool/index
diff --git a/doc/guides/vdpadevs/index.rst b/doc/guides/vdpadevs/index.rst
new file mode 100644
index 000..d69dc91
--- /dev/null
+++ b/doc/guides/vdpadevs/index.rst
@@ -0,0 +1,13 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright 2019 Mellanox Technologies, Ltd
+
+vDPA Device Drivers
+===
+
+The following are a list of vDPA(vhost data path acceleration) device drivers,
+which can be used from an application through vhost API.
+
+.. toctree::
+:maxdepth: 2
+:numbered:
+
diff --git a/drivers/Makefile b/drivers/Makefile
index 7d5da5d..46374ca 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -18,6 +18,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_PMD_QAT) += common/qat
 DEPDIRS-common/qat := bus mempool
 DIRS-$(CONFIG_RTE_LIBRTE_COMPRESSDEV) += compress
 DEPDIRS-compress := bus mempool
+DIRS-$(CONFIG_RTE_LIBRTE_VHOST) += vdpa
+DEPDIRS-vdpa := common bus mempool
 DIRS-$(CONFIG_RTE_LIBRTE_EVENTDEV) += event
 DEPDIRS-event := common bus mempool net
 DIRS-$(CONFIG_RTE_LIBRTE_RAWDEV) += raw
diff --git a/drivers/meson.build b/drivers/meson.build
index 2850d0f..29708cc 100644
--- a/drivers/meson.build
+++ b/drivers/meson.build
@@ -13,6 +13,7 @@ dpdk_driver_classes = ['common',
   'raw', # depends on common, bus and net.
   'crypto',  # depends on common, bus and mempool (net in future).
   'compress', # depends on common, bus, mempool.
+  'vdpa',# depends on common, bus and mempool.
   'event',   # depends on common, bus, mempool and net.
   'baseband'] # depends on common and bus.
 
diff --git a/drivers/vdpa/Makefile b/drivers/vdpa/Makefile
new file mode 100644
index 000..82a2b70
--- /dev/null
+++ b/drivers/vdpa/Makefile
@@ -0,0 +1,8 @@
+#   SPDX-License-Identifier: BSD-3-Clause
+#   Copyright 2019 Mellanox Technologies, Ltd
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+# DIRS-$() += 
+
+include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/drivers/vdpa/meson.build b/drivers/vdpa/meson.build
new file mode 100644
index 000..a839ff5
--- /dev/null
+++ b/drivers/vdpa/meson.build
@@ -0,0 +1,8 @@
+#   SPDX-License-Identifier: BSD-3-Clause
+#   Copyright 2019 Mellanox Technologies, Ltd
+
+drivers = []
+std_deps = ['bus_pci', 'kvargs']
+std_deps += ['vhost']
+config_flag_fmt = 'RTE_LIBRTE_@0@_PMD'
+driver_name_fmt = 'rte_pmd_@0@'
-- 
1.8.3.1

[dpdk-dev] [PATCH v2 2/3] doc: add vDPA feature table

[Matan Azrad]

Add vDPA devices features table and explanation.

Any vDPA driver can add its own supported features by ading a new ini
file to the features directory in doc/guides/vdpadevs/features.

Signed-off-by: Matan Azrad 
---
 doc/guides/conf.py|  5 +++
 doc/guides/vdpadevs/features/default.ini  | 50 +
 doc/guides/vdpadevs/features_overview.rst | 74 +++
 doc/guides/vdpadevs/index.rst |  1 +
 4 files changed, 130 insertions(+)
 create mode 100644 doc/guides/vdpadevs/features/default.ini
 create mode 100644 doc/guides/vdpadevs/features_overview.rst

diff --git a/doc/guides/conf.py b/doc/guides/conf.py
index 0892c06..c368fa5 100644
--- a/doc/guides/conf.py
+++ b/doc/guides/conf.py
@@ -401,6 +401,11 @@ def setup(app):
 'Features',
 'Features availability in compression drivers',
 'Feature')
+table_file = dirname(__file__) + '/vdpadevs/overview_feature_table.txt'
+generate_overview_table(table_file, 1,
+'Features',
+'Features availability in vDPA drivers',
+'Feature')
 
 if LooseVersion(sphinx_version) < LooseVersion('1.3.1'):
 print('Upgrade sphinx to version >= 1.3.1 for '
diff --git a/doc/guides/vdpadevs/features/default.ini 
b/doc/guides/vdpadevs/features/default.ini
new file mode 100644
index 000..518e4f1
--- /dev/null
+++ b/doc/guides/vdpadevs/features/default.ini
@@ -0,0 +1,50 @@
+;
+; Features of a default vDPA driver.
+;
+; This file defines the features that are valid for inclusion in
+; the other driver files and also the order that they appear in
+; the features table in the documentation. The feature description
+; string should not exceed feature_str_len defined in conf.py.
+;
+[Features]
+csum =
+guest csum   =
+mac  =
+gso  =
+guest tso4   =
+guest tso6   =
+ecn  =
+ufo  =
+host tso4=
+host tso6=
+mrg rxbuf=
+ctrl vq  =
+ctrl rx  =
+any layout   =
+guest announce   =
+mq   =
+version 1=
+log all  =
+indirect desc=
+event idx=
+mtu  =
+in_order =
+IOMMU platform   =
+packed   =
+proto mq =
+proto log shmfd  =
+proto rarp   =
+proto reply ack  =
+proto host notifier  =
+proto pagefault  =
+BSD nic_uio  =
+Linux VFIO   =
+Other kdrv   =
+ARMv7=
+ARMv8=
+Power8   =
+x86-32   =
+x86-64   =
+Usage doc=
+Design doc   =
+Perf doc =
\ No newline at end of file
diff --git a/doc/guides/vdpadevs/features_overview.rst 
b/doc/guides/vdpadevs/features_overview.rst
new file mode 100644
index 000..3ce1db1
--- /dev/null
+++ b/doc/guides/vdpadevs/features_overview.rst
@@ -0,0 +1,74 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright 2019 Mellanox Technologies, Ltd
+
+Overview of vDPA drivers features
+=
+
+This section explains the supported features that are listed in the table 
below.
+
+  * csum - Device can handle packets with partial checksum.
+  * guest csum - Guest can handle packets with partial checksum.
+  * mac - Device has given MAC address.
+  * gso - Device can handle packets with any GSO type.
+  * guest tso4 - Guest can receive TSOv4.
+  * guest tso6 - Guest can receive TSOv6.
+  * ecn - Device can receive TSO with ECN.
+  * ufo - Device can receive UFO.
+  * host tso4 - Device can receive TSOv4.
+  * host tso6 - Device can receive TSOv6.
+  * mrg rxbuf - Guest can merge receive buffers.
+  * ctrl vq - Control channel is available.
+  * ctrl rx - Control channel RX mode support.
+  * any layout - Device can handle any descriptor layout.
+  * guest announce - Guest can send gratuitous packets.
+  * mq - Device supports Receive Flow Steering.
+  * version 1 - v1.0 compliant.
+  * log all - Device can log all write descriptors (live migration).
+  * indirect desc - Indirect buffer descriptors support.
+  * event idx - Support for avail_idx and used_idx fields.
+  * mtu - Host can advise the guest with its maximum supported MTU.
+  * in_order - Device can use descriptors in ring order.
+  * IOMMU platform - Device support IOMMU addresses.
+  * packed - Device support packed virtio queues.
+  * proto mq - Support the number of queues query.
+  * proto log shmfd - Guest support setting log base.
+  * proto rarp - Host can broadcast a fake RARP after live migration.
+  * proto reply ack - Host support requested operation status ack.
+  * proto host notifier - Host can register memory region based host notifiers.
+  * proto pagefault - Slave expose page-fault FD for migrat

[dpdk-dev] [PATCH v2 3/3] drivers: move ifc driver to the vDPA class

[Matan Azrad]

A new vDPA class was recently introduced.

IFC driver implements the vDPA operations, hence it should be moved to
the vDPA class.

Move it.

Signed-off-by: Matan Azrad 
---
 MAINTAINERS  |   14 +-
 doc/guides/nics/features/ifcvf.ini   |8 -
 doc/guides/nics/ifc.rst  |  106 ---
 doc/guides/nics/index.rst|1 -
 doc/guides/vdpadevs/features/ifcvf.ini   |8 +
 doc/guides/vdpadevs/ifc.rst  |  106 +++
 doc/guides/vdpadevs/index.rst|1 +
 drivers/net/Makefile |3 -
 drivers/net/ifc/Makefile |   34 -
 drivers/net/ifc/base/ifcvf.c |  329 
 drivers/net/ifc/base/ifcvf.h |  162 
 drivers/net/ifc/base/ifcvf_osdep.h   |   52 --
 drivers/net/ifc/ifcvf_vdpa.c | 1280 --
 drivers/net/ifc/meson.build  |9 -
 drivers/net/ifc/rte_pmd_ifc_version.map  |3 -
 drivers/net/meson.build  |1 -
 drivers/vdpa/Makefile|6 +
 drivers/vdpa/ifc/Makefile|   34 +
 drivers/vdpa/ifc/base/ifcvf.c|  329 
 drivers/vdpa/ifc/base/ifcvf.h|  162 
 drivers/vdpa/ifc/base/ifcvf_osdep.h  |   52 ++
 drivers/vdpa/ifc/ifcvf_vdpa.c| 1280 ++
 drivers/vdpa/ifc/meson.build |9 +
 drivers/vdpa/ifc/rte_pmd_ifc_version.map |3 +
 drivers/vdpa/meson.build |2 +-
 25 files changed, 1997 insertions(+), 1997 deletions(-)
 delete mode 100644 doc/guides/nics/features/ifcvf.ini
 delete mode 100644 doc/guides/nics/ifc.rst
 create mode 100644 doc/guides/vdpadevs/features/ifcvf.ini
 create mode 100644 doc/guides/vdpadevs/ifc.rst
 delete mode 100644 drivers/net/ifc/Makefile
 delete mode 100644 drivers/net/ifc/base/ifcvf.c
 delete mode 100644 drivers/net/ifc/base/ifcvf.h
 delete mode 100644 drivers/net/ifc/base/ifcvf_osdep.h
 delete mode 100644 drivers/net/ifc/ifcvf_vdpa.c
 delete mode 100644 drivers/net/ifc/meson.build
 delete mode 100644 drivers/net/ifc/rte_pmd_ifc_version.map
 create mode 100644 drivers/vdpa/ifc/Makefile
 create mode 100644 drivers/vdpa/ifc/base/ifcvf.c
 create mode 100644 drivers/vdpa/ifc/base/ifcvf.h
 create mode 100644 drivers/vdpa/ifc/base/ifcvf_osdep.h
 create mode 100644 drivers/vdpa/ifc/ifcvf_vdpa.c
 create mode 100644 drivers/vdpa/ifc/meson.build
 create mode 100644 drivers/vdpa/ifc/rte_pmd_ifc_version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index 17c2df7..16facba 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -679,14 +679,6 @@ T: git://dpdk.org/next/dpdk-next-net-intel
 F: drivers/net/iavf/
 F: doc/guides/nics/features/iavf*.ini
 
-Intel ifc
-M: Xiao Wang 
-T: git://dpdk.org/next/dpdk-next-net-intel
-F: drivers/net/ifc/
-F: doc/guides/nics/ifc.rst
-F: doc/guides/nics/features/ifc*.ini
-
-Intel ice
 M: Qiming Yang 
 M: Wenzhuo Lu 
 T: git://dpdk.org/next/dpdk-next-net-intel
@@ -1093,6 +1085,12 @@ vDPA Drivers
 
 T: git://dpdk.org/next/dpdk-next-virtio
 
+Intel ifc
+M: Xiao Wang 
+F: drivers/vdpa/ifc/
+F: doc/guides/vdpadevs/ifc.rst
+F: doc/guides/vdpadevs/features/ifcvf.ini
+
 
 Eventdev Drivers
 
diff --git a/doc/guides/nics/features/ifcvf.ini 
b/doc/guides/nics/features/ifcvf.ini
deleted file mode 100644
index ef1fc47..000
--- a/doc/guides/nics/features/ifcvf.ini
+++ /dev/null
@@ -1,8 +0,0 @@
-;
-; Supported features of the 'ifcvf' vDPA driver.
-;
-; Refer to default.ini for the full list of available PMD features.
-;
-[Features]
-x86-32   = Y
-x86-64   = Y
diff --git a/doc/guides/nics/ifc.rst b/doc/guides/nics/ifc.rst
deleted file mode 100644
index 12a2a34..000
--- a/doc/guides/nics/ifc.rst
+++ /dev/null
@@ -1,106 +0,0 @@
-..  SPDX-License-Identifier: BSD-3-Clause
-Copyright(c) 2018 Intel Corporation.
-
-IFCVF vDPA driver
-=
-
-The IFCVF vDPA (vhost data path acceleration) driver provides support for the
-Intel FPGA 100G VF (IFCVF). IFCVF's datapath is virtio ring compatible, it
-works as a HW vhost backend which can send/receive packets to/from virtio
-directly by DMA. Besides, it supports dirty page logging and device state
-report/restore, this driver enables its vDPA functionality.
-
-
-Pre-Installation Configuration
---
-
-Config File Options
-~~~
-
-The following option can be modified in the ``config`` file.
-
-- ``CONFIG_RTE_LIBRTE_IFC_PMD`` (default ``y`` for linux)
-
-  Toggle compilation of the ``librte_pmd_ifc`` driver.
-
-
-IFCVF vDPA Implementation
--
-
-IFCVF's vendor ID and device ID are same as that of virtio net pci device,
-with its specific subsystem vendor ID and device ID. To let the device be
-probed by IFCVF driver, adding "vdpa=1" parameter helps to specify that this
-device is to be used in vDPA mode, rather than polling mode, virtio pmd will
-skip when it detects th

[dpdk-dev] [PATCH v2] net/mlx5: fix ConnectX-4LX Tx burst routines set

[Viacheslav Ovsiienko]

The tx_burst routine supporting multi-segment packets with
legacy MPW and without inline was missed, and there was no
valid selection for these options, patch adds the missing
routine.

Fixes: 82e75f8323bf ("net/mlx5: fix legacy multi-packet Tx descriptors")
Cc: sta...@dpdk.org

Signed-off-by: Viacheslav Ovsiienko 
---
v2: removes ambigous assert() to address the comment
v1: http://patches.dpdk.org/patch/64074/

 drivers/net/mlx5/mlx5_rxtx.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index a7f3bff..e39c5b9 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -4984,6 +4984,10 @@ enum mlx5_txcmp_code {
MLX5_TXOFF_CONFIG_INLINE | MLX5_TXOFF_CONFIG_EMPW |
MLX5_TXOFF_CONFIG_MPW)
 
+MLX5_TXOFF_DECL(mc_mpw,
+   MLX5_TXOFF_CONFIG_MULTI | MLX5_TXOFF_CONFIG_CSUM |
+   MLX5_TXOFF_CONFIG_EMPW | MLX5_TXOFF_CONFIG_MPW)
+
 MLX5_TXOFF_DECL(i_mpw,
MLX5_TXOFF_CONFIG_INLINE | MLX5_TXOFF_CONFIG_EMPW |
MLX5_TXOFF_CONFIG_MPW)
@@ -5140,6 +5144,10 @@ enum mlx5_txcmp_code {
MLX5_TXOFF_CONFIG_INLINE | MLX5_TXOFF_CONFIG_EMPW |
MLX5_TXOFF_CONFIG_MPW)
 
+MLX5_TXOFF_INFO(mc_mpw,
+   MLX5_TXOFF_CONFIG_MULTI | MLX5_TXOFF_CONFIG_CSUM |
+   MLX5_TXOFF_CONFIG_EMPW | MLX5_TXOFF_CONFIG_MPW)
+
 MLX5_TXOFF_INFO(i_mpw,
MLX5_TXOFF_CONFIG_INLINE | MLX5_TXOFF_CONFIG_EMPW |
MLX5_TXOFF_CONFIG_MPW)
-- 
1.8.3.1

Re: [dpdk-dev] [dpdk-stable] [PATCH] net/mlx5: fix ConnectX-4LX Tx burst routines set

[Slava Ovsiienko]

> -Original Message-
> From: Ferruh Yigit 
> Sent: Thursday, January 9, 2020 12:50
> To: Slava Ovsiienko ; dev@dpdk.org
> Cc: Matan Azrad ; Raslan Darawsheh
> ; Ori Kam ; sta...@dpdk.org;
> Thomas Monjalon 
> Subject: Re: [dpdk-stable] [PATCH] net/mlx5: fix ConnectX-4LX Tx burst
> routines set
> 
> On 1/9/2020 9:03 AM, Slava Ovsiienko wrote:
> >> -Original Message-
> >> From: Ferruh Yigit 
> >> Sent: Wednesday, January 8, 2020 17:55
> >> To: Slava Ovsiienko ; dev@dpdk.org
> >> Cc: Matan Azrad ; Raslan Darawsheh
> >> ; Ori Kam ;
> >> sta...@dpdk.org; Thomas Monjalon 
> >> Subject: Re: [dpdk-stable] [PATCH] net/mlx5: fix ConnectX-4LX Tx
> >> burst routines set
> >>
> >> On 1/8/2020 3:50 PM, Slava Ovsiienko wrote:
> >>> Hi, Ferruh
> >>>
>  -Original Message-
>  From: Ferruh Yigit 
>  Sent: Wednesday, January 8, 2020 16:55
>  To: Slava Ovsiienko ; dev@dpdk.org
>  Cc: Matan Azrad ; Raslan Darawsheh
>  ; Ori Kam ;
>  sta...@dpdk.org; Thomas Monjalon 
>  Subject: Re: [dpdk-stable] [PATCH] net/mlx5: fix ConnectX-4LX Tx
>  burst routines set
> 
>  On 1/8/2020 2:53 PM, Ferruh Yigit wrote:
> > On 12/20/2019 10:48 AM, Viacheslav Ovsiienko wrote:
> >> The tx_burst routine supporting multi-segment packets with legacy
> >> MPW and without inline was missed, and there was no valid
> >> selection for these options, patch adds the missing routine.
> >>
> >> Fixes: 82e75f8323bf ("net/mlx5: fix legacy multi-packet Tx
> >> descriptors")
> >> Cc: sta...@dpdk.org
> >>
> >> Signed-off-by: Viacheslav Ovsiienko 
> >>
> >> <...>
> >>
> >> @@ -5297,6 +5305,7 @@ enum mlx5_txcmp_code {
> >>DRV_LOG(DEBUG, "port %u has no selected Tx
> function"
> >>   " for requested offloads %04X",
> >>dev->data->port_id, olx);
> >> +  assert(false);
> >>
> >> <...>
> >>
> >>>
> 
> >
> > I think we should avoid PMDs calling the assert unconditionally,
> > specially in a code that debug level log is printed.
> >
> >>return NULL;
> >>}
> >>DRV_LOG(DEBUG, "port %u has selected Tx function"
> >>>
> >>> Yes, I agree. We just do not have the check for the result returned
> >>> by mlx5_select_tx_function(). I think we should check against NULL
> >>> and report an error.  "assert" is a temporary solution till this
> >>> upgrade (in debug mode we have a lot of messages and break on assert
> >>> helps to locate the problem quickly, reporting error will do the same).
> >>>
> >>
> >> Can it be possible to drop the patch from mlx tree and prepare a new
> >> version without 'assert'?
> > The selection routine error handling is rather generic and is not merely
> related to ConnectX-4LX.
> > I propose to prepare the dedicated patch, what do you  think?
> >
> 
> My concern is with the assert, the error handling can be another patch, but
> can we have this change without an assert? 

Yes, please: http://patches.dpdk.org/patch/64340/

With best regards, Slava

PS. Removing this assert urges me to add error handling ASAP 😊

Re: [dpdk-dev] [PATCH v2] testpmd: call cleanup on exit

[Ferruh Yigit]

On 1/8/2020 3:28 PM, Stephen Hemminger wrote:
> On Wed, 8 Jan 2020 09:45:54 +
> "Iremonger, Bernard"  wrote:
> 
>> Hi Stephen,
>>
>>> -Original Message-
>>> From: dev  On Behalf Of Stephen Hemminger
>>> Sent: Tuesday, January 7, 2020 7:00 PM
>>> To: dev@dpdk.org
>>> Cc: Stephen Hemminger 
>>> Subject: [dpdk-dev] [PATCH v2] testpmd: call cleanup on exit
>>>
>>> The rte_eal_cleanup code is not exercised by testpmd which is the most
>>> used DPDK test tool. Add a call at end of program.
>>>
>>> This helps exercise free and close paths which can be checked with tools 
>>> like
>>> valgrind.
>>>
>>> Signed-off-by: Stephen Hemminger 
>>> ---
>>> v2 - report errors
>>>
>>>  app/test-pmd/testpmd.c | 7 ++-
>>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
>>> b3746822366f..2eec8afda1ec 100644
>>> --- a/app/test-pmd/testpmd.c
>>> +++ b/app/test-pmd/testpmd.c
>>> @@ -3570,5 +3570,10 @@ main(int argc, char** argv)
>>> return 1;
>>> }
>>>
>>> -   return 0;
>>> +   ret = rte_eal_cleanup();
>>> +   if (ret != 0)
>>> +   rte_exit(EXIT_FAILURE,
>>> +"EAL cleanup failed: %s\n", strerror(-ret));
>>> +
>>> +   return EXIT_SUCCESS;
>>>  }
>>> --
>>> 2.20.1  
>>
>> This looks like a fix to me and is probably worth backporting, it should 
>> probably have a fixes line.
>>
>> Regards,
>>
>> Bernard.
>>
> 
> Not sure if it needs to be backported. It depends on the definition
> of a fix.  The original definition of stable was fixes only.
> Linux has moved on to fixes and backports of missing features
> like this; but DPDK has mostly stuck to the original definition
> of stable.
> 

I also tend to think this a fix more then a feature, and although it is a minor
fix it is good to get it to reduce the change of the conflict on other stuff in
LTS. I will add fix/stable tag while merging.

Re: [dpdk-dev] [PATCH v2] testpmd: call cleanup on exit

[Ferruh Yigit]

On 1/9/2020 11:16 AM, Ferruh Yigit wrote:
> On 1/8/2020 3:28 PM, Stephen Hemminger wrote:
>> On Wed, 8 Jan 2020 09:45:54 +
>> "Iremonger, Bernard"  wrote:
>>
>>> Hi Stephen,
>>>
 -Original Message-
 From: dev  On Behalf Of Stephen Hemminger
 Sent: Tuesday, January 7, 2020 7:00 PM
 To: dev@dpdk.org
 Cc: Stephen Hemminger 
 Subject: [dpdk-dev] [PATCH v2] testpmd: call cleanup on exit

 The rte_eal_cleanup code is not exercised by testpmd which is the most
 used DPDK test tool. Add a call at end of program.

 This helps exercise free and close paths which can be checked with tools 
 like
 valgrind.

 Signed-off-by: Stephen Hemminger 
 ---
 v2 - report errors

  app/test-pmd/testpmd.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

 diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
 b3746822366f..2eec8afda1ec 100644
 --- a/app/test-pmd/testpmd.c
 +++ b/app/test-pmd/testpmd.c
 @@ -3570,5 +3570,10 @@ main(int argc, char** argv)
return 1;
}

 -  return 0;
 +  ret = rte_eal_cleanup();
 +  if (ret != 0)
 +  rte_exit(EXIT_FAILURE,
 +   "EAL cleanup failed: %s\n", strerror(-ret));
 +
 +  return EXIT_SUCCESS;
  }
 --
 2.20.1  
>>>
>>> This looks like a fix to me and is probably worth backporting, it should 
>>> probably have a fixes line.
>>>
>>> Regards,
>>>
>>> Bernard.
>>>
>>
>> Not sure if it needs to be backported. It depends on the definition
>> of a fix.  The original definition of stable was fixes only.
>> Linux has moved on to fixes and backports of missing features
>> like this; but DPDK has mostly stuck to the original definition
>> of stable.
>>
> 
> I also tend to think this a fix more then a feature, and although it is a 
> minor
> fix it is good to get it to reduce the change of the conflict on other stuff 
> in
> LTS. I will add fix/stable tag while merging.
> 

Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org

Acked-by: Bernard Iremonger 

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

Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device drivers

[Matan Azrad]

From: Xu, Rosen 
> > -Original Message-
> > From: Thomas Monjalon 
> > Sent: Thursday, January 09, 2020 16:41
> > To: Xu, Rosen 
> > Cc: Matan Azrad ; Maxime Coquelin
> > ; Bie, Tiwei ; Wang,
> > Zhihong ; Wang, Xiao W
> > ; Yigit, Ferruh ;
> > dev@dpdk.org; Pei, Andy 
> > Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA
> > device drivers
> >
> > 09/01/2020 03:27, Xu, Rosen:
> > > Hi,
> > >
> > > From: Thomas Monjalon 
> > > > 08/01/2020 13:39, Xu, Rosen:
> > > > > From: Matan Azrad 
> > > > > > From: Xu, Rosen
> > > > > > > Did you think about OVS DPDK?
> > > > > > > vDPA is a basic module for OVS, currently it will take some
> > > > > > > exception path packet processing for OVS, so it still needs
> > > > > > > to integrate
> > > > eth_dev.
> > > > > >
> > > > > > I don't understand your question.
> > > > > >
> > > > > > What do you mean by "integrate eth_dev"?
> > > > >
> > > > > My questions is in OVS DPDK scenario vDPA device implements
> > > > > eth_dev ops, so create a new class and move ifc code to this new
> > > > > class
> > is not ok.
> > > >
> > > > 1/ I don't understand the relation with OVS.
> > > >
> > > > 2/ no, vDPA device implements vDPA ops.
> > > > If it implements ethdev ops, it is an ethdev device.
> > > >
> > > > Please show an example of what you claim.
> > >
> > > Answers of 1 and 2.
> > >
> > > In OVS DPDK, each network device(such as NIC, vHost etc) of DPDK
> > > needs to be implemented as rte_eth_dev and provides eth_dev_ops
> such
> > > as
> > packet TX/RX for OVS.
> >
> > No, OVS is also using the vhost API for vhost port.
> 
> Yes, vhost pmd is not a good example.
> 
> > > Take vHost(Virtio back end) for example, OVS startups vHost
> > > interface like
> > this:
> > > ovs-vsctl add-port br0 vhost-user-1 -- set Interface vhost-user-1
> > > type=dpdkvhostuser drivers/net/vhost implements vHost as
> rte_eth_dev
> > and integrated in OVS.
> > > OVS can send/receive packets to/from VM with rte_eth_tx_burst()
> > > rte_eth_rx_burst() which call eth_dev_ops implementation of
> > drivers/net/vhost.
> >
> > No, it is using rte_vhost_dequeue_burst() and
> > rte_vhost_enqueue_burst() which are not in ethdev.
> >
> > > vDPA is also Virtio back end and works like vHost, same as vHost, it
> > > will be implemented as rte_eth_dev and also be integrated into OVS.
> >
> > No, vDPA is not "implemented as rte_eth_dev".
> 
> Currently, vDPA isn't integrated with OVS.
> 
> > > So, it's not ok to move ifc code from drivers/net.
> >
> > drivers/net/ifc has no ethdev implementation at all.
> 
> For OVS hasn't integrated vDPA, it doesn't implement rte_eth_dev, but
> there are many discussions in OVS community about vDPA, some are from
> Mellanox, it seems vDPA port will be implemented as rte_eth_dev port in
> OVS in the near feature.
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.ozlabs.org%2Fpatch%2F1178474%2F&data=02%7C01%7Cmatan%4
> 0mellanox.com%7C9e84c2581e2f414e0aca08d794f22e8d%7Ca652971c7d2e4d
> 9ba6a4d149256f461b%7C0%7C0%7C637141640216181763&sdata=TA%2F
> 0zU495kXUqhC6eP09NDzBZfjJz1dbfkRcDpV%2BYAs%3D&reserved=0
> 
> Matan,
> Could you clarify how OVS integrates vDPA in Mellanox patch?
> 
> >
> > Rosen, I'm sorry, these arguments look irrelevant, so I won't consider
> > them as blocking the integration of this patch.
> 
> What I mentioned is not blocking the integration of this patch, I just want to
> get clarification from Matan how to integrate vDPA port in OVS.


Hi

OVS like any other application should use the current API of vDPA to attach a 
probed vdpa device to a vhost device.
See example application /examples/vdpa.

Here, we just introduce a new class to hold all the vDPA drivers, no change in 
the API.

As I understand, no vDPA device is currently integrated in OVS.

I think it can be integrated only when a full offload will be integrated since 
the vDPA device forward the traffic from the HW directly to the virtio queue, 
once it will be there, I guess the offload will be configured by the 
representor of the vdpa device(VF) which is managed by an ethdev device.


Matan.

 

Re: [dpdk-dev] [PATCH v2 0/10] dpdk: introduce __rte_internal tag

[Neil Horman]

On Thu, Jan 09, 2020 at 10:55:04AM +0100, David Marchand wrote:
> Hello Neil,
> 
> On Tue, Aug 6, 2019 at 2:22 PM Neil Horman  wrote:
> >
> > On Tue, Aug 06, 2019 at 12:03:38PM +0200, Thomas Monjalon wrote:
> > > I think it would be good to rebase and send at the beginning of the 19.11 
> > > cycle.
> > > Thank you
> > >
> > I'm on PTO for the next 10 days or so, but yes, I'll take care of that asap.
> 
> Looks like your PTO were a bit longer than 10 days ;-).
> Do you have some cycles to resurrect this series?
> 
Shoot, apologies, it completely slipped my mind.  Yes, I'll get back to this
today
Neil

> 
> --
> David Marchand
> 
> 

Re: [dpdk-dev] [PATCH 12/14] examples/ipsec-secgw: add driver outbound worker

[Anoob Joseph]

Hi Konstantin,

Please see inline.

Thanks,
Anoob

> -Original Message-
> From: dev  On Behalf Of Ananyev, Konstantin
> Sent: Tuesday, January 7, 2020 8:01 PM
> To: Anoob Joseph ; Akhil Goyal
> ; Nicolau, Radu ; Thomas
> Monjalon 
> Cc: Ankur Dwivedi ; Jerin Jacob Kollanukkaran
> ; Narayana Prasad Raju Athreya
> ; Archana Muniganti ;
> Tejasree Kondoj ; Vamsi Krishna Attunuru
> ; Lukas Bartosik ;
> dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 12/14] examples/ipsec-secgw: add driver
> outbound worker
> 
> > > > > > This patch adds the driver outbound worker thread for ipsec-secgw.
> > > > > > In this mode the security session is a fixed one and sa update
> > > > > > is not done.
> > > > > >
> > > > > > Signed-off-by: Ankur Dwivedi 
> > > > > > Signed-off-by: Anoob Joseph 
> > > > > > Signed-off-by: Lukasz Bartosik 
> > > > > > ---
> > > > > >  examples/ipsec-secgw/ipsec-secgw.c  | 12 +
> > > > > >  examples/ipsec-secgw/ipsec.c|  9 
> > > > > >  examples/ipsec-secgw/ipsec_worker.c | 90
> > > > > > -
> > > > > >  3 files changed, 110 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/examples/ipsec-secgw/ipsec-secgw.c
> > > > > > b/examples/ipsec-secgw/ipsec-secgw.c
> > > > > > index 2e7d4d8..76719f2 100644
> > > > > > --- a/examples/ipsec-secgw/ipsec-secgw.c
> > > > > > +++ b/examples/ipsec-secgw/ipsec-secgw.c
> > > > > > @@ -2011,6 +2011,18 @@ cryptodevs_init(void)
> > > > > > i++;
> > > > > > }
> > > > > >
> > > > > > +   /*
> > > > > > +* Set the queue pair to at least the number of
> ethernet
> > > > > > +* devices for inline outbound.
> > > > > > +*/
> > > > > > +   qp = RTE_MAX(rte_eth_dev_count_avail(), qp);
> > > > >
> > > > >
> > > > > Not sure, what for?
> > > > > Why we can't process packets from several eth devs on the same
> > > > > crypto-dev queue?
> > > >
> > > > [Anoob] This is because of a limitation in our hardware. In our
> > > > hardware, it's the crypto queue pair which would be submitting to
> > > > the ethernet queue for Tx. But in DPDK spec, the security
> > > > processing is done by the ethernet PMD Tx routine alone. We manage
> > > > to do this by sharing
> > > the crypto queue internally. The crypto queues initialized during
> > > crypto_configure() gets mapped to various ethernet ports. Because of
> > > this, we need to have atleast as many crypto queues as the number of
> eth ports.
> > >
> > > Ok, but that breaks current behavior.
> > > Right now in poll-mode it is possible to map traffic from N eth-devs
> > > to M crypto- devs (N>= M, by using M lcores).
> > > Would prefer to keep this functionality in place.
> >
> > [Anoob] Understood. I don't think that functionality is broken. If the
> > number of qps available is lower than the number of eth devs, then only
> the ones available would be enabled. Inline protocol session for the other
> eth devs would fail for us.
> >
> > Currently, the app assumes that for one core, it needs only one qp
> > (and for M core, M qp). Is there any harm in enabling all qps available? If
> such a change can be done, that would also work for us.
> 
> Hmm, I suppose it could cause some problems with some corner-cases:
> if we'll have crypto-dev with really big number of max_queues.
> In that case it might require a lot of extra memory for
> cryptodev_configure/queue_pair_setup.
> Probably the easiest way to deal with it:
> - add req_queue_num parameter for cryptodevs_init()
>And then do: qp =RTE_MIN(max_nb_qps, RTE_MAX(req_queue_num,
> qp));
>  - for poll mode we'll call cryptodevs_init(0), for your case it could be
>cryptodevs_init(rte_eth_dev_count_avail()).
> 
> Would it work for your case?

[Anoob] I tried investigating about this a bit more. The reason why we get 
limited by the number of cores is because of the logic in add_cdev_mapping() & 
add_mapping() functions. I've tried reworking it a bit and was able to make it 
equal to number of lcore params (core-port-queue mapping). Technically, we just 
need to match that. What do you think? I will submit a separate patch with the 
said rework.
 
> 
> > >
> > > >
> > > > The above change is required because here we limit the number of
> > > > crypto qps based on the number of cores etc. So when tried on
> > > > single core, the
> > > qps get limited to 1, which causes session_create() to fail for all
> > > ports other than the first one.
> > > >
> > > > >
> > > > > > +
> > > > > > +   /*
> > > > > > +* The requested number of queues should never
> exceed
> > > > > > +* the max available
> > > > > > +*/
> > > > > > +   qp = RTE_MIN(qp, max_nb_qps);
> > > > > > +
> > > > > > if (qp == 0)
> > > > > > continue;
> > > > > >
> > > > > > diff --git a/examples/ipsec-secgw/ipsec.c
> > > > > > b/examples/ipsec-secgw/ipsec.c index e529f68..9ff8a63 100644
> > >

Re: [dpdk-dev] [PATCH v2 0/10] dpdk: introduce __rte_internal tag

[David Marchand]

On Thu, Jan 9, 2020 at 12:46 PM Neil Horman  wrote:
>
> On Thu, Jan 09, 2020 at 10:55:04AM +0100, David Marchand wrote:
> > Hello Neil,
> >
> > On Tue, Aug 6, 2019 at 2:22 PM Neil Horman  wrote:
> > >
> > > On Tue, Aug 06, 2019 at 12:03:38PM +0200, Thomas Monjalon wrote:
> > > > I think it would be good to rebase and send at the beginning of the 
> > > > 19.11 cycle.
> > > > Thank you
> > > >
> > > I'm on PTO for the next 10 days or so, but yes, I'll take care of that 
> > > asap.
> >
> > Looks like your PTO were a bit longer than 10 days ;-).
> > Do you have some cycles to resurrect this series?
> >
> Shoot, apologies, it completely slipped my mind.  Yes, I'll get back to this
> today

Cool!
Thanks Neil.


-- 
David Marchand

[dpdk-dev] [PATCH 0/6] meson build improvements

[Bruce Richardson]

These patches make some improvements to the meson build, particularly
for documentation. They also remove many, but not all warnings issued by
meson e.g. warnings about newer features unsupported in baseline.

The biggest change is to improve the handling of the guide html docs.
The change here is more significant, and the doc build now uses a
wrapper script around sphinx. This wrapper script allows us to output
correct dependency information for the sphinx build in a .d file. This
.d file is processed by ninja (not meson) on build, so that any changes
to doc files trigger a rebuild to the guides using sphinx.

For now, the two patches which remove the meson version warnings are
CC'ed to stable for backport, theoretically this who set could be
backported if so desired, as all changes could be considered fixes to
some degree or other, and nothing introduces a whole new feature.

Note: for completeness and simplicity, previously submitted patch
http://patches.dpdk.org/patch/64189/ is included in this set, and will
be marked superceded in patchwork.

Bruce Richardson (6):
  kernel/linux/kni: fix meson warning about console keyword
  build: skip processing docs folder if docs disabled
  doc/api: fix warning with meson build
  doc/guides: reduce whitespace in meson build file
  doc/guides: rebuild with meson whenever a file changes
  doc/api: reduce indentation in meson build file

 buildtools/call-sphinx-build.py | 29 ++
 buildtools/meson.build  |  6 +-
 doc/api/meson.build | 99 +
 doc/guides/meson.build  | 38 ++---
 doc/meson.build |  4 ++
 kernel/linux/kni/meson.build|  1 -
 6 files changed, 104 insertions(+), 73 deletions(-)
 create mode 100755 buildtools/call-sphinx-build.py

-- 
2.24.1

[dpdk-dev] [PATCH 3/6] doc/api: fix warning with meson build

[Bruce Richardson]

The install parameter to configure_file is new in 0.50 and generates a
warning since it is newer than our minimum version of 0.47.1. The
parameter, however, is unneeded as the documentation states:

"When omitted it defaults to true when install_dir is set and not empty,
false otherwise."

Given that install_dir is not set for this file, install defaults to false
so no need to explicitly specify it.

Fixes: 720b14db3ae2 ("build: generate API documentation with meson")
Cc: bl...@debian.org

Signed-off-by: Bruce Richardson 
---
 doc/api/meson.build | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/doc/api/meson.build b/doc/api/meson.build
index 1c48b7672..23a7dfc75 100644
--- a/doc/api/meson.build
+++ b/doc/api/meson.build
@@ -38,8 +38,7 @@ if doxygen.found()
 
doxy_conf = configure_file(input: 'doxy-api.conf.in',
output: 'doxy-api.conf',
-   configuration: cdata,
-   install: false)
+   configuration: cdata)
 
doxy_build = custom_target('doxygen',
depends: example,
-- 
2.24.1

[dpdk-dev] [PATCH 1/6] kernel/linux/kni: fix meson warning about console keyword

[Bruce Richardson]

Since kni no longer includes the ethtool code and so is faster to build, we
no longer need the console parameter to have incremental screen updates as
it builds. Therefore, we drop the keyword which removes the warning.

Fixes: b78f32cff94d ("kni: support meson build")
Cc: bl...@debian.org

Signed-off-by: Bruce Richardson 
---
 kernel/linux/kni/meson.build | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/linux/kni/meson.build b/kernel/linux/kni/meson.build
index 955eec949..f93e97fa0 100644
--- a/kernel/linux/kni/meson.build
+++ b/kernel/linux/kni/meson.build
@@ -23,7 +23,6 @@ custom_target('rte_kni',
' -I' + meson.current_source_dir(),
'modules'],
depends: kni_mkfile,
-   console: true,
install: true,
install_dir: kernel_dir + '/extra/dpdk',
build_by_default: get_option('enable_kmods'))
-- 
2.24.1

[dpdk-dev] [PATCH 2/6] build: skip processing docs folder if docs disabled

[Bruce Richardson]

While each target is set to be ignored if the docs are disabled in the
meson build, there is little reason to process the docs folder at all.

Signed-off-by: Bruce Richardson 
---
 doc/meson.build | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/meson.build b/doc/meson.build
index c5410d85d..c49ec8476 100644
--- a/doc/meson.build
+++ b/doc/meson.build
@@ -1,6 +1,10 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2018 Luca Boccassi 
 
+if not get_option('enable_docs')
+   subdir_done()
+endif
+
 doc_targets = []
 doc_target_names = []
 subdir('api')
-- 
2.24.1

[dpdk-dev] [PATCH 6/6] doc/api: reduce indentation in meson build file

[Bruce Richardson]

When building the API docs, we can make the meson.build file easier to
read, and allow more code per line, by using subdir_done() to quit early.

Signed-off-by: Bruce Richardson 
---
 doc/api/meson.build | 98 +++--
 1 file changed, 50 insertions(+), 48 deletions(-)

diff --git a/doc/api/meson.build b/doc/api/meson.build
index 23a7dfc75..c72b880e1 100644
--- a/doc/api/meson.build
+++ b/doc/api/meson.build
@@ -3,52 +3,54 @@
 
 doxygen = find_program('doxygen', required: get_option('enable_docs'))
 
-if doxygen.found()
-   # due to the CSS customisation script, which needs to run on a file that
-   # is in a subdirectory that is created at build time and thus it cannot
-   # be an individual custom_target, we need to wrap the doxygen call in a
-   # script to run the CSS modification afterwards
-   generate_doxygen = find_program('generate_doxygen.sh')
-   generate_examples = find_program('generate_examples.sh')
-   generate_css = find_program('doxy-html-custom.sh')
-
-   inputdir = join_paths(meson.source_root(), 'examples')
-   htmldir = join_paths('share', 'doc', 'dpdk')
-
-   # due to the following bug: 
https://github.com/mesonbuild/meson/issues/4107
-   # if install is set to true it will override build_by_default and it 
will
-   # cause the target to always be built. If install were to be always set 
to
-   # false it would be impossible to install the docs.
-   # So use a configure option for now.
-   example = custom_target('examples.dox',
-   input: inputdir,
-   output: 'examples.dox',
-   command: [generate_examples, '@INPUT@', '@OUTPUT@'],
-   install: get_option('enable_docs'),
-   install_dir: htmldir,
-   build_by_default: get_option('enable_docs'))
-
-   cdata = configuration_data()
-   cdata.set('VERSION', meson.project_version())
-   cdata.set('API_EXAMPLES', join_paths(meson.build_root(), 'doc', 'api', 
'examples.dox'))
-   cdata.set('OUTPUT', join_paths(meson.build_root(), 'doc', 'api'))
-   cdata.set('HTML_OUTPUT', 'api')
-   cdata.set('TOPDIR', meson.source_root())
-   cdata.set('STRIP_FROM_PATH', meson.source_root())
-
-   doxy_conf = configure_file(input: 'doxy-api.conf.in',
-   output: 'doxy-api.conf',
-   configuration: cdata)
-
-   doxy_build = custom_target('doxygen',
-   depends: example,
-   input: doxy_conf,
-   output: 'api',
-   command: [generate_doxygen, '@INPUT@', '@OUTPUT@', 
generate_css],
-   install: get_option('enable_docs'),
-   install_dir: htmldir,
-   build_by_default: get_option('enable_docs'))
-
-   doc_targets += doxy_build
-   doc_target_names += 'Doxygen_API'
+if not doxygen.found()
+  subdir_done()
 endif
+
+# due to the CSS customisation script, which needs to run on a file that
+# is in a subdirectory that is created at build time and thus it cannot
+# be an individual custom_target, we need to wrap the doxygen call in a
+# script to run the CSS modification afterwards
+generate_doxygen = find_program('generate_doxygen.sh')
+generate_examples = find_program('generate_examples.sh')
+generate_css = find_program('doxy-html-custom.sh')
+
+inputdir = join_paths(meson.source_root(), 'examples')
+htmldir = join_paths('share', 'doc', 'dpdk')
+
+# due to the following bug: https://github.com/mesonbuild/meson/issues/4107
+# if install is set to true it will override build_by_default and it will
+# cause the target to always be built. If install were to be always set to
+# false it would be impossible to install the docs.
+# So use a configure option for now.
+example = custom_target('examples.dox',
+   input: inputdir,
+   output: 'examples.dox',
+   command: [generate_examples, '@INPUT@', '@OUTPUT@'],
+   install: get_option('enable_docs'),
+   install_dir: htmldir,
+   build_by_default: get_option('enable_docs'))
+
+cdata = configuration_data()
+cdata.set('VERSION', meson.project_version())
+cdata.set('API_EXAMPLES', join_paths(meson.build_root(), 'doc', 'api', 
'examples.dox'))
+cdata.set('OUTPUT', join_paths(meson.build_root(), 'doc', 'api'))
+cdata.set('HTML_OUTPUT', 'api')
+cdata.set('TOPDIR', meson.source_root())
+cdata.set('STRIP_FROM_PATH', meson.source_root())
+
+doxy_conf = configure_file(input: 'doxy-api.conf.in',
+   output: 'doxy-api.conf',
+   configuration: cdata)
+
+doxy_build = custom_target('doxygen',
+   depends: example,
+   input: doxy_conf,
+   output: 'api',
+   command: [generate_doxygen, '@INPUT@', '@OUTPUT@', generate_css],
+   install: get_option('enable_docs'),
+   install_dir: htmldir,
+   build_by_default: get_option('enable_docs'))
+
+doc_targets += doxy_build
+doc_target_names += 'Doxygen_API'
-- 
2.24.1

[dpdk-dev] [PATCH 4/6] doc/guides: reduce whitespace in meson build file

[Bruce Richardson]

For building the guides, we can make the meson.build easier to read by
using the subdir_done function to quit early.

Signed-off-by: Bruce Richardson 
---
 doc/guides/meson.build | 44 ++
 1 file changed, 23 insertions(+), 21 deletions(-)

diff --git a/doc/guides/meson.build b/doc/guides/meson.build
index 7931ef3bb..80c21d168 100644
--- a/doc/guides/meson.build
+++ b/doc/guides/meson.build
@@ -3,26 +3,28 @@
 
 sphinx = find_program('sphinx-build', required: get_option('enable_docs'))
 
-if sphinx.found()
-   htmldir = join_paths('share', 'doc', 'dpdk')
-   html_guides_build = custom_target('html_guides_build',
-   input: meson.current_source_dir(),
-   output: 'guides',
-   command: [sphinx, '-b', 'html',
-   '-d', meson.current_build_dir() + '/.doctrees',
-   '@INPUT@', meson.current_build_dir() + '/guides'],
-   build_by_default: get_option('enable_docs'),
-   install: get_option('enable_docs'),
-   install_dir: htmldir)
+if not sphinx.found()
+   subdir_done()
+endif
 
-   doc_targets += html_guides_build
-   doc_target_names += 'HTML_Guides'
+htmldir = join_paths('share', 'doc', 'dpdk')
+html_guides = custom_target('html_guides',
+   input: meson.current_source_dir(),
+   output: 'guides',
+   command: [sphinx, '-b', 'html',
+   '-d', meson.current_build_dir() + '/.doctrees',
+   '@INPUT@', meson.current_build_dir() + '/guides'],
+   build_by_default: get_option('enable_docs'),
+   install: get_option('enable_docs'),
+   install_dir: htmldir)
 
-   # sphinx leaves a .buildinfo in the target directory, which we don't
-   # want to install. Note that sh -c has to be used, otherwise the
-   # env var does not get expanded if calling rm/install directly.
-   meson.add_install_script('sh', '-c',
-   'rm -f 
$MESON_INSTALL_DESTDIR_PREFIX/share/doc/dpdk/guides/.buildinfo')
-   meson.add_install_script('sh', '-c',
-   'install -D -m0644 $MESON_SOURCE_ROOT/doc/guides/custom.css 
$MESON_INSTALL_DESTDIR_PREFIX/share/doc/dpdk/guides/_static/css/custom.css')
-endif
+doc_targets += html_guides
+doc_target_names += 'HTML_Guides'
+
+# sphinx leaves a .buildinfo in the target directory, which we don't
+# want to install. Note that sh -c has to be used, otherwise the
+# env var does not get expanded if calling rm/install directly.
+meson.add_install_script('sh', '-c',
+   'rm -f $MESON_INSTALL_DESTDIR_PREFIX/share/doc/dpdk/guides/.buildinfo')
+meson.add_install_script('sh', '-c',
+   'install -D -m0644 $MESON_SOURCE_ROOT/doc/guides/custom.css 
$MESON_INSTALL_DESTDIR_PREFIX/share/doc/dpdk/guides/_static/css/custom.css')
-- 
2.24.1

[dpdk-dev] [PATCH 5/6] doc/guides: rebuild with meson whenever a file changes

[Bruce Richardson]

Add proper support for calling sphinx whenever a file in the doc
directory changes. This is accomplished by using a wrapper script
for sphinx, which runs sphinx but also emits a gcc-format dependency
file listing all the doc files. This is used by ninja so that any
change to the doc files triggers a rebuild of the docs.

Signed-off-by: Bruce Richardson 
---
 buildtools/call-sphinx-build.py | 29 +
 buildtools/meson.build  |  6 --
 doc/guides/meson.build  | 22 --
 3 files changed, 41 insertions(+), 16 deletions(-)
 create mode 100755 buildtools/call-sphinx-build.py

diff --git a/buildtools/call-sphinx-build.py b/buildtools/call-sphinx-build.py
new file mode 100755
index 0..027317b9b
--- /dev/null
+++ b/buildtools/call-sphinx-build.py
@@ -0,0 +1,29 @@
+#! /usr/bin/env python3
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2019 Intel Corporation
+#
+
+import sys
+import os
+import os.path
+import subprocess
+
+sphinx = sys.argv[1]
+src = sys.argv[2]
+dst = sys.argv[3]
+depfile = os.path.join(dst,'.html.d')
+
+# find all the files sphinx will process so we can write them as dependencies
+srcfiles = []
+for root, dirs, files in os.walk(src):
+for f in files:
+srcfiles.append(os.path.join(root, f))
+
+# run sphinx, putting the html output in a "html" directory
+subprocess.run([sphinx, '-j', 'auto', '-b', 'html', src,
+os.path.join(dst, 'html')], check = True)
+
+# create a gcc format .d file giving all the dependencies of this doc build
+with open(depfile, 'w') as d:
+d.write('html: ' + ' '.join(srcfiles) + '\n')
+subprocess.run(['cp', '-f', depfile, '/tmp'])
diff --git a/buildtools/meson.build b/buildtools/meson.build
index 6ef2c5721..cd1d05403 100644
--- a/buildtools/meson.build
+++ b/buildtools/meson.build
@@ -10,10 +10,12 @@ check_experimental_syms = 
find_program('check-experimental-syms.sh')
 # set up map-to-def script using python, either built-in or external
 python3 = import('python').find_installation(required: false)
 if python3.found()
-   map_to_def_cmd = [python3, files('map_to_def.py')]
+   py3 = [python3]
 else
-   map_to_def_cmd = ['meson', 'runpython', files('map_to_def.py')]
+   py3 = ['meson', 'runpython']
 endif
+map_to_def_cmd = py3 + files('map_to_def.py')
+sphinx_wrapper = py3 + files('call-sphinx-build.py')
 
 # stable ABI always starts with "DPDK_"
 is_experimental_cmd = [find_program('grep', 'findstr'), '^DPDK_']
diff --git a/doc/guides/meson.build b/doc/guides/meson.build
index 80c21d168..732e7ad3a 100644
--- a/doc/guides/meson.build
+++ b/doc/guides/meson.build
@@ -7,24 +7,18 @@ if not sphinx.found()
subdir_done()
 endif
 
-htmldir = join_paths('share', 'doc', 'dpdk')
+htmldir = join_paths(get_option('datadir'), 'doc', 'dpdk')
 html_guides = custom_target('html_guides',
-   input: meson.current_source_dir(),
-   output: 'guides',
-   command: [sphinx, '-b', 'html',
-   '-d', meson.current_build_dir() + '/.doctrees',
-   '@INPUT@', meson.current_build_dir() + '/guides'],
+   input: files('index.rst'),
+   output: 'html',
+   command: [sphinx_wrapper, sphinx, meson.current_source_dir(), 
meson.current_build_dir()],
+   depfile: '.html.d',
build_by_default: get_option('enable_docs'),
install: get_option('enable_docs'),
install_dir: htmldir)
 
+install_data(files('custom.css'),
+   install_dir: join_paths(htmldir,'_static', 'css'))
+
 doc_targets += html_guides
 doc_target_names += 'HTML_Guides'
-
-# sphinx leaves a .buildinfo in the target directory, which we don't
-# want to install. Note that sh -c has to be used, otherwise the
-# env var does not get expanded if calling rm/install directly.
-meson.add_install_script('sh', '-c',
-   'rm -f $MESON_INSTALL_DESTDIR_PREFIX/share/doc/dpdk/guides/.buildinfo')
-meson.add_install_script('sh', '-c',
-   'install -D -m0644 $MESON_SOURCE_ROOT/doc/guides/custom.css 
$MESON_INSTALL_DESTDIR_PREFIX/share/doc/dpdk/guides/_static/css/custom.css')
-- 
2.24.1

Re: [dpdk-dev] [PATCH 01/14] examples/ipsec-secgw: add default rte_flow for inline Rx

[Lukas Bartosik]

Hi Konstantin,

Please see my question inline.

Thanks,
Lukasz

On 16.12.2019 16:58, Anoob Joseph wrote:
> Hi Konstantin,
> 
> Thanks for the review. Please see inline.
> 
> Thanks,
> Anoob
> 
>> -Original Message-
>> From: Ananyev, Konstantin 
>> Sent: Monday, December 16, 2019 7:51 PM
>> To: Anoob Joseph ; Akhil Goyal ;
>> Nicolau, Radu ; Thomas Monjalon
>> 
>> Cc: Ankur Dwivedi ; Jerin Jacob Kollanukkaran
>> ; Narayana Prasad Raju Athreya
>> ; Archana Muniganti ;
>> Tejasree Kondoj ; Vamsi Krishna Attunuru
>> ; Lukas Bartosik ;
>> dev@dpdk.org
>> Subject: [EXT] RE: [PATCH 01/14] examples/ipsec-secgw: add default rte_flow
>> for inline Rx
>>
>> External Email
>>
>> --
>>
>>> From: Ankur Dwivedi 
>>>
>>> The default flow created would enable security processing on all ESP
>>> packets. If the default flow is created, SA based rte_flow creation
>>> would be skipped.
>>
>> I suppose that one depends on:
>>  http://patches.dpdk.org/patch/63621/
>>  http://patches.dpdk.org/cover/63625/
>> to work as expected?
>> If so probably worth to mention in that header or in cover letter (or both).
> 
> [Anoob] Yes. Usually the dependency is not added in the commit header. I'll 
> update the v2 cover letter with such details.
>  
>>
>>>
>>> Signed-off-by: Ankur Dwivedi 
>>> Signed-off-by: Anoob Joseph 
>>> ---
>>>  examples/ipsec-secgw/ipsec-secgw.c | 56
>> ++
>>>  examples/ipsec-secgw/ipsec.c   |  8 ++
>>>  examples/ipsec-secgw/ipsec.h   |  6 
>>>  3 files changed, 70 insertions(+)
>>>
>>> diff --git a/examples/ipsec-secgw/ipsec-secgw.c
>>> b/examples/ipsec-secgw/ipsec-secgw.c
>>> index 3b5aaf6..7506922 100644
>>> --- a/examples/ipsec-secgw/ipsec-secgw.c
>>> +++ b/examples/ipsec-secgw/ipsec-secgw.c
>>> @@ -128,6 +128,8 @@ struct ethaddr_info
>> ethaddr_tbl[RTE_MAX_ETHPORTS] = {
>>> { 0, ETHADDR(0x00, 0x16, 0x3e, 0x49, 0x9e, 0xdd) }  };
>>>
>>> +struct flow_info flow_info_tbl[RTE_MAX_ETHPORTS];
>>
>> Need to be initialized with zeroes somewhere.
> 
> [Anoob] Will add it in v2.

[Lukasz] Is there any reason to initialize flow_info_tbl explicitly with zeros 
? As a global array it will be automatically
zeroized by the compiler.

>>
>>> +
>>>  #define CMD_LINE_OPT_CONFIG"config"
>>>  #define CMD_LINE_OPT_SINGLE_SA "single-sa"
>>>  #define CMD_LINE_OPT_CRYPTODEV_MASK"cryptodev_mask"
>>> @@ -2406,6 +2408,55 @@ reassemble_init(void)
>>> return rc;
>>>  }
>>>
>>> +static int
>>> +create_default_ipsec_flow(uint16_t port_id, uint64_t rx_offloads) {
>>> +   int ret = 0;
>>> +
>>> +   /* Add the default ipsec flow to detect all ESP packets for rx */
>>> +   if (rx_offloads & DEV_RX_OFFLOAD_SECURITY) {
>>> +   struct rte_flow_action action[2];
>>> +   struct rte_flow_item pattern[2];
>>> +   struct rte_flow_attr attr = {0};
>>> +   struct rte_flow_error err;
>>> +   struct rte_flow *flow;
>>> +
>>> +   pattern[0].type = RTE_FLOW_ITEM_TYPE_ESP;
>>> +   pattern[0].spec = NULL;
>>> +   pattern[0].mask = NULL;
>>> +   pattern[0].last = NULL;
>>> +   pattern[1].type = RTE_FLOW_ITEM_TYPE_END;
>>> +
>>> +   action[0].type = RTE_FLOW_ACTION_TYPE_SECURITY;
>>> +   action[0].conf = NULL;
>>> +   action[1].type = RTE_FLOW_ACTION_TYPE_END;
>>> +   action[1].conf = NULL;
>>> +
>>> +   attr.egress = 0;
>>> +   attr.ingress = 1;
>>> +
>>> +   ret = rte_flow_validate(port_id, &attr, pattern, action, &err);
>>> +   if (ret) {
>>
>> As I understand, flow_validate() is used here to query does this capability
>> (multiple security sessions for same flow) is supported by PMD/HW?
>> If so, then probably no need for error message if it doesn't.
> 
> [Anoob] Yes. Will remove the error log.
>  
>>
>>> +   RTE_LOG(ERR, IPSEC,
>>> +   "Failed to validate ipsec flow %s\n",
>>> +   err.message);
>>> +   goto exit;
>>> +   }
>>> +
>>> +   flow = rte_flow_create(port_id, &attr, pattern, action, &err);
>>
>> Same question as for http://patches.dpdk.org/patch/63621/ , why do you need 
>> it at all?
>> What it will enable/disable?
> 
> [Anoob] Your followup question there accurately describes the usage. If the 
> application wants to enable H/w IPsec processing only on a specific SPI 
> range, it will be allowed so with this kind of flow.
> 
> Let's say, application wants to allow H/w processing only for SPI 1-8192. In 
> that case, either 8192 rte_flows need to be created, or one rte_flow rule 
> with SPI 1-8192 range can be created. Any SPI outside the range won't match 
> the rule and rte_flow could have further rules to act on such packets.
> 
>>
>>> +   if (flow == NULL) {
>>> +   RTE_LOG(ERR, IPSEC,
>>> +   "

[dpdk-dev] [PATCH v2 0/6] meson build improvements

[Bruce Richardson]

These patches make some improvements to the meson build, particularly
for documentation. They also remove many, but not all warnings issued by
meson e.g. warnings about newer features unsupported in baseline.

The biggest change is to improve the handling of the guide html docs.
The change here is more significant, and the doc build now uses a
wrapper script around sphinx. This wrapper script allows us to output
correct dependency information for the sphinx build in a .d file. This
.d file is processed by ninja (not meson) on build, so that any changes
to doc files trigger a rebuild to the guides using sphinx.

For now, the two patches which remove the meson version warnings are
CC'ed to stable for backport, theoretically this who set could be
backported if so desired, as all changes could be considered fixes to
some degree or other, and nothing introduces a whole new feature.

Note: for completeness and simplicity, previously submitted patch
http://patches.dpdk.org/patch/64189/ is included in this set, and will
be marked superceded in patchwork.

V2: resend to correct email addresses

Bruce Richardson (6):
  kernel/linux/kni: fix meson warning about console keyword
  build: skip processing docs folder if docs disabled
  doc/api: fix warning with meson build
  doc/guides: reduce whitespace in meson build file
  doc/guides: rebuild with meson whenever a file changes
  doc/api: reduce indentation in meson build file

 buildtools/call-sphinx-build.py | 29 ++
 buildtools/meson.build  |  6 +-
 doc/api/meson.build | 99 +
 doc/guides/meson.build  | 38 ++---
 doc/meson.build |  4 ++
 kernel/linux/kni/meson.build|  1 -
 6 files changed, 104 insertions(+), 73 deletions(-)
 create mode 100755 buildtools/call-sphinx-build.py

-- 
2.24.1

[dpdk-dev] [PATCH v2 2/6] build: skip processing docs folder if docs disabled

[Bruce Richardson]

While each target is set to be ignored if the docs are disabled in the
meson build, there is little reason to process the docs folder at all.

Signed-off-by: Bruce Richardson 
---
 doc/meson.build | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/meson.build b/doc/meson.build
index c5410d85d..c49ec8476 100644
--- a/doc/meson.build
+++ b/doc/meson.build
@@ -1,6 +1,10 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2018 Luca Boccassi 
 
+if not get_option('enable_docs')
+   subdir_done()
+endif
+
 doc_targets = []
 doc_target_names = []
 subdir('api')
-- 
2.24.1

[dpdk-dev] [PATCH v2 0/6] meson build improvements

[Bruce Richardson]

These patches make some improvements to the meson build, particularly
for documentation. They also remove many, but not all warnings issued by
meson e.g. warnings about newer features unsupported in baseline.

The biggest change is to improve the handling of the guide html docs.
The change here is more significant, and the doc build now uses a
wrapper script around sphinx. This wrapper script allows us to output
correct dependency information for the sphinx build in a .d file. This
.d file is processed by ninja (not meson) on build, so that any changes
to doc files trigger a rebuild to the guides using sphinx.

For now, the two patches which remove the meson version warnings are
CC'ed to stable for backport, theoretically this who set could be
backported if so desired, as all changes could be considered fixes to
some degree or other, and nothing introduces a whole new feature.

Note: for completeness and simplicity, previously submitted patch
http://patches.dpdk.org/patch/64189/ is included in this set, and will
be marked superceded in patchwork.

V2: resend to correct email addresses

Bruce Richardson (6):
  kernel/linux/kni: fix meson warning about console keyword
  build: skip processing docs folder if docs disabled
  doc/api: fix warning with meson build
  doc/guides: reduce whitespace in meson build file
  doc/guides: rebuild with meson whenever a file changes
  doc/api: reduce indentation in meson build file

 buildtools/call-sphinx-build.py | 29 ++
 buildtools/meson.build  |  6 +-
 doc/api/meson.build | 99 +
 doc/guides/meson.build  | 38 ++---
 doc/meson.build |  4 ++
 kernel/linux/kni/meson.build|  1 -
 6 files changed, 104 insertions(+), 73 deletions(-)
 create mode 100755 buildtools/call-sphinx-build.py

-- 
2.24.1

[dpdk-dev] [PATCH v2 5/6] doc/guides: rebuild with meson whenever a file changes

[Bruce Richardson]

Add proper support for calling sphinx whenever a file in the doc
directory changes. This is accomplished by using a wrapper script
for sphinx, which runs sphinx but also emits a gcc-format dependency
file listing all the doc files. This is used by ninja so that any
change to the doc files triggers a rebuild of the docs.

Signed-off-by: Bruce Richardson 
---
 buildtools/call-sphinx-build.py | 29 +
 buildtools/meson.build  |  6 --
 doc/guides/meson.build  | 22 --
 3 files changed, 41 insertions(+), 16 deletions(-)
 create mode 100755 buildtools/call-sphinx-build.py

diff --git a/buildtools/call-sphinx-build.py b/buildtools/call-sphinx-build.py
new file mode 100755
index 0..027317b9b
--- /dev/null
+++ b/buildtools/call-sphinx-build.py
@@ -0,0 +1,29 @@
+#! /usr/bin/env python3
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2019 Intel Corporation
+#
+
+import sys
+import os
+import os.path
+import subprocess
+
+sphinx = sys.argv[1]
+src = sys.argv[2]
+dst = sys.argv[3]
+depfile = os.path.join(dst,'.html.d')
+
+# find all the files sphinx will process so we can write them as dependencies
+srcfiles = []
+for root, dirs, files in os.walk(src):
+for f in files:
+srcfiles.append(os.path.join(root, f))
+
+# run sphinx, putting the html output in a "html" directory
+subprocess.run([sphinx, '-j', 'auto', '-b', 'html', src,
+os.path.join(dst, 'html')], check = True)
+
+# create a gcc format .d file giving all the dependencies of this doc build
+with open(depfile, 'w') as d:
+d.write('html: ' + ' '.join(srcfiles) + '\n')
+subprocess.run(['cp', '-f', depfile, '/tmp'])
diff --git a/buildtools/meson.build b/buildtools/meson.build
index 6ef2c5721..cd1d05403 100644
--- a/buildtools/meson.build
+++ b/buildtools/meson.build
@@ -10,10 +10,12 @@ check_experimental_syms = 
find_program('check-experimental-syms.sh')
 # set up map-to-def script using python, either built-in or external
 python3 = import('python').find_installation(required: false)
 if python3.found()
-   map_to_def_cmd = [python3, files('map_to_def.py')]
+   py3 = [python3]
 else
-   map_to_def_cmd = ['meson', 'runpython', files('map_to_def.py')]
+   py3 = ['meson', 'runpython']
 endif
+map_to_def_cmd = py3 + files('map_to_def.py')
+sphinx_wrapper = py3 + files('call-sphinx-build.py')
 
 # stable ABI always starts with "DPDK_"
 is_experimental_cmd = [find_program('grep', 'findstr'), '^DPDK_']
diff --git a/doc/guides/meson.build b/doc/guides/meson.build
index 80c21d168..732e7ad3a 100644
--- a/doc/guides/meson.build
+++ b/doc/guides/meson.build
@@ -7,24 +7,18 @@ if not sphinx.found()
subdir_done()
 endif
 
-htmldir = join_paths('share', 'doc', 'dpdk')
+htmldir = join_paths(get_option('datadir'), 'doc', 'dpdk')
 html_guides = custom_target('html_guides',
-   input: meson.current_source_dir(),
-   output: 'guides',
-   command: [sphinx, '-b', 'html',
-   '-d', meson.current_build_dir() + '/.doctrees',
-   '@INPUT@', meson.current_build_dir() + '/guides'],
+   input: files('index.rst'),
+   output: 'html',
+   command: [sphinx_wrapper, sphinx, meson.current_source_dir(), 
meson.current_build_dir()],
+   depfile: '.html.d',
build_by_default: get_option('enable_docs'),
install: get_option('enable_docs'),
install_dir: htmldir)
 
+install_data(files('custom.css'),
+   install_dir: join_paths(htmldir,'_static', 'css'))
+
 doc_targets += html_guides
 doc_target_names += 'HTML_Guides'
-
-# sphinx leaves a .buildinfo in the target directory, which we don't
-# want to install. Note that sh -c has to be used, otherwise the
-# env var does not get expanded if calling rm/install directly.
-meson.add_install_script('sh', '-c',
-   'rm -f $MESON_INSTALL_DESTDIR_PREFIX/share/doc/dpdk/guides/.buildinfo')
-meson.add_install_script('sh', '-c',
-   'install -D -m0644 $MESON_SOURCE_ROOT/doc/guides/custom.css 
$MESON_INSTALL_DESTDIR_PREFIX/share/doc/dpdk/guides/_static/css/custom.css')
-- 
2.24.1

[dpdk-dev] [PATCH v2 1/6] kernel/linux/kni: fix meson warning about console keyword

[Bruce Richardson]

Since kni no longer includes the ethtool code and so is faster to build, we
no longer need the console parameter to have incremental screen updates as
it builds. Therefore, we drop the keyword which removes the warning.

Fixes: b78f32cff94d ("kni: support meson build")
Cc: bl...@debian.org

Signed-off-by: Bruce Richardson 
---
 kernel/linux/kni/meson.build | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/linux/kni/meson.build b/kernel/linux/kni/meson.build
index 955eec949..f93e97fa0 100644
--- a/kernel/linux/kni/meson.build
+++ b/kernel/linux/kni/meson.build
@@ -23,7 +23,6 @@ custom_target('rte_kni',
' -I' + meson.current_source_dir(),
'modules'],
depends: kni_mkfile,
-   console: true,
install: true,
install_dir: kernel_dir + '/extra/dpdk',
build_by_default: get_option('enable_kmods'))
-- 
2.24.1

[dpdk-dev] [PATCH v2 3/6] doc/api: fix warning with meson build

[Bruce Richardson]

The install parameter to configure_file is new in 0.50 and generates a
warning since it is newer than our minimum version of 0.47.1. The
parameter, however, is unneeded as the documentation states:

"When omitted it defaults to true when install_dir is set and not empty,
false otherwise."

Given that install_dir is not set for this file, install defaults to false
so no need to explicitly specify it.

Fixes: 720b14db3ae2 ("build: generate API documentation with meson")
Cc: bl...@debian.org

Signed-off-by: Bruce Richardson 
---
 doc/api/meson.build | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/doc/api/meson.build b/doc/api/meson.build
index 1c48b7672..23a7dfc75 100644
--- a/doc/api/meson.build
+++ b/doc/api/meson.build
@@ -38,8 +38,7 @@ if doxygen.found()
 
doxy_conf = configure_file(input: 'doxy-api.conf.in',
output: 'doxy-api.conf',
-   configuration: cdata,
-   install: false)
+   configuration: cdata)
 
doxy_build = custom_target('doxygen',
depends: example,
-- 
2.24.1

[dpdk-dev] [PATCH v2 4/6] doc/guides: reduce whitespace in meson build file

[Bruce Richardson]

For building the guides, we can make the meson.build easier to read by
using the subdir_done function to quit early.

Signed-off-by: Bruce Richardson 
---
 doc/guides/meson.build | 44 ++
 1 file changed, 23 insertions(+), 21 deletions(-)

diff --git a/doc/guides/meson.build b/doc/guides/meson.build
index 7931ef3bb..80c21d168 100644
--- a/doc/guides/meson.build
+++ b/doc/guides/meson.build
@@ -3,26 +3,28 @@
 
 sphinx = find_program('sphinx-build', required: get_option('enable_docs'))
 
-if sphinx.found()
-   htmldir = join_paths('share', 'doc', 'dpdk')
-   html_guides_build = custom_target('html_guides_build',
-   input: meson.current_source_dir(),
-   output: 'guides',
-   command: [sphinx, '-b', 'html',
-   '-d', meson.current_build_dir() + '/.doctrees',
-   '@INPUT@', meson.current_build_dir() + '/guides'],
-   build_by_default: get_option('enable_docs'),
-   install: get_option('enable_docs'),
-   install_dir: htmldir)
+if not sphinx.found()
+   subdir_done()
+endif
 
-   doc_targets += html_guides_build
-   doc_target_names += 'HTML_Guides'
+htmldir = join_paths('share', 'doc', 'dpdk')
+html_guides = custom_target('html_guides',
+   input: meson.current_source_dir(),
+   output: 'guides',
+   command: [sphinx, '-b', 'html',
+   '-d', meson.current_build_dir() + '/.doctrees',
+   '@INPUT@', meson.current_build_dir() + '/guides'],
+   build_by_default: get_option('enable_docs'),
+   install: get_option('enable_docs'),
+   install_dir: htmldir)
 
-   # sphinx leaves a .buildinfo in the target directory, which we don't
-   # want to install. Note that sh -c has to be used, otherwise the
-   # env var does not get expanded if calling rm/install directly.
-   meson.add_install_script('sh', '-c',
-   'rm -f 
$MESON_INSTALL_DESTDIR_PREFIX/share/doc/dpdk/guides/.buildinfo')
-   meson.add_install_script('sh', '-c',
-   'install -D -m0644 $MESON_SOURCE_ROOT/doc/guides/custom.css 
$MESON_INSTALL_DESTDIR_PREFIX/share/doc/dpdk/guides/_static/css/custom.css')
-endif
+doc_targets += html_guides
+doc_target_names += 'HTML_Guides'
+
+# sphinx leaves a .buildinfo in the target directory, which we don't
+# want to install. Note that sh -c has to be used, otherwise the
+# env var does not get expanded if calling rm/install directly.
+meson.add_install_script('sh', '-c',
+   'rm -f $MESON_INSTALL_DESTDIR_PREFIX/share/doc/dpdk/guides/.buildinfo')
+meson.add_install_script('sh', '-c',
+   'install -D -m0644 $MESON_SOURCE_ROOT/doc/guides/custom.css 
$MESON_INSTALL_DESTDIR_PREFIX/share/doc/dpdk/guides/_static/css/custom.css')
-- 
2.24.1

[dpdk-dev] [PATCH v2 6/6] doc/api: reduce indentation in meson build file

[Bruce Richardson]

When building the API docs, we can make the meson.build file easier to
read, and allow more code per line, by using subdir_done() to quit early.

Signed-off-by: Bruce Richardson 
---
 doc/api/meson.build | 98 +++--
 1 file changed, 50 insertions(+), 48 deletions(-)

diff --git a/doc/api/meson.build b/doc/api/meson.build
index 23a7dfc75..c72b880e1 100644
--- a/doc/api/meson.build
+++ b/doc/api/meson.build
@@ -3,52 +3,54 @@
 
 doxygen = find_program('doxygen', required: get_option('enable_docs'))
 
-if doxygen.found()
-   # due to the CSS customisation script, which needs to run on a file that
-   # is in a subdirectory that is created at build time and thus it cannot
-   # be an individual custom_target, we need to wrap the doxygen call in a
-   # script to run the CSS modification afterwards
-   generate_doxygen = find_program('generate_doxygen.sh')
-   generate_examples = find_program('generate_examples.sh')
-   generate_css = find_program('doxy-html-custom.sh')
-
-   inputdir = join_paths(meson.source_root(), 'examples')
-   htmldir = join_paths('share', 'doc', 'dpdk')
-
-   # due to the following bug: 
https://github.com/mesonbuild/meson/issues/4107
-   # if install is set to true it will override build_by_default and it 
will
-   # cause the target to always be built. If install were to be always set 
to
-   # false it would be impossible to install the docs.
-   # So use a configure option for now.
-   example = custom_target('examples.dox',
-   input: inputdir,
-   output: 'examples.dox',
-   command: [generate_examples, '@INPUT@', '@OUTPUT@'],
-   install: get_option('enable_docs'),
-   install_dir: htmldir,
-   build_by_default: get_option('enable_docs'))
-
-   cdata = configuration_data()
-   cdata.set('VERSION', meson.project_version())
-   cdata.set('API_EXAMPLES', join_paths(meson.build_root(), 'doc', 'api', 
'examples.dox'))
-   cdata.set('OUTPUT', join_paths(meson.build_root(), 'doc', 'api'))
-   cdata.set('HTML_OUTPUT', 'api')
-   cdata.set('TOPDIR', meson.source_root())
-   cdata.set('STRIP_FROM_PATH', meson.source_root())
-
-   doxy_conf = configure_file(input: 'doxy-api.conf.in',
-   output: 'doxy-api.conf',
-   configuration: cdata)
-
-   doxy_build = custom_target('doxygen',
-   depends: example,
-   input: doxy_conf,
-   output: 'api',
-   command: [generate_doxygen, '@INPUT@', '@OUTPUT@', 
generate_css],
-   install: get_option('enable_docs'),
-   install_dir: htmldir,
-   build_by_default: get_option('enable_docs'))
-
-   doc_targets += doxy_build
-   doc_target_names += 'Doxygen_API'
+if not doxygen.found()
+  subdir_done()
 endif
+
+# due to the CSS customisation script, which needs to run on a file that
+# is in a subdirectory that is created at build time and thus it cannot
+# be an individual custom_target, we need to wrap the doxygen call in a
+# script to run the CSS modification afterwards
+generate_doxygen = find_program('generate_doxygen.sh')
+generate_examples = find_program('generate_examples.sh')
+generate_css = find_program('doxy-html-custom.sh')
+
+inputdir = join_paths(meson.source_root(), 'examples')
+htmldir = join_paths('share', 'doc', 'dpdk')
+
+# due to the following bug: https://github.com/mesonbuild/meson/issues/4107
+# if install is set to true it will override build_by_default and it will
+# cause the target to always be built. If install were to be always set to
+# false it would be impossible to install the docs.
+# So use a configure option for now.
+example = custom_target('examples.dox',
+   input: inputdir,
+   output: 'examples.dox',
+   command: [generate_examples, '@INPUT@', '@OUTPUT@'],
+   install: get_option('enable_docs'),
+   install_dir: htmldir,
+   build_by_default: get_option('enable_docs'))
+
+cdata = configuration_data()
+cdata.set('VERSION', meson.project_version())
+cdata.set('API_EXAMPLES', join_paths(meson.build_root(), 'doc', 'api', 
'examples.dox'))
+cdata.set('OUTPUT', join_paths(meson.build_root(), 'doc', 'api'))
+cdata.set('HTML_OUTPUT', 'api')
+cdata.set('TOPDIR', meson.source_root())
+cdata.set('STRIP_FROM_PATH', meson.source_root())
+
+doxy_conf = configure_file(input: 'doxy-api.conf.in',
+   output: 'doxy-api.conf',
+   configuration: cdata)
+
+doxy_build = custom_target('doxygen',
+   depends: example,
+   input: doxy_conf,
+   output: 'api',
+   command: [generate_doxygen, '@INPUT@', '@OUTPUT@', generate_css],
+   install: get_option('enable_docs'),
+   install_dir: htmldir,
+   build_by_default: get_option('enable_docs'))
+
+doc_targets += doxy_build
+doc_target_names += 'Doxygen_API'
-- 
2.24.1

[dpdk-dev] [PATCH v3 3/9] net/i40e: improve RSS debug

[Bernard Iremonger]

improve RSS debug in i40e_ethdev.c

Signed-off-by: Bernard Iremonger 
---
 drivers/net/i40e/i40e_ethdev.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 5999c96..5f1cf8a 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -8679,7 +8679,9 @@ i40e_pf_config_rss(struct i40e_pf *pf)
num);
 
if (num == 0) {
-   PMD_INIT_LOG(ERR, "No PF queues are configured to enable RSS");
+   PMD_INIT_LOG(ERR,
+   "No PF queues are configured to enable RSS for port %u",
+   pf->dev_data->port_id);
return -ENOTSUP;
}
 
@@ -12840,7 +12842,9 @@ i40e_config_rss_filter(struct i40e_pf *pf,
num);
 
if (num == 0) {
-   PMD_DRV_LOG(ERR, "No PF queues are configured to enable RSS");
+   PMD_DRV_LOG(ERR,
+   "No PF queues are configured to enable RSS for port %u",
+   pf->dev_data->port_id);
return -ENOTSUP;
}
 
-- 
2.7.4

[dpdk-dev] [PATCH v3 1/9] app/testpmd: parse flow command line for ESP

[Bernard Iremonger]

add ITEM_ESP
add ITEM_ESP_SPI
add debug to cmdline_flow.c

Signed-off-by: Bernard Iremonger 
Acked-by: Ori Kam 
---
 app/test-pmd/cmdline_flow.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 9643148..9c6edb8 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -6075,9 +6075,6 @@ cmd_flow_tok(cmdline_parse_token_hdr_t **hdr,
 static void
 cmd_flow_parsed(const struct buffer *in)
 {
-   printf("Flow command line parsed successfully for command=%d.\n",
-   in->command);
-
switch (in->command) {
case VALIDATE:
port_flow_validate(in->port, &in->args.vc.attr,
@@ -6261,6 +6258,7 @@ flow_item_default_mask(const struct rte_flow_item *item)
break;
case RTE_FLOW_ITEM_TYPE_PPPOE_PROTO_ID:
mask = &rte_flow_item_pppoe_proto_id_mask;
+   break;
case RTE_FLOW_ITEM_TYPE_ESP:
mask = &rte_flow_item_esp_mask;
break;
-- 
2.7.4

[dpdk-dev] [PATCH v3 2/9] app/testpmd: dump Rx and Tx mbuf

[Bernard Iremonger]

add call to rte_pktmbuf_dump() in dump_pkt_burst in util.c

Signed-off-by: Bernard Iremonger 
---
 app/test-pmd/util.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/app/test-pmd/util.c b/app/test-pmd/util.c
index b514be5..bf03873 100644
--- a/app/test-pmd/util.c
+++ b/app/test-pmd/util.c
@@ -158,6 +158,7 @@ dump_pkt_burst(uint16_t port_id, uint16_t queue, struct 
rte_mbuf *pkts[],
printf("  ol_flags: %s\n", buf);
if (rte_mbuf_check(mb, 1, &reason) < 0)
printf("INVALID mbuf: %s\n", reason);
+   rte_pktmbuf_dump(stdout, pkts[i], pkts[i]->data_len);
}
 }
 
-- 
2.7.4

[dpdk-dev] [PATCH v3 8/9] doc: release note for ESP

[Bernard Iremonger]

Release note for ESP support on the i40e PMD.
Release note for ESP support on testpmd.

Signed-off-by: Bernard Iremonger 
---
 doc/guides/rel_notes/release_20_02.rst | 9 +
 1 file changed, 9 insertions(+)

diff --git a/doc/guides/rel_notes/release_20_02.rst 
b/doc/guides/rel_notes/release_20_02.rst
index 0eaa45a..367c980 100644
--- a/doc/guides/rel_notes/release_20_02.rst
+++ b/doc/guides/rel_notes/release_20_02.rst
@@ -56,6 +56,15 @@ New Features
  Also, make sure to start the actual text at the margin.
  =
 
+* **Updated i40e driver to support ESP.**
+
+  Updated the i40e PMD to support ESP-AH supporting profiles which can be
+  programmed by the dynamic device personalization (DDP) process.
+
+* **Updated testpmd to support ESP flows.**
+
+  Added support for ESP rte_flow patterns to the testpmd application.
+
 
 Removed Items
 -
-- 
2.7.4

[dpdk-dev] [PATCH v3 0/9] net/i40e: ESP support

[Bernard Iremonger]

Add support for ESP flows to testpmd.
Improve debug information in testpmd and the i40e PMD.
Process ESP flows on the i40e Flow Director and RSS.

Changes in V3:
-
Added i40e_flow_set_filter_spi() function in i40e_flow.c
Set UDP destination port to 4500 for ESP  in i40e_ethdev.h
Split flow structures into 4 instead of 2 in i40e_ethdev.h 
Dropped extra printf from commandline_flow.c

Changes in V2: 
--
Moved change in app/test-pmd/config.c to a seperate patch.
Added extra parameter to fill_ip6_head() in i40e_fdir.c
set is_udp to false in i40e_flow_fdir_get_pctype_value() in i40e_flow.c

Bernard Iremonger (9):
  app/testpmd: parse flow command line for ESP
  app/testpmd: dump Rx and Tx mbuf
  net/i40e: improve RSS debug
  net/i40e: handle ESP tunnel
  net/i40e: process ESP flows
  net/i40e: display Flow Director packet
  librte_ethdev: add ESP and AH flow types to RSS
  doc: release note for ESP
  doc: update i40e user guide

 app/test-pmd/cmdline_flow.c|   4 +-
 app/test-pmd/util.c|   1 +
 doc/guides/nics/i40e.rst   |   4 +-
 doc/guides/rel_notes/release_20_02.rst |   9 +++
 drivers/net/i40e/i40e_ethdev.c |  52 -
 drivers/net/i40e/i40e_ethdev.h |  38 ++
 drivers/net/i40e/i40e_fdir.c   | 132 +---
 drivers/net/i40e/i40e_flow.c   | 135 -
 drivers/net/i40e/rte_pmd_i40e.c|   3 +-
 lib/librte_ethdev/rte_ethdev.h |  29 ++-
 10 files changed, 385 insertions(+), 22 deletions(-)

-- 
2.7.4

[dpdk-dev] [PATCH v3 6/9] net/i40e: display Flow Director packet

[Bernard Iremonger]

call rte_hexdump in i40e_flow_fdir_construct_pkt() in i40e_fdir.c

Signed-off-by: Bernard Iremonger 
---
 drivers/net/i40e/i40e_fdir.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/i40e/i40e_fdir.c b/drivers/net/i40e/i40e_fdir.c
index 3fa6297..78329d2 100644
--- a/drivers/net/i40e/i40e_fdir.c
+++ b/drivers/net/i40e/i40e_fdir.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "i40e_logs.h"
 #include "base/i40e_type.h"
@@ -805,6 +806,7 @@ i40e_fdir_fill_eth_ip_head(const struct rte_eth_fdir_input 
*fdir_input,
fdir_input->flow_type);
return -1;
}
+   rte_hexdump(stdout, NULL, raw_pkt, len);
return len;
 }
 
@@ -954,7 +956,7 @@ i40e_fdir_construct_pkt(struct i40e_pf *pf,
 &fdir_input->flow_ext.flexbytes[dst],
 size * sizeof(uint16_t));
}
-
+   rte_hexdump(stdout, NULL, raw_pkt, len);
return 0;
 }
 
-- 
2.7.4

[dpdk-dev] [PATCH v3 9/9] doc: update i40e user guide

[Bernard Iremonger]

Update the i40e user guide with ESP information.

Signed-off-by: Bernard Iremonger 
---
 doc/guides/nics/i40e.rst | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 38acf59..5cf34d9 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -457,7 +457,7 @@ which is used to configure hardware by downloading a 
profile to support
 protocols/filters which are not supported by default. The DDP
 functionality requires a NIC firmware version of 6.0 or greater.
 
-Current implementation supports GTP-C/GTP-U/PPPoE/PPPoL2TP,
+Current implementation supports GTP-C/GTP-U/PPPoE/PPPoL2TP/ESP,
 steering can be used with rte_flow API.
 
 GTPv1 package is released, and it can be downloaded from
@@ -466,6 +466,8 @@ https://downloadcenter.intel.com/download/27587.
 PPPoE package is released, and it can be downloaded from
 https://downloadcenter.intel.com/download/28040.
 
+ESP-AH package is not released yet.
+
 Load a profile which supports GTP and store backup profile:
 
 .. code-block:: console
-- 
2.7.4

[dpdk-dev] [PATCH v3 7/9] librte_ethdev: add ESP and AH flow types to RSS

[Bernard Iremonger]

Add flow types for the following PCTYPE's in the DDP ipsec profile:
14: IPV6 ESP
15: IPV4 ESP
16: IPV6 AH
17: IPV4 AH
18: IPV6 UDP ESP
19: IPV4 UDP ESP

Add the following RSS macros for IPsec:
ETH_RSS_ESP
ETH_RSS_AH
ETH_RSS_IPSEC

Signed-off-by: Bernard Iremonger 
---
 lib/librte_ethdev/rte_ethdev.h | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 18a9def..39c89cb 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -484,7 +484,13 @@ struct rte_eth_rss_conf {
 #define RTE_ETH_FLOW_NVGRE  21 /**< NVGRE protocol based flow */
 #define RTE_ETH_FLOW_VXLAN_GPE  22 /**< VXLAN-GPE protocol based flow 
*/
 #define RTE_ETH_FLOW_GTPU   23 /**< GTPU protocol based flow */
-#define RTE_ETH_FLOW_MAX24
+#define RTE_ETH_FLOW_IPV4_AH24 /**< IPv4 AH protocol based flow */
+#define RTE_ETH_FLOW_IPV4_ESP   25 /**< IPv4 ESP protocol based flow */
+#define RTE_ETH_FLOW_IPV4_UDP_ESP   26 /**< IPv4 UDP ESP proto based flow 
*/
+#define RTE_ETH_FLOW_IPV6_AH27 /**< IPv6 AH protocol based flow */
+#define RTE_ETH_FLOW_IPV6_ESP   28 /**< IPv6 ESP protocol based flow */
+#define RTE_ETH_FLOW_IPV6_UDP_ESP   29 /**< IPv6 UDP ESP proto based flow 
*/
+#define RTE_ETH_FLOW_MAX30
 
 /*
  * Below macros are defined for RSS offload types, they can be used to
@@ -511,6 +517,13 @@ struct rte_eth_rss_conf {
 #define ETH_RSS_GENEVE (1ULL << 20)
 #define ETH_RSS_NVGRE  (1ULL << 21)
 #define ETH_RSS_GTPU   (1ULL << 23)
+#define ETH_RSS_IPV4_AH(1ULL << 24)
+#define ETH_RSS_IPV4_ESP   (1ULL << 25)
+#define ETH_RSS_IPV4_UDP_ESP   (1ULL << 26)
+#define ETH_RSS_IPV6_AH(1ULL << 27)
+#define ETH_RSS_IPV6_ESP   (1ULL << 28)
+#define ETH_RSS_IPV6_UDP_ESP   (1ULL << 29)
+
 
 /*
  * We use the following macros to combine with above ETH_RSS_* for
@@ -571,6 +584,20 @@ rte_eth_rss_hf_refine(uint64_t rss_hf)
ETH_RSS_NONFRAG_IPV4_SCTP | \
ETH_RSS_NONFRAG_IPV6_SCTP)
 
+#define ETH_RSS_AH ( \
+   ETH_RSS_IPV4_AH | \
+   ETH_RSS_IPV6_AH)
+
+#define ETH_RSS_ESP ( \
+   ETH_RSS_IPV4_ESP | \
+   ETH_RSS_IPV6_ESP | \
+   ETH_RSS_IPV4_UDP_ESP | \
+   ETH_RSS_IPV6_UDP_ESP)
+
+#define ETH_RSS_IPSEC ( \
+   ETH_RSS_AH | \
+   ETH_RSS_ESP)
+
 #define ETH_RSS_TUNNEL ( \
ETH_RSS_VXLAN  | \
ETH_RSS_GENEVE | \
-- 
2.7.4

[dpdk-dev] [PATCH v3 5/9] net/i40e: process ESP flows

[Bernard Iremonger]

Process ESP flows on Flow Director and RSS.

add eth/ipv4/esp and eth/ipv6/esp patterns
add eth/ipv4/udp/esp and eth/ipv6/esp/udp patterns
add flow structures for above patterns
update i40e_flow_parse_fdir_filter()
add i40e_flow_set_filter_spi()
add fill_ip6_head()
add oip_type in filter
add is_udp in filter
use tenant_id in filter for spi
handle ESP and AH pctypes in ESP-AH profile
update customized code for ESP
hardcode udp destination port to 4500

Signed-off-by: Bernard Iremonger 
---
 drivers/net/i40e/i40e_ethdev.c |  44 +-
 drivers/net/i40e/i40e_ethdev.h |  38 
 drivers/net/i40e/i40e_fdir.c   | 128 +++---
 drivers/net/i40e/i40e_flow.c   | 135 -
 4 files changed, 332 insertions(+), 13 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 5f1cf8a..a462eba 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1106,6 +1106,7 @@ i40e_init_customized_info(struct i40e_pf *pf)
}
 
pf->gtp_support = false;
+   pf->esp_support = false;
 }
 
 void
@@ -12337,6 +12338,7 @@ i40e_update_customized_pctype(struct rte_eth_dev *dev, 
uint8_t *pkg,
}
}
name[strlen(name) - 1] = '\0';
+   PMD_DRV_LOG(INFO, "name = %s\n", name);
if (!strcmp(name, "GTPC"))
new_pctype =
i40e_find_customized_pctype(pf,
@@ -12353,6 +12355,30 @@ i40e_update_customized_pctype(struct rte_eth_dev *dev, 
uint8_t *pkg,
new_pctype =
i40e_find_customized_pctype(pf,
  I40E_CUSTOMIZED_GTPU);
+   else if (!strcmp(name, "IPV4_ESP"))
+   new_pctype =
+   i40e_find_customized_pctype(pf,
+   I40E_CUSTOMIZED_ESP_IPV4);
+   else if (!strcmp(name, "IPV6_ESP"))
+   new_pctype =
+   i40e_find_customized_pctype(pf,
+   I40E_CUSTOMIZED_ESP_IPV6);
+   else if (!strcmp(name, "IPV4_UDP_ESP"))
+   new_pctype =
+   i40e_find_customized_pctype(pf,
+   I40E_CUSTOMIZED_ESP_IPV4_UDP);
+   else if (!strcmp(name, "IPV6_UDP_ESP"))
+   new_pctype =
+   i40e_find_customized_pctype(pf,
+   I40E_CUSTOMIZED_ESP_IPV6_UDP);
+   else if (!strcmp(name, "IPV4_AH"))
+   new_pctype =
+   i40e_find_customized_pctype(pf,
+   I40E_CUSTOMIZED_AH_IPV4);
+   else if (!strcmp(name, "IPV6_AH"))
+   new_pctype =
+   i40e_find_customized_pctype(pf,
+   I40E_CUSTOMIZED_AH_IPV6);
if (new_pctype) {
if (op == RTE_PMD_I40E_PKG_OP_WR_ADD) {
new_pctype->pctype = pctype_value;
@@ -12448,6 +12474,7 @@ i40e_update_customized_ptype(struct rte_eth_dev *dev, 
uint8_t *pkg,
continue;
memset(name, 0, sizeof(name));
strcpy(name, proto[n].name);
+   PMD_DRV_LOG(INFO, "name = %s\n", name);
if (!strncasecmp(name, "PPPOE", 5))
ptype_mapping[i].sw_ptype |=
RTE_PTYPE_L2_ETHER_PPPOE;
@@ -12541,6 +12568,10 @@ i40e_update_customized_ptype(struct rte_eth_dev *dev, 
uint8_t *pkg,
ptype_mapping[i].sw_ptype |=
RTE_PTYPE_TUNNEL_GTPU;
in_tunnel = true;
+   } else if (!strncasecmp(name, "ESP", 3)) {
+   ptype_mapping[i].sw_ptype |=
+   RTE_PTYPE_TUNNEL_ESP;
+   in_tunnel = true;
} else if (!strncasecmp(name, "GRENAT", 6)) {
ptype_mapping[i].sw_ptype |=
RTE_PTYPE_TUNNEL_GRENAT;
@@ -12560,7 +12591,7 @@ i40e_update_customized_ptype(struct rte_eth_dev *dev, 
uint8_t *pkg,
ret = rte_pmd_i40e_ptype_mapping_update(port_id, ptype_mapping,
ptype_num, 0);
if (ret)
-   PMD_DRV_LOG(ERR, "Failed to update mapping table.");
+

[dpdk-dev] [PATCH v3 4/9] net/i40e: handle ESP tunnel

[Bernard Iremonger]

handle ESP tunnel in rte_pmd_i40e.c

Signed-off-by: Bernard Iremonger 
---
 drivers/net/i40e/rte_pmd_i40e.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/i40e/rte_pmd_i40e.c b/drivers/net/i40e/rte_pmd_i40e.c
index fdcb1a4..b987346 100644
--- a/drivers/net/i40e/rte_pmd_i40e.c
+++ b/drivers/net/i40e/rte_pmd_i40e.c
@@ -2172,7 +2172,8 @@ static int check_invalid_pkt_type(uint32_t pkt_type)
tnl != RTE_PTYPE_TUNNEL_GRENAT &&
tnl != RTE_PTYPE_TUNNEL_GTPC &&
tnl != RTE_PTYPE_TUNNEL_GTPU &&
-   tnl != RTE_PTYPE_TUNNEL_L2TP)
+   tnl != RTE_PTYPE_TUNNEL_L2TP &&
+   tnl != RTE_PTYPE_TUNNEL_ESP)
return -1;
 
if (il2 &&
-- 
2.7.4

[dpdk-dev] [PATCH v2] net/virtio-user: fix return value of tap offload sets not checked

[Yunjian Wang]

The function vhost_kernel_tap_set_offload() could return errors,
the return value need to be checked. And there is no need to fail
when error is -ENOTSUP.

Fixes: 1db4d2330bc8 ("net/virtio-user: check negotiated features before set")
Cc: sta...@dpdk.org

Signed-off-by: Yunjian Wang 
---
v2:
 * No need to fail when error is -ENOTSUP.
---
 drivers/net/virtio/virtio_user/vhost_kernel_tap.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/virtio/virtio_user/vhost_kernel_tap.c 
b/drivers/net/virtio/virtio_user/vhost_kernel_tap.c
index 76bf75423..2a0c2106d 100644
--- a/drivers/net/virtio/virtio_user/vhost_kernel_tap.c
+++ b/drivers/net/virtio/virtio_user/vhost_kernel_tap.c
@@ -66,6 +66,7 @@ vhost_kernel_open_tap(char **p_ifname, int hdr_size, int 
req_mq,
int sndbuf = INT_MAX;
struct ifreq ifr;
int tapfd;
+   int ret;
 
/* TODO:
 * 1. verify we can get/set vnet_hdr_len, tap_probe_vnet_hdr_len
@@ -131,7 +132,9 @@ vhost_kernel_open_tap(char **p_ifname, int hdr_size, int 
req_mq,
goto error;
}
 
-   vhost_kernel_tap_set_offload(tapfd, features);
+   ret = vhost_kernel_tap_set_offload(tapfd, features);
+   if (ret < 0 && ret != ENOTSUP)
+   goto error;
 
memset(&ifr, 0, sizeof(ifr));
ifr.ifr_hwaddr.sa_family = ARPHRD_ETHER;
-- 
2.19.1

[dpdk-dev] [PATCH] ethdev: fix secondary process change share memory

[Fang TongHao]

Hi all，I am from Sangfor Tech.I found a bug when using DPDK in
multiprocess scenario.The secondary process enters
"rte_eth_dev_pci_copy_info" function when initializing.Then it
sets the value of struct "rte_eth_dev_data.dev_flags" to zero,
but this struct is shared by primary process and secondary
process, and the value change is unexpected by primary process.
This may cause very serious damage.I think
the secondary process should not enter "rte_eth_dev_pci_copy_info"
function or changes the value of struct "rte_eth_dev_data.dev_flags"
in shared memory.
I fixed this bug by adding an if-statement to forbid the secondary
process changing the above-mentioned value.
Thansk, All.

Signed-off-by: Fang TongHao 
---
 lib/librte_ethdev/rte_ethdev_pci.h | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/lib/librte_ethdev/rte_ethdev_pci.h 
b/lib/librte_ethdev/rte_ethdev_pci.h
index ccdbb46ec..916de8a14 100644
--- a/lib/librte_ethdev/rte_ethdev_pci.h
+++ b/lib/librte_ethdev/rte_ethdev_pci.h
@@ -59,15 +59,16 @@ rte_eth_copy_pci_info(struct rte_eth_dev *eth_dev,
}
 
eth_dev->intr_handle = &pci_dev->intr_handle;
-
-   eth_dev->data->dev_flags = 0;
-   if (pci_dev->driver->drv_flags & RTE_PCI_DRV_INTR_LSC)
-   eth_dev->data->dev_flags |= RTE_ETH_DEV_INTR_LSC;
-   if (pci_dev->driver->drv_flags & RTE_PCI_DRV_INTR_RMV)
-   eth_dev->data->dev_flags |= RTE_ETH_DEV_INTR_RMV;
-
-   eth_dev->data->kdrv = pci_dev->kdrv;
-   eth_dev->data->numa_node = pci_dev->device.numa_node;
+   if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+   eth_dev->data->dev_flags = 0;
+   if (pci_dev->driver->drv_flags & RTE_PCI_DRV_INTR_LSC)
+   eth_dev->data->dev_flags |= RTE_ETH_DEV_INTR_LSC;
+   if (pci_dev->driver->drv_flags & RTE_PCI_DRV_INTR_RMV)
+   eth_dev->data->dev_flags |= RTE_ETH_DEV_INTR_RMV;
+
+   eth_dev->data->kdrv = pci_dev->kdrv;
+   eth_dev->data->numa_node = pci_dev->device.numa_node;
+   }
 }
 
 static inline int
-- 
2.24.1.windows.2

Re: [dpdk-dev] [PATCH v3 6/9] net/i40e: display Flow Director packet

[Zhang, Qi Z]

Hi Bernard:

> -Original Message-
> From: Iremonger, Bernard 
> Sent: Thursday, January 9, 2020 8:17 PM
> To: dev@dpdk.org; Xing, Beilei ; Zhang, Qi Z
> ; Doherty, Declan 
> Cc: Ananyev, Konstantin ; Byrne, Stephen1
> ; Zhang, Helin ;
> Iremonger, Bernard 
> Subject: [PATCH v3 6/9] net/i40e: display Flow Director packet
> 
> call rte_hexdump in i40e_flow_fdir_construct_pkt() in i40e_fdir.c
> 
> Signed-off-by: Bernard Iremonger 
> ---
>  drivers/net/i40e/i40e_fdir.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/i40e/i40e_fdir.c b/drivers/net/i40e/i40e_fdir.c index
> 3fa6297..78329d2 100644
> --- a/drivers/net/i40e/i40e_fdir.c
> +++ b/drivers/net/i40e/i40e_fdir.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "i40e_logs.h"
>  #include "base/i40e_type.h"
> @@ -805,6 +806,7 @@ i40e_fdir_fill_eth_ip_head(const struct
> rte_eth_fdir_input *fdir_input,
>   fdir_input->flow_type);
>   return -1;
>   }
> + rte_hexdump(stdout, NULL, raw_pkt, len);

Why we need this? Does this just for debug?

Regards
Qi

>   return len;
>  }
> 
> @@ -954,7 +956,7 @@ i40e_fdir_construct_pkt(struct i40e_pf *pf,
>&fdir_input->flow_ext.flexbytes[dst],
>size * sizeof(uint16_t));
>   }
> -
> + rte_hexdump(stdout, NULL, raw_pkt, len);
>   return 0;
>  }
> 
> --
> 2.7.4

[dpdk-dev] [PATCH 1/2] build: fix libm detection in meson

[David Marchand]

Using version 0.47.1, meson is unable to find the math library in Travis
for the 32bits job.
Quite surprisingly, this problem is not seen with the 64bits jobs.

Switching to 0.48.0, the problem disappears.

But we should pass 'm' to find_library instead of 'libm' anyway.

Fixes: 98edcbb5ab2f ("eal/windows: introduce Windows support")
Cc: sta...@dpdk.org

Signed-off-by: David Marchand 
---
 config/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config/meson.build b/config/meson.build
index 01911ecf9..28a57f56f 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -115,7 +115,7 @@ add_project_link_arguments('-pthread', language: 'c')
 dpdk_extra_ldflags += '-pthread'
 
 # on some OS, maths functions are in a separate library
-if cc.find_library('libm', required : false).found()
+if cc.find_library('m', required : false).found()
# some libs depend on maths lib
add_project_link_arguments('-lm', language: 'c')
dpdk_extra_ldflags += '-lm'
-- 
2.23.0

[dpdk-dev] [PATCH 2/2] ci: use meson 0.47.1

[David Marchand]

meson 0.53.0 has a compatibility issue [1] with the python 3.5.2 that comes
in Ubuntu 16.04.
On the other hand, the minimal version supported in dpdk is 0.47.1.

Stick to this version to avoid getting hit by regressions in meson latest
shiny release.

1: https://github.com/mesonbuild/meson/issues/6427

Cc: sta...@dpdk.org

Signed-off-by: David Marchand 
---
 .ci/linux-setup.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
index dfb9d4a20..38bb88e15 100755
--- a/.ci/linux-setup.sh
+++ b/.ci/linux-setup.sh
@@ -1,7 +1,7 @@
 #!/bin/sh -xe
 
 # need to install as 'root' since some of the unit tests won't run without it
-sudo python3 -m pip install --upgrade meson
+sudo python3 -m pip install --upgrade 'meson==0.47.1'
 
 # setup hugepages
 cat /proc/meminfo
-- 
2.23.0

Re: [dpdk-dev] [PATCH 1/4] lib/crypto: add support for ECDSA

[Kusztal, ArkadiuszX]

Hi Anoob,

> -Original Message-
> From: Anoob Joseph 
> Sent: Thursday, January 2, 2020 8:55 AM
> To: Kusztal, ArkadiuszX ; Akhil Goyal
> ; Doherty, Declan ; De
> Lara Guarch, Pablo 
> Cc: Ayuj Verma ; Trahe, Fiona
> ; Jerin Jacob Kollanukkaran ;
> Narayana Prasad Raju Athreya ; Shally Verma
> ; Ankur Dwivedi ; Sunila
> Sahu ; dev@dpdk.org
> Subject: RE: [PATCH 1/4] lib/crypto: add support for ECDSA
> 
> Hi Arek,
> 
> Please see inline.
> 
> Thanks,
> Anoob
> 
> > -Original Message-
> > From: Kusztal, ArkadiuszX 
> > Sent: Friday, December 20, 2019 9:36 PM
> > To: Anoob Joseph ; Akhil Goyal
> > ; Doherty, Declan ; De
> > Lara Guarch, Pablo 
> > Cc: Ayuj Verma ; Trahe, Fiona
> > ; Jerin Jacob Kollanukkaran
> > ; Narayana Prasad Raju Athreya
> > ; Shally Verma ; Ankur
> > Dwivedi ; Sunila Sahu ;
> > dev@dpdk.org
> > Subject: [EXT] RE: [PATCH 1/4] lib/crypto: add support for ECDSA
> >
> > External Email
> >
> > --
> > Hi Anoob,
> >
> > Few suggestions inline.
> >
> > >  ;
> > >  [Asymmetric]
> > > -RSA =
> > > -DSA =
> > > -Modular Exponentiation =
> > > -Modular Inversion =
> > > -Diffie-hellman =
> > > \ No newline at end of file
> > > +RSA =
> > > +DSA =
> > > +Modular Exponentiation  =
> > > +Modular Inversion   =
> > > +Diffie-hellman  =
> > > +ECDSA   =
> > > diff --git a/lib/librte_cryptodev/rte_crypto_asym.h
> > > b/lib/librte_cryptodev/rte_crypto_asym.h
> > > index 0d34ce8..dd5e6e3 100644
> > > --- a/lib/librte_cryptodev/rte_crypto_asym.h
> > > +++ b/lib/librte_cryptodev/rte_crypto_asym.h
> > > @@ -81,6 +81,10 @@ enum rte_crypto_asym_xform_type {
> > >   /**< Modular Exponentiation
> > >* Perform Modular Exponentiation b^e mod n
> > >*/
> > > + RTE_CRYPTO_ASYM_XFORM_ECDSA,
> > > + /**< Elliptic Curve Digital Signature Algorithm
> > > +  * Perform Signature Generation and Verification.
> > > +  */
> > >   RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> > >   /**< End of list */
> > >  };
> > > @@ -319,6 +323,46 @@ struct rte_crypto_dsa_xform {  };
> > >
> > >  /**
> > > + * TLS named curves
> > > + *
> > > +https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__www.iana.org_ass
> > > +ignments_tls-
> > 2Dparameters_&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=jPfB8r
> > > +wwviRSxyLWs2n6B-WYLn1v9SyTMrT5EQqh2TU&m=nYBsHHO1NEdu-
> > JmNULDH0kx7auwQd
> > >
> >
> +SbI0VYNVNxmm1w&s=RKZgomFiHpm9Yp8AYEn4FjlPpzbdavkMv5cRUggVid
> > A&e=
> > > + * tls-parameters.xhtml#tls-parameters-8
> > > + * secp192r1 = 19,
> > > + * secp224r1 = 21,
> > > + * secp256r1 = 23,
> > > + * secp384r1 = 24,
> > > + * secp521r1 = 25,
> > > + */
> > > +enum rte_crypto_ec_group {
> > > + RTE_CRYPTO_EC_GROUP_UNKNOWN  = 0,
> > > + RTE_CRYPTO_EC_GROUP_NISTP192 = 19,
> > > + RTE_CRYPTO_EC_GROUP_NISTP224 = 21,
> > > + RTE_CRYPTO_EC_GROUP_NISTP256 = 23,
> > > + RTE_CRYPTO_EC_GROUP_NISTP384 = 24,
> > > + RTE_CRYPTO_EC_GROUP_NISTP521 = 25, };
> >
> > [Arek] Since in comment we use SECG naming maybe enum should follow
> to
> > avoid confusion?
> 
> [Anoob] How about RTE_CRYPTO_EC_GROUP_SECP521R1 and so on?
[Arek] Iam ok with that.
> 
> > > +
> > > +/**
> > > + * Structure for elliptic curve point  */ struct
> > > +rte_crypto_ec_point {
> > > + rte_crypto_param x;
> > > + /**< X coordinate */
> > > + rte_crypto_param y;
> > > + /**< Y coordinate */
> > > +};
> > > +
> > > +/**
> > > + * Asymmetric elliptic curve transform data
> > > + *
> > > + * Structure describing all EC based xform params
> > > + *
> > > + */
> > > +struct rte_crypto_ec_xform {
> > > + enum rte_crypto_ec_group curve_id;
> > > + /**< Pre-defined ec groups */
> > > +};
> > > +
> > > +/**
> > >   * Operations params for modular operations:
> > >   * exponentiation and multiplicative inverse
> > >   *
> > > @@ -372,6 +416,11 @@ struct rte_crypto_asym_xform {
> > >
> > >   struct rte_crypto_dsa_xform dsa;
> > >   /**< DSA xform parameters */
> > > +
> > > + struct rte_crypto_ec_xform ec;
> > > + /**< EC xform parameters, used by elliptic curve based
> > > +  * operations.
> > > +  */
> > >   };
> > >  };
> > >
> > > @@ -516,6 +565,39 @@ struct rte_crypto_dsa_op_param {  };
> > >
> > >  /**
> > > + * ECDSA operation params
> > > + */
> > > +struct rte_crypto_ecdsa_op_param {
> > > + enum rte_crypto_asym_op_type op_type;
> > > + /**< Signature generation or verification */
> > > +
> > > + rte_crypto_param pkey;
> > > + /**< Private key of the signer for signature generation */
> > [Arek] - for DSA we have private key in xform, why this inconsistency?
> 
> [Anoob] Putting key in the session would limit the number of ops we can
> perform with one session. In regular use cases, the number of ops done with
> one key is very minimal. But the number of ops using same EC group is more.
> So if we define the session to one per EC group, then we will have better
> usage of session. Otherwise, the sess

Re: [dpdk-dev] [PATCH 1/2] build: fix libm detection in meson

[Bruce Richardson]

On Thu, Jan 09, 2020 at 01:59:15PM +0100, David Marchand wrote:
> Using version 0.47.1, meson is unable to find the math library in Travis
> for the 32bits job.
> Quite surprisingly, this problem is not seen with the 64bits jobs.
> 
> Switching to 0.48.0, the problem disappears.
> 
> But we should pass 'm' to find_library instead of 'libm' anyway.
> 
> Fixes: 98edcbb5ab2f ("eal/windows: introduce Windows support")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: David Marchand 
> ---
>  config/meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/config/meson.build b/config/meson.build
> index 01911ecf9..28a57f56f 100644
> --- a/config/meson.build
> +++ b/config/meson.build
> @@ -115,7 +115,7 @@ add_project_link_arguments('-pthread', language: 'c')
>  dpdk_extra_ldflags += '-pthread'
>  
>  # on some OS, maths functions are in a separate library
> -if cc.find_library('libm', required : false).found()
> +if cc.find_library('m', required : false).found()
>   # some libs depend on maths lib
>   add_project_link_arguments('-lm', language: 'c')
>   dpdk_extra_ldflags += '-lm'
> -- 
> 2.23.0
Acked-by: Bruce Richardson 

Re: [dpdk-dev] [PATCH 2/2] ci: use meson 0.47.1

[Bruce Richardson]

On Thu, Jan 09, 2020 at 01:59:16PM +0100, David Marchand wrote:
> meson 0.53.0 has a compatibility issue [1] with the python 3.5.2 that comes
> in Ubuntu 16.04.
> On the other hand, the minimal version supported in dpdk is 0.47.1.
> 
> Stick to this version to avoid getting hit by regressions in meson latest
> shiny release.
> 
> 1: https://github.com/mesonbuild/meson/issues/6427
> 
> Cc: sta...@dpdk.org
> 
> Signed-off-by: David Marchand 
> ---
>  .ci/linux-setup.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
> index dfb9d4a20..38bb88e15 100755
> --- a/.ci/linux-setup.sh
> +++ b/.ci/linux-setup.sh
> @@ -1,7 +1,7 @@
>  #!/bin/sh -xe
>  
>  # need to install as 'root' since some of the unit tests won't run without it
> -sudo python3 -m pip install --upgrade meson
> +sudo python3 -m pip install --upgrade 'meson==0.47.1'
>  
Acked-by: Bruce Richardson 

[dpdk-dev] [PATCH] mempool: fix mempool virt populate with small chunks

[Olivier Matz]

To populate a mempool with a virtual area, the mempool code calls
rte_mempool_populate_iova() for each iova-contiguous area. It happens
(rarely) that this area is too small to store one object. In this case,
rte_mempool_populate_iova() returns an error, which is forwarded by
rte_mempool_populate_virt().

This case should not throw an error in
rte_mempool_populate_virt(). Instead, the area that is too small should
just be ignored.

To fix this issue, change the return value of
rte_mempool_populate_iova() to -ENOBUFS when no object can be populated,
so it can be ignored by the caller. As this would be an API change, add
a compat wrapper to keep the current API unchanged. The wrapper will be
removed for 20.11.

Fixes: 354788b60cfd ("mempool: allow populating with unaligned virtual area")
Cc: sta...@dpdk.org

Signed-off-by: Olivier Matz 
---

Is there a simple way to ensure that we won't forget to remove the
wrapper for 20.11? Anatoly suggested me to use versioned symbols, but
it's not clear to me how.

 doc/guides/rel_notes/deprecation.rst |  4 
 lib/librte_mempool/rte_mempool.c | 28 +++-
 lib/librte_mempool/rte_mempool.h |  5 -
 3 files changed, 31 insertions(+), 6 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index afa94b43e..b6e89d9a2 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -86,3 +86,7 @@ Deprecation Notices
   to set new power environment if power environment was already initialized.
   In this case the function will return -1 unless the environment is unset 
first
   (using ``rte_power_unset_env``). Other function usage scenarios will not 
change.
+
+* mempool: starting from v20.11, rte_mempool_populate_iova() will
+  return -ENOBUFS instead of -EINVAL when there is not enough room to
+  store one object.
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index 78d8eb941..bda361ce6 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -297,8 +297,8 @@ mempool_ops_alloc_once(struct rte_mempool *mp)
  * zone. Return the number of objects added, or a negative value
  * on error.
  */
-int
-rte_mempool_populate_iova(struct rte_mempool *mp, char *vaddr,
+static int
+__rte_mempool_populate_iova(struct rte_mempool *mp, char *vaddr,
rte_iova_t iova, size_t len, rte_mempool_memchunk_free_cb_t *free_cb,
void *opaque)
 {
@@ -332,7 +332,7 @@ rte_mempool_populate_iova(struct rte_mempool *mp, char 
*vaddr,
off = RTE_PTR_ALIGN_CEIL(vaddr, RTE_MEMPOOL_ALIGN) - vaddr;
 
if (off > len) {
-   ret = -EINVAL;
+   ret = -ENOBUFS;
goto fail;
}
 
@@ -343,7 +343,7 @@ rte_mempool_populate_iova(struct rte_mempool *mp, char 
*vaddr,
 
/* not enough room to store one object */
if (i == 0) {
-   ret = -EINVAL;
+   ret = -ENOBUFS;
goto fail;
}
 
@@ -356,6 +356,22 @@ rte_mempool_populate_iova(struct rte_mempool *mp, char 
*vaddr,
return ret;
 }
 
+/* Compat wrapper, to be removed when changing the API is allowed (v20.11). */
+int
+rte_mempool_populate_iova(struct rte_mempool *mp, char *vaddr,
+   rte_iova_t iova, size_t len, rte_mempool_memchunk_free_cb_t *free_cb,
+   void *opaque)
+{
+   int ret;
+
+   ret = __rte_mempool_populate_iova(mp, vaddr, iova, len, free_cb,
+   opaque);
+   if (ret == -ENOBUFS)
+   ret = -EINVAL;
+
+   return ret;
+}
+
 static rte_iova_t
 get_iova(void *addr)
 {
@@ -406,8 +422,10 @@ rte_mempool_populate_virt(struct rte_mempool *mp, char 
*addr,
break;
}
 
-   ret = rte_mempool_populate_iova(mp, addr + off, iova,
+   ret = __rte_mempool_populate_iova(mp, addr + off, iova,
phys_len, free_cb, opaque);
+   if (ret == -ENOBUFS)
+   continue;
if (ret < 0)
goto fail;
/* no need to call the free callback for next chunks */
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index f81152af9..c08bb444f 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -1108,7 +1108,10 @@ rte_mempool_free(struct rte_mempool *mp);
  * @return
  *   The number of objects added on success.
  *   On error, the chunk is not added in the memory list of the
- *   mempool and a negative errno is returned.
+ *   mempool and a negative errno is returned:
+ *   (-ENOBUFS): not enough room in chunk for one object.
+ *   (-ENOSPC): mempool is already populated.
+ *   (-ENOMEM): allocation failure.
  */
 int rte_mempool_populate_iova(struct rte_mempool *mp, char *vaddr,
rte_iova_t iova, size_t len, rte_mempool_memchunk_free_cb_t *free_cb,
-- 
2.20.1

[dpdk-dev] [PATCH] mempool: fix slow allocation of large mempools

[Olivier Matz]

When allocating a mempool which is larger than the largest
available area, it can take a lot of time:

a- the mempool calculate the required memory size, and tries
   to allocate it, it fails
b- then it tries to allocate the largest available area (this
   does not request new huge pages)
c- add this zone to the mempool, this triggers the allocation
   of a mem hdr, which request a new huge page
d- back to a- until mempool is populated or until there is no
   more memory

This can take a lot of time to finally fail (several minutes): in step
a- it takes all available hugepages on the system, then release them
after it fails.

The problem appeared with commit eba11e364614 ("mempool: reduce wasted
space on populate"), because smaller chunks are now allowed. Previously,
it had to be at least one page size, which is not the case in step b-.

To fix this, implement our own way to allocate the largest available
area instead of using the feature from memzone: if an allocation fails,
try to divide the size by 2 and retry. When the requested size falls
below min_chunk_size, stop and return an error.

Fixes: eba11e364614 ("mempool: reduce wasted space on populate")
Cc: sta...@dpdk.org

Signed-off-by: Olivier Matz 
---
 lib/librte_mempool/rte_mempool.c | 29 -
 1 file changed, 12 insertions(+), 17 deletions(-)

diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index bda361ce6..03c8d984c 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -481,6 +481,7 @@ rte_mempool_populate_default(struct rte_mempool *mp)
unsigned mz_id, n;
int ret;
bool need_iova_contig_obj;
+   size_t max_alloc_size = SIZE_MAX;
 
ret = mempool_ops_alloc_once(mp);
if (ret != 0)
@@ -560,30 +561,24 @@ rte_mempool_populate_default(struct rte_mempool *mp)
if (min_chunk_size == (size_t)mem_size)
mz_flags |= RTE_MEMZONE_IOVA_CONTIG;
 
-   mz = rte_memzone_reserve_aligned(mz_name, mem_size,
+   /* Allocate a memzone, retrying with a smaller area on ENOMEM */
+   do {
+   mz = rte_memzone_reserve_aligned(mz_name,
+   RTE_MIN((size_t)mem_size, max_alloc_size),
mp->socket_id, mz_flags, align);
 
-   /* don't try reserving with 0 size if we were asked to reserve
-* IOVA-contiguous memory.
-*/
-   if (min_chunk_size < (size_t)mem_size && mz == NULL) {
-   /* not enough memory, retry with the biggest zone we
-* have
-*/
-   mz = rte_memzone_reserve_aligned(mz_name, 0,
-   mp->socket_id, mz_flags, align);
-   }
+   if (mz == NULL && rte_errno != ENOMEM)
+   break;
+
+   max_alloc_size = RTE_MIN(max_alloc_size,
+   (size_t)mem_size) / 2;
+   } while (max_alloc_size >= min_chunk_size);
+
if (mz == NULL) {
ret = -rte_errno;
goto fail;
}
 
-   if (mz->len < min_chunk_size) {
-   rte_memzone_free(mz);
-   ret = -ENOMEM;
-   goto fail;
-   }
-
if (need_iova_contig_obj)
iova = mz->iova;
else
-- 
2.20.1

Re: [dpdk-dev] Inconsistent behavior of mempool with regards to hugepage allocation

[Olivier Matz]

On Tue, Jan 07, 2020 at 01:06:01PM +, Burakov, Anatoly wrote:
> On 27-Dec-19 11:11 AM, Olivier Matz wrote:
> > Hi Bao-Long,
> > 
> > On Fri, Dec 27, 2019 at 06:05:57PM +0800, Bao-Long Tran wrote:
> > > Hi Olivier,
> > > 
> > > > On 27 Dec 2019, at 4:11 PM, Olivier Matz  wrote:
> > > > 
> > > > On Thu, Dec 26, 2019 at 04:45:24PM +0100, Olivier Matz wrote:
> > > > > Hi Bao-Long,
> > > > > 
> > > > > On Mon, Dec 23, 2019 at 07:09:29PM +0800, Bao-Long Tran wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > I'm not sure if this is a bug, but I've seen an inconsistency in 
> > > > > > the behavior
> > > > > > of DPDK with regards to hugepage allocation for rte_mempool. 
> > > > > > Basically, for the
> > > > > > same mempool size, the number of hugepages allocated changes from 
> > > > > > run to run.
> > > > > > 
> > > > > > Here's how I reproduce with DPDK 19.11. IOVA=pa (default)
> > > > > > 
> > > > > > 1. Reserve 16x1G hugepages on socket 0
> > > > > > 2. Replace examples/skeleton/basicfwd.c with the code below, build 
> > > > > > and run
> > > > > > make && ./build/basicfwd
> > > > > > 3. At the same time, watch the number of hugepages allocated
> > > > > > "watch -n.1 ls /dev/hugepages"
> > > > > > 4. Repeat step 2
> > > > > > 
> > > > > > If you can reproduce, you should see that for some runs, DPDK 
> > > > > > allocates 5
> > > > > > hugepages, other times it allocates 6. When it allocates 6, if you 
> > > > > > watch the
> > > > > > output from step 3., you will see that DPDK first  try to allocate 
> > > > > > 5 hugepages,
> > > > > > then unmap all 5, retry, and got 6.
> > > > > 
> > > > > I cannot reproduce in the same conditions than yours (with 16 
> > > > > hugepages
> > > > > on socket 0), but I think I can see a similar issue:
> > > > > 
> > > > > If I reserve at least 6 hugepages, it seems reproducible (6 hugepages
> > > > > are used). If I reserve 5 hugepages, it takes more time,
> > > > > taking/releasing hugepages several times, and it finally succeeds 
> > > > > with 5
> > > > > hugepages.
> > > 
> > > My apology: I just checked again, I was using DPDK 19.05, not 19.11 or 
> > > master.
> > > Let me try to see if I can repro my issue with 19.11. Sorry for the 
> > > confusion.
> > > 
> > > I also saw your patch to reduce wasted memory (eba11e). Seems like it 
> > > resolves
> > > the problem with the IOVA-contig constraint that I described in my first 
> > > message.
> > > I'll look into it to confirm.
> > > 
> > > If I cannot repro my issue (different number of hugepages) with 19.11, 
> > > from our
> > > side we can upgrade to 19.11 and that's all we need for now. But let me 
> > > also try
> > > to repro the issue you described (multiple attempts to allocate 
> > > hugepages).
> > 
> > OK, thanks.
> > 
> > Anyway, I think there is an issue on 19.11. And it is is even worse with
> > 2M hugepages. Let's say we reserve 500x 2M hugepages, and try to
> > allocate a mempool of 5G:
> > 
> > 1/ mempool_populate tries to allocate in one virtually contiguous block,
> > which maps all 500 hugepages, then fail, unmapping them
> > 2/ it tries to allocate the largest zone, which returns ~2MB.
> > 3/ this zone is added to the mempool, and for that, it allocates a
> > mem_header struct, which triggers the mapping of a new page.
> > 4/ Back to 1... until it fails after 3 mins
> > 
> > The memzone allocation of "largest available area" does not have the
> > same semantic depending on the memory model (pre-mapped hugepages or
> > not). When using dynamic hugepage mapping, it won't map any additional
> > hugepage.
> > 
> > To solve the issue, we could either change it to allocate all available
> > hugepages, or change mempool populate, by not using the "largest
> > available area" allocation, doing the search by ourself.
> 
> Yep, this is one of the things that is currently an unsolved problem in the
> allocator. I am not sure if any one behavior is "more correct" than the
> other, so i don't think allocating "all available" hugepages is more correct
> than not doing it.
> 
> Besides, there's no reliable way to get "biggest" chunk of memory, because
> while you might get *some* memory from 2M pages, there's no guarantee that
> the amount you may get from 1G pages isn't bigger. So, we either momentarily
> take over the entire users' memory and figure out what we need and what we
> don't, or we use the first available page size and hope that that's enough.
> 
> That said, there's an internal API to allocate "up to X" pages, so in
> principle, we could build this kind of infrastructure.

I tried to solve the issue in mempool, without using the memzone_alloc(size=0)
feature. See https://patches.dpdk.org/patch/64370/

> 
> > 
> > 
> > > 
> > > > > 
> > > > > > For our use case, it's important that DPDK allocate the same number 
> > > > > > of
> > > > > > hugepages on every run so we can get reproducable results.
> > > > > 
> > > > > One possibility is to use the --legacy-mem EAL option. It will try to

Re: [dpdk-dev] 18.11.6 (LTS) patches review and test

[Kevin Traynor]

On 25/12/2019 05:17, Pei Zhang wrote:
> Hi Kevin,
> 
> Testing with 18.11.6-rc1 from Red Hat looks good.
> 

Ack, thanks for testing Pei.

> We cover below 14 scenarios and and all get PASS:
> 
> (1)Guest with device assignment(PF) throughput testing(1G hugepage size):  
> PASS
> (2)Guest with device assignment(PF) throughput testing(2M hugepage size) :  
> PASS
> (3)Guest with device assignment(VF) throughput testing: PASS
> (4)PVP (host dpdk testpmd as vswitch) 1Q: throughput testing: PASS
> (5)PVP vhost-user 2Q throughput testing: PASS
> (6)PVP vhost-user 1Q - cross numa node  throughput testing: PASS
> (7)Guest with vhost-user 2 queues throughput testing: PASS
> (8)vhost-user reconnect with dpdk-client, qemu-server: ovs reconnect: PASS
> (9)vhost-user reconnect with dpdk-client, qemu-server: qemu reconnect:  PASS
> (10)PVP 1Q live migration testing: PASS
> (11)PVP 1Q cross numa node live migration testing: PASS
> (12)Guest with ovs+dpdk+vhost-user 1Q live migration testing: PASS
> (13)Guest with ovs+dpdk+vhost-user 1Q live migration testing (2M): PASS
> (14)Guest with ovs+dpdk+vhost-user 2Q live migration testing: PASS
> 
> 
> Versions:
> kernel 3.10
> qemu 2.12
> dpdk: http://dpdk.org/git/dpdk-stabl   remotes/origin/18.11
> # git log -1
> commit ae63431d6aa03aba1e73f80e797ee0af151adeb5
> Author: Kevin Traynor 
> Date:   Wed Dec 18 11:24:09 2019 +
> version: 18.11.6-rc1
> Signed-off-by: Kevin Traynor 
> 
> 
> Best regards,
> 
> Pei
> 
> 
> - Original Message -
> From: "Kevin Traynor" 
> To: sta...@dpdk.org
> Cc: dev@dpdk.org, "Abhishek Marathe" , "Akhil 
> Goyal" , "Ali Alnubani" , 
> "benjamin walker" , "David Christensen" 
> , "Hemant Agrawal" , "Ian 
> Stokes" , "Jerin Jacob" , "John 
> McNamara" , "Ju-Hyoung Lee" , 
> "Kevin Traynor" , "Luca Boccassi" , 
> "Pei Zhang" , "pingx yu" , "qian q 
> xu" , "Raslan Darawsheh" , "Thomas 
> Monjalon" , "yuan peng" , "zhaoyan 
> chen" 
> Sent: Wednesday, December 18, 2019 7:42:03 PM
> Subject: 18.11.6 (LTS) patches review and test
> 
> Hi all,
> 
> Here is a list of patches targeted for LTS release 18.11.6.
> 
> The planned date for the final release is 31st January.
> 
> Please help with testing and validation of your use cases and report
> any issues/results with reply-all to this mail. For the final release
> the fixes and reported validations will be added to the release notes.
> 
> A release candidate tarball can be found at:
> 
> https://dpdk.org/browse/dpdk-stable/tag/?id=v18.11.6-rc1
> 
> These patches are located at branch 18.11 of dpdk-stable repo:
> https://dpdk.org/browse/dpdk-stable/
> 
> Thanks.
> 
> Kevin.
> 

Re: [dpdk-dev] [PATCH] mempool: fix mempool virt populate with small chunks

[David Marchand]

On Thu, Jan 9, 2020 at 2:27 PM Olivier Matz  wrote:
>
> To populate a mempool with a virtual area, the mempool code calls
> rte_mempool_populate_iova() for each iova-contiguous area. It happens
> (rarely) that this area is too small to store one object. In this case,
> rte_mempool_populate_iova() returns an error, which is forwarded by
> rte_mempool_populate_virt().
>
> This case should not throw an error in
> rte_mempool_populate_virt(). Instead, the area that is too small should
> just be ignored.
>
> To fix this issue, change the return value of
> rte_mempool_populate_iova() to -ENOBUFS when no object can be populated,
> so it can be ignored by the caller. As this would be an API change, add
> a compat wrapper to keep the current API unchanged. The wrapper will be
> removed for 20.11.
>
> Fixes: 354788b60cfd ("mempool: allow populating with unaligned virtual area")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Olivier Matz 
> ---
>
> Is there a simple way to ensure that we won't forget to remove the
> wrapper for 20.11? Anatoly suggested me to use versioned symbols, but
> it's not clear to me how.
>
>  doc/guides/rel_notes/deprecation.rst |  4 
>  lib/librte_mempool/rte_mempool.c | 28 +++-
>  lib/librte_mempool/rte_mempool.h |  5 -
>  3 files changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst 
> b/doc/guides/rel_notes/deprecation.rst
> index afa94b43e..b6e89d9a2 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -86,3 +86,7 @@ Deprecation Notices
>to set new power environment if power environment was already initialized.
>In this case the function will return -1 unless the environment is unset 
> first
>(using ``rte_power_unset_env``). Other function usage scenarios will not 
> change.
> +
> +* mempool: starting from v20.11, rte_mempool_populate_iova() will
> +  return -ENOBUFS instead of -EINVAL when there is not enough room to
> +  store one object.
> diff --git a/lib/librte_mempool/rte_mempool.c 
> b/lib/librte_mempool/rte_mempool.c
> index 78d8eb941..bda361ce6 100644
> --- a/lib/librte_mempool/rte_mempool.c
> +++ b/lib/librte_mempool/rte_mempool.c
> @@ -297,8 +297,8 @@ mempool_ops_alloc_once(struct rte_mempool *mp)
>   * zone. Return the number of objects added, or a negative value
>   * on error.
>   */
> -int
> -rte_mempool_populate_iova(struct rte_mempool *mp, char *vaddr,
> +static int
> +__rte_mempool_populate_iova(struct rte_mempool *mp, char *vaddr,
> rte_iova_t iova, size_t len, rte_mempool_memchunk_free_cb_t *free_cb,
> void *opaque)
>  {
> @@ -332,7 +332,7 @@ rte_mempool_populate_iova(struct rte_mempool *mp, char 
> *vaddr,
> off = RTE_PTR_ALIGN_CEIL(vaddr, RTE_MEMPOOL_ALIGN) - vaddr;
>
> if (off > len) {
> -   ret = -EINVAL;
> +   ret = -ENOBUFS;
> goto fail;
> }
>
> @@ -343,7 +343,7 @@ rte_mempool_populate_iova(struct rte_mempool *mp, char 
> *vaddr,
>
> /* not enough room to store one object */
> if (i == 0) {
> -   ret = -EINVAL;
> +   ret = -ENOBUFS;
> goto fail;
> }
>
> @@ -356,6 +356,22 @@ rte_mempool_populate_iova(struct rte_mempool *mp, char 
> *vaddr,
> return ret;
>  }
>
> +/* Compat wrapper, to be removed when changing the API is allowed (v20.11). 
> */
> +int
> +rte_mempool_populate_iova(struct rte_mempool *mp, char *vaddr,
> +   rte_iova_t iova, size_t len, rte_mempool_memchunk_free_cb_t *free_cb,
> +   void *opaque)
> +{
> +   int ret;
> +
> +   ret = __rte_mempool_populate_iova(mp, vaddr, iova, len, free_cb,
> +   opaque);
> +   if (ret == -ENOBUFS)
> +   ret = -EINVAL;
> +
> +   return ret;
> +}
> +
>  static rte_iova_t
>  get_iova(void *addr)
>  {
> @@ -406,8 +422,10 @@ rte_mempool_populate_virt(struct rte_mempool *mp, char 
> *addr,
> break;
> }
>
> -   ret = rte_mempool_populate_iova(mp, addr + off, iova,
> +   ret = __rte_mempool_populate_iova(mp, addr + off, iova,
> phys_len, free_cb, opaque);
> +   if (ret == -ENOBUFS)
> +   continue;
> if (ret < 0)
> goto fail;
> /* no need to call the free callback for next chunks */
> diff --git a/lib/librte_mempool/rte_mempool.h 
> b/lib/librte_mempool/rte_mempool.h
> index f81152af9..c08bb444f 100644
> --- a/lib/librte_mempool/rte_mempool.h
> +++ b/lib/librte_mempool/rte_mempool.h
> @@ -1108,7 +1108,10 @@ rte_mempool_free(struct rte_mempool *mp);
>   * @return
>   *   The number of objects added on success.
>   *   On error, the chunk is not added in the memory list of the
> - *   mempool and a negative errno is returned.
> + *   mempool and a negative errno is returned:
> + *   (

Re: [dpdk-dev] 18.11.6 (LTS) patches review and test

[Kevin Traynor]

On 26/12/2019 13:35, Ali Alnubani wrote:
> Hi,
> 
>> -Original Message-
>> From: Kevin Traynor 
>> Sent: Wednesday, December 18, 2019 1:42 PM
>> To: sta...@dpdk.org
>> Cc: dev@dpdk.org; Abhishek Marathe ;
>> Akhil Goyal ; Ali Alnubani ;
>> benjamin.wal...@intel.com; David Christensen ;
>> Hemant Agrawal ; Ian Stokes
>> ; Jerin Jacob ; John McNamara
>> ; Ju-Hyoung Lee ;
>> Kevin Traynor ; Luca Boccassi ;
>> Pei Zhang ; pingx...@intel.com;
>> qian.q...@intel.com; Raslan Darawsheh ; Thomas
>> Monjalon ; yuan.p...@intel.com;
>> zhaoyan.c...@intel.com
>> Subject: 18.11.6 (LTS) patches review and test
>>
>> Hi all,
>>
>> Here is a list of patches targeted for LTS release 18.11.6.
>>
>> The planned date for the final release is 31st January.
>>
>> Please help with testing and validation of your use cases and report any
>> issues/results with reply-all to this mail. For the final release the fixes 
>> and
>> reported validations will be added to the release notes.
>>
> 
> The following covers the tests that we ran on Mellanox hardware for this 
> version:

Thanks Ali. I am assuming they passed too ;-)

btw, the clang 9 issue you fixed on master was present on 18.11, so I
will add your patch (unless objections)

> - Verify sending and receiving multiple types of traffic.
> - testpmd xstats counter tests.
> - testpmd timestamp tests.
> - Changing/checking link status through testpmd.
> - RTE flow and flow_director tests.
> - Some RSS tests.
> - VLAN stripping and insertion tests.
> - Checksum and TSO tests.
> - ptype tests.
> - Multi-process tests.
> 
> The tests ran on (OS: RHEL7.4 | Kernel: Linux 3.10.0-693.el7.x86_64 | Driver: 
> MLNX_OFED_LINUX-4.7-3.2.9.0).
> 
> NICs tested:
> - ConnectX-5 | Firmware: 16.26.4012
> - ConnectX-4 Lx | Firmware: 14.26.4012
> 
> Regards,
> Ali
> 

Re: [dpdk-dev] [PATCH v3 3/9] net/i40e: improve RSS debug

[Zhang, Qi Z]

> -Original Message-
> From: Iremonger, Bernard 
> Sent: Thursday, January 9, 2020 8:16 PM
> To: dev@dpdk.org; Xing, Beilei ; Zhang, Qi Z
> ; Doherty, Declan 
> Cc: Ananyev, Konstantin ; Byrne, Stephen1
> ; Zhang, Helin ;
> Iremonger, Bernard 
> Subject: [PATCH v3 3/9] net/i40e: improve RSS debug
> 
> improve RSS debug in i40e_ethdev.c
> 
> Signed-off-by: Bernard Iremonger 

Acked-by: Qi Zhang 

Re: [dpdk-dev] [PATCH] mempool: fix mempool virt populate with small chunks

[Olivier Matz]

On Thu, Jan 09, 2020 at 02:40:06PM +0100, David Marchand wrote:
> On Thu, Jan 9, 2020 at 2:27 PM Olivier Matz  wrote:
> >
> > To populate a mempool with a virtual area, the mempool code calls
> > rte_mempool_populate_iova() for each iova-contiguous area. It happens
> > (rarely) that this area is too small to store one object. In this case,
> > rte_mempool_populate_iova() returns an error, which is forwarded by
> > rte_mempool_populate_virt().
> >
> > This case should not throw an error in
> > rte_mempool_populate_virt(). Instead, the area that is too small should
> > just be ignored.
> >
> > To fix this issue, change the return value of
> > rte_mempool_populate_iova() to -ENOBUFS when no object can be populated,
> > so it can be ignored by the caller. As this would be an API change, add
> > a compat wrapper to keep the current API unchanged. The wrapper will be
> > removed for 20.11.
> >
> > Fixes: 354788b60cfd ("mempool: allow populating with unaligned virtual 
> > area")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Olivier Matz 
> > ---
> >
> > Is there a simple way to ensure that we won't forget to remove the
> > wrapper for 20.11? Anatoly suggested me to use versioned symbols, but
> > it's not clear to me how.
> >
> >  doc/guides/rel_notes/deprecation.rst |  4 
> >  lib/librte_mempool/rte_mempool.c | 28 +++-
> >  lib/librte_mempool/rte_mempool.h |  5 -
> >  3 files changed, 31 insertions(+), 6 deletions(-)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst 
> > b/doc/guides/rel_notes/deprecation.rst
> > index afa94b43e..b6e89d9a2 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -86,3 +86,7 @@ Deprecation Notices
> >to set new power environment if power environment was already 
> > initialized.
> >In this case the function will return -1 unless the environment is unset 
> > first
> >(using ``rte_power_unset_env``). Other function usage scenarios will not 
> > change.
> > +
> > +* mempool: starting from v20.11, rte_mempool_populate_iova() will
> > +  return -ENOBUFS instead of -EINVAL when there is not enough room to
> > +  store one object.
> > diff --git a/lib/librte_mempool/rte_mempool.c 
> > b/lib/librte_mempool/rte_mempool.c
> > index 78d8eb941..bda361ce6 100644
> > --- a/lib/librte_mempool/rte_mempool.c
> > +++ b/lib/librte_mempool/rte_mempool.c
> > @@ -297,8 +297,8 @@ mempool_ops_alloc_once(struct rte_mempool *mp)
> >   * zone. Return the number of objects added, or a negative value
> >   * on error.
> >   */
> > -int
> > -rte_mempool_populate_iova(struct rte_mempool *mp, char *vaddr,
> > +static int
> > +__rte_mempool_populate_iova(struct rte_mempool *mp, char *vaddr,
> > rte_iova_t iova, size_t len, rte_mempool_memchunk_free_cb_t 
> > *free_cb,
> > void *opaque)
> >  {
> > @@ -332,7 +332,7 @@ rte_mempool_populate_iova(struct rte_mempool *mp, char 
> > *vaddr,
> > off = RTE_PTR_ALIGN_CEIL(vaddr, RTE_MEMPOOL_ALIGN) - vaddr;
> >
> > if (off > len) {
> > -   ret = -EINVAL;
> > +   ret = -ENOBUFS;
> > goto fail;
> > }
> >
> > @@ -343,7 +343,7 @@ rte_mempool_populate_iova(struct rte_mempool *mp, char 
> > *vaddr,
> >
> > /* not enough room to store one object */
> > if (i == 0) {
> > -   ret = -EINVAL;
> > +   ret = -ENOBUFS;
> > goto fail;
> > }
> >
> > @@ -356,6 +356,22 @@ rte_mempool_populate_iova(struct rte_mempool *mp, char 
> > *vaddr,
> > return ret;
> >  }
> >
> > +/* Compat wrapper, to be removed when changing the API is allowed 
> > (v20.11). */
> > +int
> > +rte_mempool_populate_iova(struct rte_mempool *mp, char *vaddr,
> > +   rte_iova_t iova, size_t len, rte_mempool_memchunk_free_cb_t 
> > *free_cb,
> > +   void *opaque)
> > +{
> > +   int ret;
> > +
> > +   ret = __rte_mempool_populate_iova(mp, vaddr, iova, len, free_cb,
> > +   opaque);
> > +   if (ret == -ENOBUFS)
> > +   ret = -EINVAL;
> > +
> > +   return ret;
> > +}
> > +
> >  static rte_iova_t
> >  get_iova(void *addr)
> >  {
> > @@ -406,8 +422,10 @@ rte_mempool_populate_virt(struct rte_mempool *mp, char 
> > *addr,
> > break;
> > }
> >
> > -   ret = rte_mempool_populate_iova(mp, addr + off, iova,
> > +   ret = __rte_mempool_populate_iova(mp, addr + off, iova,
> > phys_len, free_cb, opaque);
> > +   if (ret == -ENOBUFS)
> > +   continue;
> > if (ret < 0)
> > goto fail;
> > /* no need to call the free callback for next chunks */
> > diff --git a/lib/librte_mempool/rte_mempool.h 
> > b/lib/librte_mempool/rte_mempool.h
> > index f81152af9..c08bb444f 100644
> > --- a/lib/librte_mempool/rte_mempool.h
> > +++ b/

Re: [dpdk-dev] [PATCH] mempool: fix mempool virt populate with small chunks

[Burakov, Anatoly]

On 09-Jan-20 1:27 PM, Olivier Matz wrote:

To populate a mempool with a virtual area, the mempool code calls
rte_mempool_populate_iova() for each iova-contiguous area. It happens
(rarely) that this area is too small to store one object. In this case,
rte_mempool_populate_iova() returns an error, which is forwarded by
rte_mempool_populate_virt().

This case should not throw an error in
rte_mempool_populate_virt(). Instead, the area that is too small should
just be ignored.

To fix this issue, change the return value of
rte_mempool_populate_iova() to -ENOBUFS when no object can be populated,
so it can be ignored by the caller. As this would be an API change, add
a compat wrapper to keep the current API unchanged. The wrapper will be
removed for 20.11.

Fixes: 354788b60cfd ("mempool: allow populating with unaligned virtual area")
Cc: sta...@dpdk.org

Signed-off-by: Olivier Matz 
---



The approach fixes the issue on my end, so

Tested-by: Anatoly Burakov 


Is there a simple way to ensure that we won't forget to remove the
wrapper for 20.11? Anatoly suggested me to use versioned symbols, but
it's not clear to me how.



Yes, i'd like to do better than "ah shur we won't forget pinky swear".

Can't we do this with ABI versioning? E.g.

rte_populate_iova_v20() ... returns EINVAL

rte_populate_iova_v21() ... returns ENOBUFS

I'm pretty sure, even if it doesn't break, it will still be more likely 
to not be forgotten because there's almost a guarantee that someone will 
grep for symbol versioning macros across the codebase around 20.11 
timeframe.


--
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH] mempool: fix slow allocation of large mempools

[Burakov, Anatoly]

On 09-Jan-20 1:27 PM, Olivier Matz wrote:

When allocating a mempool which is larger than the largest
available area, it can take a lot of time:

a- the mempool calculate the required memory size, and tries
to allocate it, it fails
b- then it tries to allocate the largest available area (this
does not request new huge pages)
c- add this zone to the mempool, this triggers the allocation
of a mem hdr, which request a new huge page
d- back to a- until mempool is populated or until there is no
more memory

This can take a lot of time to finally fail (several minutes): in step
a- it takes all available hugepages on the system, then release them
after it fails.

The problem appeared with commit eba11e364614 ("mempool: reduce wasted
space on populate"), because smaller chunks are now allowed. Previously,
it had to be at least one page size, which is not the case in step b-.

To fix this, implement our own way to allocate the largest available
area instead of using the feature from memzone: if an allocation fails,
try to divide the size by 2 and retry. When the requested size falls
below min_chunk_size, stop and return an error.

Fixes: eba11e364614 ("mempool: reduce wasted space on populate")
Cc: sta...@dpdk.org

Signed-off-by: Olivier Matz 
---


I don't particularly like the idea of working around this issue as 
opposed to fixing it memzone-side, but since there's currently no plan 
to address this in memzone allocator, this should work much better than 
before.


Acked-by: Anatoly Burakov 

--
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH v3 5/9] net/i40e: process ESP flows

[Zhang, Qi Z]

Hi Bernard:

> -Original Message-
> From: Iremonger, Bernard 
> Sent: Thursday, January 9, 2020 8:17 PM
> To: dev@dpdk.org; Xing, Beilei ; Zhang, Qi Z
> ; Doherty, Declan 
> Cc: Ananyev, Konstantin ; Byrne, Stephen1
> ; Zhang, Helin ;
> Iremonger, Bernard 
> Subject: [PATCH v3 5/9] net/i40e: process ESP flows
> 
> Process ESP flows on Flow Director and RSS.
> 
> add eth/ipv4/esp and eth/ipv6/esp patterns add eth/ipv4/udp/esp and
> eth/ipv6/esp/udp patterns add flow structures for above patterns update
> i40e_flow_parse_fdir_filter() add i40e_flow_set_filter_spi() add 
> fill_ip6_head()
> add oip_type in filter add is_udp in filter use tenant_id in filter for spi 
> handle ESP
> and AH pctypes in ESP-AH profile update customized code for ESP hardcode udp
> destination port to 4500

Looks like the patch could be separate into 3 parts for easy review.

One is for the DDP package process,  (rte_pmd_i40e_process_ddp_package -> 
i40e_update_customized_info -> i40e_update_customized_pctype
One is for fdir related - training packet construction .. etc.
And one for adding all rte_flow parser

Regards
Qi

> 
> Signed-off-by: Bernard Iremonger 
> ---
>  drivers/net/i40e/i40e_ethdev.c |  44 +-
> drivers/net/i40e/i40e_ethdev.h |  38 
>  drivers/net/i40e/i40e_fdir.c   | 128
> +++---
>  drivers/net/i40e/i40e_flow.c   | 135
> -
>  4 files changed, 332 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 5f1cf8a..a462eba 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -1106,6 +1106,7 @@ i40e_init_customized_info(struct i40e_pf *pf)
>   }
> 
>   pf->gtp_support = false;
> + pf->esp_support = false;
>  }
> 
>  void
> @@ -12337,6 +12338,7 @@ i40e_update_customized_pctype(struct
> rte_eth_dev *dev, uint8_t *pkg,
>   }
>   }
>   name[strlen(name) - 1] = '\0';
> + PMD_DRV_LOG(INFO, "name = %s\n", name);
>   if (!strcmp(name, "GTPC"))
>   new_pctype =
>   i40e_find_customized_pctype(pf,
> @@ -12353,6 +12355,30 @@ i40e_update_customized_pctype(struct
> rte_eth_dev *dev, uint8_t *pkg,
>   new_pctype =
>   i40e_find_customized_pctype(pf,
> I40E_CUSTOMIZED_GTPU);
> + else if (!strcmp(name, "IPV4_ESP"))
> + new_pctype =
> + i40e_find_customized_pctype(pf,
> + I40E_CUSTOMIZED_ESP_IPV4);
> + else if (!strcmp(name, "IPV6_ESP"))
> + new_pctype =
> + i40e_find_customized_pctype(pf,
> + I40E_CUSTOMIZED_ESP_IPV6);
> + else if (!strcmp(name, "IPV4_UDP_ESP"))
> + new_pctype =
> + i40e_find_customized_pctype(pf,
> + I40E_CUSTOMIZED_ESP_IPV4_UDP);
> + else if (!strcmp(name, "IPV6_UDP_ESP"))
> + new_pctype =
> + i40e_find_customized_pctype(pf,
> + I40E_CUSTOMIZED_ESP_IPV6_UDP);
> + else if (!strcmp(name, "IPV4_AH"))
> + new_pctype =
> + i40e_find_customized_pctype(pf,
> + I40E_CUSTOMIZED_AH_IPV4);
> + else if (!strcmp(name, "IPV6_AH"))
> + new_pctype =
> + i40e_find_customized_pctype(pf,
> + I40E_CUSTOMIZED_AH_IPV6);
>   if (new_pctype) {
>   if (op == RTE_PMD_I40E_PKG_OP_WR_ADD) {
>   new_pctype->pctype = pctype_value;
> @@ -12448,6 +12474,7 @@ i40e_update_customized_ptype(struct
> rte_eth_dev *dev, uint8_t *pkg,
>   continue;
>   memset(name, 0, sizeof(name));
>   strcpy(name, proto[n].name);
> + PMD_DRV_LOG(INFO, "name = %s\n", name);
>   if (!strncasecmp(name, "PPPOE", 5))
>   ptype_mapping[i].sw_ptype |=
>   RTE_PTYPE_L2_ETHER_PPPOE;
> @@ -12541,6 +12568,10 @@ i40e_update_customized_ptype(struct
> rte_eth_dev *dev, uint8_t *pkg,
>   ptype_mapping[i].sw_ptype |=
>   RTE_PTYPE_TUNNEL_GTPU;
>   in_tunnel = true;
> + } else if (!strncasecmp(name, "ESP", 3)) {
> +  

Re: [dpdk-dev] [PATCH v7 3/4] net/ixgbe: cleanup Tx buffers

[Ananyev, Konstantin]

Hi Chenxu,

Good progress wih _full_version, but still some issues remains I think.
More comments inline.
Konstantin

> 
> Signed-off-by: Chenxu Di 
> ---
>  drivers/net/ixgbe/ixgbe_ethdev.c |   4 +
>  drivers/net/ixgbe/ixgbe_rxtx.c   | 156 ++-
>  drivers/net/ixgbe/ixgbe_rxtx.h   |  10 ++
>  3 files changed, 169 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c 
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 2c6fd0f13..668c36188 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -601,6 +601,7 @@ static const struct eth_dev_ops ixgbe_eth_dev_ops = {
>   .udp_tunnel_port_add  = ixgbe_dev_udp_tunnel_port_add,
>   .udp_tunnel_port_del  = ixgbe_dev_udp_tunnel_port_del,
>   .tm_ops_get   = ixgbe_tm_ops_get,
> + .tx_done_cleanup  = ixgbe_tx_done_cleanup,
>  };
> 
>  /*
> @@ -649,6 +650,7 @@ static const struct eth_dev_ops ixgbevf_eth_dev_ops = {
>   .reta_query   = ixgbe_dev_rss_reta_query,
>   .rss_hash_update  = ixgbe_dev_rss_hash_update,
>   .rss_hash_conf_get= ixgbe_dev_rss_hash_conf_get,
> + .tx_done_cleanup  = ixgbe_tx_done_cleanup,
>  };
> 
>  /* store statistics names and its offset in stats structure */
> @@ -1101,6 +1103,7 @@ eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev, void 
> *init_params __rte_unused)
>   eth_dev->rx_pkt_burst = &ixgbe_recv_pkts;
>   eth_dev->tx_pkt_burst = &ixgbe_xmit_pkts;
>   eth_dev->tx_pkt_prepare = &ixgbe_prep_pkts;
> + ixgbe_set_tx_done_cleanup_func(ixgbe_tx_done_cleanup_scalar);
> 
>   /*
>* For secondary processes, we don't initialise any further as primary
> @@ -1580,6 +1583,7 @@ eth_ixgbevf_dev_init(struct rte_eth_dev *eth_dev)
>   eth_dev->dev_ops = &ixgbevf_eth_dev_ops;
>   eth_dev->rx_pkt_burst = &ixgbe_recv_pkts;
>   eth_dev->tx_pkt_burst = &ixgbe_xmit_pkts;
> + ixgbe_set_tx_done_cleanup_func(ixgbe_tx_done_cleanup_scalar);
> 
>   /* for secondary processes, we don't initialise any further as primary
>* has already done this work. Only check we don't need a different
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
> index fa572d184..122dae425 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> @@ -92,6 +92,8 @@ uint16_t ixgbe_xmit_fixed_burst_vec(void *tx_queue, struct 
> rte_mbuf **tx_pkts,
>   uint16_t nb_pkts);
>  #endif
> 
> +static ixgbe_tx_done_cleanup_t ixgbe_tx_done_cleanup_op;

You can't have just one static variable here.
There could be several ixgbe devices and they could be configured in a 
different way.
I.E. txpkt_burst() is per device, so tx_done_cleanup() also has to be per 
device.
Probably the easiest way is to add new entry for tx_done_cleanup into struct 
ixgbe_txq_ops,
and set it properly in ixgbe_set_tx_function().

> +
>  /*
>   *
>   *  TX functions
> @@ -2306,6 +2308,152 @@ ixgbe_tx_queue_release_mbufs(struct ixgbe_tx_queue 
> *txq)
>   }
>  }
> 
> +int
> +ixgbe_tx_done_cleanup_scalar(struct ixgbe_tx_queue *txq, uint32_t free_cnt)

As a nit I would change _scalar to _full or so.

> +{
> + uint32_t pkt_cnt;
> + uint16_t i;
> + uint16_t tx_last;
> + uint16_t tx_id;
> + uint16_t nb_tx_to_clean;
> + uint16_t nb_tx_free_last;
> + struct ixgbe_tx_entry *swr_ring = txq->sw_ring;
> +
> + /* Start free mbuf from the next of tx_tail */
> + tx_last = txq->tx_tail;
> + tx_id  = swr_ring[tx_last].next_id;
> +
> + if (txq->nb_tx_free == 0)
> + if (ixgbe_xmit_cleanup(txq))


As a nit it could be just if (ixgbe_set_tx_function && ixgbe_xmit_cleanup(txq))

> + return 0;
> +
> + nb_tx_to_clean = txq->nb_tx_free;
> + nb_tx_free_last = txq->nb_tx_free;
> + if (!free_cnt)
> + free_cnt = txq->nb_tx_desc;
> +
> + /* Loop through swr_ring to count the amount of
> +  * freeable mubfs and packets.
> +  */
> + for (pkt_cnt = 0; pkt_cnt < free_cnt; ) {
> + for (i = 0; i < nb_tx_to_clean &&
> + pkt_cnt < free_cnt &&
> + tx_id != tx_last; i++) {
> + if (swr_ring[tx_id].mbuf != NULL) {
> + rte_pktmbuf_free_seg(swr_ring[tx_id].mbuf);
> + swr_ring[tx_id].mbuf = NULL;
> +
> + /*
> +  * last segment in the packet,
> +  * increment packet count
> +  */
> + pkt_cnt += (swr_ring[tx_id].last_id == tx_id);
> + }
> +
> + tx_id = swr_ring[tx_id].next_id;
> + }
> +
> + if (tx_id == tx_last || txq->tx_rs_thresh
> + > txq->nb_tx_desc - txq->nb_

Re: [dpdk-dev] [PATCH v3 6/9] net/i40e: display Flow Director packet

[Iremonger, Bernard]

Hi Qi,


> -Original Message-
> From: Zhang, Qi Z 
> Sent: Thursday, January 9, 2020 12:44 PM
> To: Iremonger, Bernard ; dev@dpdk.org;
> Xing, Beilei ; Doherty, Declan
> 
> Cc: Ananyev, Konstantin ; Byrne, Stephen1
> ; Zhang, Helin 
> Subject: RE: [PATCH v3 6/9] net/i40e: display Flow Director packet
> 
> Hi Bernard:
> 
> > -Original Message-
> > From: Iremonger, Bernard 
> > Sent: Thursday, January 9, 2020 8:17 PM
> > To: dev@dpdk.org; Xing, Beilei ; Zhang, Qi Z
> > ; Doherty, Declan 
> > Cc: Ananyev, Konstantin ; Byrne,
> > Stephen1 ; Zhang, Helin
> > ; Iremonger, Bernard
> > 
> > Subject: [PATCH v3 6/9] net/i40e: display Flow Director packet
> >
> > call rte_hexdump in i40e_flow_fdir_construct_pkt() in i40e_fdir.c
> >
> > Signed-off-by: Bernard Iremonger 
> > ---
> >  drivers/net/i40e/i40e_fdir.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/i40e/i40e_fdir.c
> > b/drivers/net/i40e/i40e_fdir.c index
> > 3fa6297..78329d2 100644
> > --- a/drivers/net/i40e/i40e_fdir.c
> > +++ b/drivers/net/i40e/i40e_fdir.c
> > @@ -21,6 +21,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "i40e_logs.h"
> >  #include "base/i40e_type.h"
> > @@ -805,6 +806,7 @@ i40e_fdir_fill_eth_ip_head(const struct
> > rte_eth_fdir_input *fdir_input,
> > fdir_input->flow_type);
> > return -1;
> > }
> > +   rte_hexdump(stdout, NULL, raw_pkt, len);
> 
> Why we need this? Does this just for debug?

Useful to see the packet constructed by this function, otherwise no visibility 
on what is happening.
Needed for debug.

> 
> Regards
> Qi
> 
> > return len;
> >  }
> >
> > @@ -954,7 +956,7 @@ i40e_fdir_construct_pkt(struct i40e_pf *pf,
> >  &fdir_input->flow_ext.flexbytes[dst],
> >  size * sizeof(uint16_t));
> > }
> > -
> > +   rte_hexdump(stdout, NULL, raw_pkt, len);
> > return 0;
> >  }
> >
> > --
> > 2.7.4
> 

Regards,

Bernard.

Re: [dpdk-dev] 18.11.6 (LTS) patches review and test

[Kevin Traynor]

On 30/12/2019 08:56, Lili Deng wrote:
> Hi Kevin,
> 
> 
> 
> I'd like to sign off validation dpdk-stable-18.11.6-rc1 against Azure gallery 
> images.
> 
> Version used - 
> https://git.dpdk.org/dpdk-stable/snapshot/dpdk-stable-18.11.6-rc1.tar.xz
> 
> 
> 
> Below are test matrix and results -
> 
> Tests
> 
> Ubuntu 16.04
> 
> Ubuntu 18.04
> 
> Ubuntu 19.10
> 
> RHEL 7-RAW
> 
> SLES 15
> 
> RHEL 7.5
> 
> CentOS 7.5
> 
> RHEL 8
> 
> CentOS 8
> 
> VERIFY-DPDK-FAILSAFE-DURING-TRAFFIC
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> VERIFY-DPDK-BUILD-AND-TESTPMD-TEST
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> VERIFY-SRIOV-FAILSAFE-FOR-DPDK
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> VERIFY-DPDK-COMPLIANCE
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> VERIFY-DPDK-OVS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> SKIPPED
> 
> SKIPPED
> 
> SKIPPED
> 
> SKIPPED
> 
> SKIPPED
> 
> SKIPPED
> 
> VERIFY-DPDK-RING-LATENCY
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PERF-DPDK-FWD-PPS-DS15
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PERF-DPDK-SINGLE-CORE-PPS-DS4
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PERF-DPDK-SINGLE-CORE-PPS-DS15
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PERF-DPDK-MULTICORE-PPS-DS15
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PASS
> 
> PERF-DPDK-MULTICORE-PPS-F32
> 
> PASS
> 
> PASS
> 
> PASS
> 
> FAIL
> 
> PASS
> 
> PASS
> 
> FAIL
> 
> PASS
> 
> FAIL
> 
> 
> 
> FAIL reason for PERF-DPDK-MULTICORE-PPS-F32 - the performance is not expected 
> in some rate.
> 
> For example, when run 3 times, only 1/3 pass, maybe the size Standard_F32s_v2 
> on Azure is unstable.
> 
> 

Thanks Lili. I think this is ok. It seems this test has been reporting
fails in previous testing cycles too. Perhaps in future the thresholds
could be changed so it will check if there are regressions?

fyi - if you want to be added to the list of validation contacts for
dpdk stable
(https://git.dpdk.org/tools/stable-scripts/tree/validation-contacts),
let me know. Not a requirement, just to make it easier for being
notified about an RC's etc.

Kevin.

> 
> Thanks,
> 
> Lili
> 

Re: [dpdk-dev] [PATCH v3 4/9] net/i40e: handle ESP tunnel

[Zhang, Qi Z]

Hi Bernard:
> -Original Message-
> From: Iremonger, Bernard 
> Sent: Thursday, January 9, 2020 8:16 PM
> To: dev@dpdk.org; Xing, Beilei ; Zhang, Qi Z
> ; Doherty, Declan 
> Cc: Ananyev, Konstantin ; Byrne, Stephen1
> ; Zhang, Helin ;
> Iremonger, Bernard 
> Subject: [PATCH v3 4/9] net/i40e: handle ESP tunnel
> 
> handle ESP tunnel in rte_pmd_i40e.c

Not sure if this should be part of the patch that enable the DDP that 
support ESP packet type, or at least it should be the one after that patch?

Regards
Qi
> 
> Signed-off-by: Bernard Iremonger 
> ---
>  drivers/net/i40e/rte_pmd_i40e.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/i40e/rte_pmd_i40e.c b/drivers/net/i40e/rte_pmd_i40e.c
> index fdcb1a4..b987346 100644
> --- a/drivers/net/i40e/rte_pmd_i40e.c
> +++ b/drivers/net/i40e/rte_pmd_i40e.c
> @@ -2172,7 +2172,8 @@ static int check_invalid_pkt_type(uint32_t pkt_type)
>   tnl != RTE_PTYPE_TUNNEL_GRENAT &&
>   tnl != RTE_PTYPE_TUNNEL_GTPC &&
>   tnl != RTE_PTYPE_TUNNEL_GTPU &&
> - tnl != RTE_PTYPE_TUNNEL_L2TP)
> + tnl != RTE_PTYPE_TUNNEL_L2TP &&
> + tnl != RTE_PTYPE_TUNNEL_ESP)
>   return -1;
> 
>   if (il2 &&
> --
> 2.7.4

Re: [dpdk-dev] [PATCH 1/2] build: fix libm detection in meson

[David Marchand]

On Thu, Jan 9, 2020 at 2:09 PM Bruce Richardson
 wrote:
>
> On Thu, Jan 09, 2020 at 01:59:15PM +0100, David Marchand wrote:
> > Using version 0.47.1, meson is unable to find the math library in Travis
> > for the 32bits job.
> > Quite surprisingly, this problem is not seen with the 64bits jobs.
> >
> > Switching to 0.48.0, the problem disappears.
> >
> > But we should pass 'm' to find_library instead of 'libm' anyway.
> >
> > Fixes: 98edcbb5ab2f ("eal/windows: introduce Windows support")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: David Marchand 
> > ---
> >  config/meson.build | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/config/meson.build b/config/meson.build
> > index 01911ecf9..28a57f56f 100644
> > --- a/config/meson.build
> > +++ b/config/meson.build
> > @@ -115,7 +115,7 @@ add_project_link_arguments('-pthread', language: 'c')
> >  dpdk_extra_ldflags += '-pthread'
> >
> >  # on some OS, maths functions are in a separate library
> > -if cc.find_library('libm', required : false).found()
> > +if cc.find_library('m', required : false).found()
> >   # some libs depend on maths lib
> >   add_project_link_arguments('-lm', language: 'c')
> >   dpdk_extra_ldflags += '-lm'
> > --
> > 2.23.0
> Acked-by: Bruce Richardson 

Series applied.


-- 
David Marchand

Re: [dpdk-dev] [PATCH v3 6/9] net/i40e: display Flow Director packet

[Zhang, Qi Z]

> -Original Message-
> From: Iremonger, Bernard 
> Sent: Thursday, January 9, 2020 10:03 PM
> To: Zhang, Qi Z ; dev@dpdk.org; Xing, Beilei
> ; Doherty, Declan 
> Cc: Ananyev, Konstantin ; Byrne, Stephen1
> ; Zhang, Helin 
> Subject: RE: [PATCH v3 6/9] net/i40e: display Flow Director packet
> 
> Hi Qi,
> 
> 
> > -Original Message-
> > From: Zhang, Qi Z 
> > Sent: Thursday, January 9, 2020 12:44 PM
> > To: Iremonger, Bernard ; dev@dpdk.org;
> > Xing, Beilei ; Doherty, Declan
> > 
> > Cc: Ananyev, Konstantin ; Byrne,
> > Stephen1 ; Zhang, Helin
> > 
> > Subject: RE: [PATCH v3 6/9] net/i40e: display Flow Director packet
> >
> > Hi Bernard:
> >
> > > -Original Message-
> > > From: Iremonger, Bernard 
> > > Sent: Thursday, January 9, 2020 8:17 PM
> > > To: dev@dpdk.org; Xing, Beilei ; Zhang, Qi Z
> > > ; Doherty, Declan 
> > > Cc: Ananyev, Konstantin ; Byrne,
> > > Stephen1 ; Zhang, Helin
> > > ; Iremonger, Bernard
> > > 
> > > Subject: [PATCH v3 6/9] net/i40e: display Flow Director packet
> > >
> > > call rte_hexdump in i40e_flow_fdir_construct_pkt() in i40e_fdir.c
> > >
> > > Signed-off-by: Bernard Iremonger 
> > > ---
> > >  drivers/net/i40e/i40e_fdir.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/i40e/i40e_fdir.c
> > > b/drivers/net/i40e/i40e_fdir.c index
> > > 3fa6297..78329d2 100644
> > > --- a/drivers/net/i40e/i40e_fdir.c
> > > +++ b/drivers/net/i40e/i40e_fdir.c
> > > @@ -21,6 +21,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >
> > >  #include "i40e_logs.h"
> > >  #include "base/i40e_type.h"
> > > @@ -805,6 +806,7 @@ i40e_fdir_fill_eth_ip_head(const struct
> > > rte_eth_fdir_input *fdir_input,
> > >  fdir_input->flow_type);
> > >  return -1;
> > >  }
> > > +rte_hexdump(stdout, NULL, raw_pkt, len);
> >
> > Why we need this? Does this just for debug?
> 
> Useful to see the packet constructed by this function, otherwise no 
> visibility on
> what is happening.
> Needed for debug.

But this may flush the screen if we create 1000 rules by script and it impact 
the rule programming performance, should this code only be called when debug 
mode is enabled?
> 
> >
> > Regards
> > Qi
> >
> > >  return len;
> > >  }
> > >
> > > @@ -954,7 +956,7 @@ i40e_fdir_construct_pkt(struct i40e_pf *pf,
> > >   &fdir_input->flow_ext.flexbytes[dst],
> > >   size * sizeof(uint16_t));
> > >  }
> > > -
> > > +rte_hexdump(stdout, NULL, raw_pkt, len);
> > >  return 0;
> > >  }
> > >
> > > --
> > > 2.7.4
> >
> 
> Regards,
> 
> Bernard.
> 

Re: [dpdk-dev] [dpdk-stable] [PATCH] mark experimental variables

[Thomas Monjalon]

02/12/2019 16:20, David Marchand:
> So far, we did not pay attention to direct access to variables but they
> are part of the API/ABI too and should be clearly identified.
> 
> Introduce a __rte_experimental_var tag and mark existing exported
> variables.
> 
> Fixes: a4bcd61de82d ("buildtools: add script to check experimental API 
> exports")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: David Marchand 
> ---
> + elif grep -qe "\(\.data\|\*COM\*\).*[[:space:]]$SYM$" $DUMPFILE &&
> + ! grep -q "\.data\.experimental.*[[:space:]]$SYM$" $DUMPFILE

I like such regex ;)
I don't know COM section but I am not an ELF expert.
Maybe you can just add a comment in the commit log about searching
the symbol in .data and COM sections, even if we don't know exactly why.

One more comment for the record,
I would like we avoid having some variables in the ABI.

Feel free to push this patch.
Acked-by: Thomas Monjalon 

Re: [dpdk-dev] [PATCH 2/2] ci: use meson 0.47.1

[Aaron Conole]

David Marchand  writes:

> meson 0.53.0 has a compatibility issue [1] with the python 3.5.2 that comes
> in Ubuntu 16.04.
> On the other hand, the minimal version supported in dpdk is 0.47.1.
>
> Stick to this version to avoid getting hit by regressions in meson latest
> shiny release.
>
> 1: https://github.com/mesonbuild/meson/issues/6427
>
> Cc: sta...@dpdk.org
>
> Signed-off-by: David Marchand 
> ---

Acked-by: Aaron Conole 

Re: [dpdk-dev] [PATCH 1/2] build: fix libm detection in meson

[Aaron Conole]

David Marchand  writes:

> Using version 0.47.1, meson is unable to find the math library in Travis
> for the 32bits job.
> Quite surprisingly, this problem is not seen with the 64bits jobs.
>
> Switching to 0.48.0, the problem disappears.
>
> But we should pass 'm' to find_library instead of 'libm' anyway.
>
> Fixes: 98edcbb5ab2f ("eal/windows: introduce Windows support")
> Cc: sta...@dpdk.org
>
> Signed-off-by: David Marchand 
> ---

Acked-by: Aaron Conole 

Re: [dpdk-dev] [PATCH v2 1/6] kernel/linux/kni: fix meson warning about console keyword

[Aaron Conole]

Bruce Richardson  writes:

> Since kni no longer includes the ethtool code and so is faster to build, we
> no longer need the console parameter to have incremental screen updates as
> it builds. Therefore, we drop the keyword which removes the warning.
>
> Fixes: b78f32cff94d ("kni: support meson build")
> Cc: bl...@debian.org
>
> Signed-off-by: Bruce Richardson 
> ---

Acked-by: Aaron Conole 

Re: [dpdk-dev] 18.11.6 (LTS) patches review and test

[Kevin Traynor]

On 09/01/2020 08:30, Julien Meunier wrote:
> Hi,
> 

Hi Julien,

> I launched UT on my target which has a QAT VF device, binded to igb_uio.
> 
>   + TestCase [97] : test_null_auth_only_operation failed
>   + TestCase [99] : test_null_cipher_auth_operation failed
> 
> When I did some debug, I saw that the content of the digest is 0.
> 
> If I revert ac0a49ed9258 ("crypto/qat: fix null auth when using VFIO"), 
> all tests are OK.
> 
> This issue is not seen on master branch, because other UTs are executed 
> for QAT PMDs in order to check NULL algo. UTs were a reworked, see 
> af46a0bc0c5b ("test/crypto: add NULL algo to loop test mechanism")
> 
> My commit does not seem to add any specific regression.
> 

Great, thanks for investigating it, that helps a lot.

@Fiona, I think the options we have are:

1. Revert 18.11 branch ac0a49ed9258 ("crypto/qat: fix null auth when
using VFIO")

2. You could send a backport for af46a0bc0c5b ("test/crypto: add NULL
algo to loop test mechanism") on 18.11 branch. It mostly applies but
there are some conflicts and I can't test it.

Only other option seems to be
3. Let the cryptodev_qat_autotest UT fail on 18.11.6.

What do you think?

thanks,
Kevin.

p.s. Damian's email bounced

> Regards,
> 
> On 08/01/2020 19:34, Kevin Traynor wrote:
>> On 24/12/2019 10:07, Yu, PingX wrote:
>>> Kevin,
>>> Update the regression test result of Intel part. See the details as below.
>>>
>>
>> Hi Yu Ping,
>>
>> thanks for the report and the log files.
>>
>>> # Basic Intel(R) NIC testing
>>> * PF(i40e): Pass
>>> * PF(ixgbe): Pass
>>> * VF: Pass
>>> * Build or compile: 2 bugs are found.
>>> 1. [dpdk-stable 18.11.6-rc1] meson build failed on FreeBSD12.1(See freebsd 
>>> 12.1.log.txt)
>>
>> I have a fix for this and another FreeBSD+meson issue that was hidden by
>> this.
>>
>>> 2. [dpdk-stable 18.11.6-rc1] make build failed on fedora31.(See 
>>> fedora31.log.txt)
>>
>> I have fixes for this and some other issues I found with clang 9.0 and
>> gcc 9 on F31.
>>
>>> * Intel NIC single core/NIC performance: Pass
>>>   
>>> #Basic cryptodev and virtio testing
>>> * vhost/virtio basic loopback, PVP and performance test: Pass.
>>> * cryptodev: 2 bugs are found.
>>> 1. [dpdk-stable-18.11.6]Crypto: cryptodev_qat_autotest test failed. PS: 
>>> issue passed on 18.11.3 and 18.11.5.
>>
>> Looking at commits related to crypto/qat I see:
>>
>> commit f7a7842ebec33c9cda3f5aac119adea4ce4f6999
>> Author: Hemant Agrawal 
>> Date:   Wed Dec 18 10:15:27 2019 +0530
>>
>>  test/crypto: fix session init failure for wireless case
>>
>>  [ upstream commit 2967612f44b9726cb14242ae61658f2c944188d2 ]
>>
>> commit 2674667aac56448c8bd151bc082e64ef4c88b649
>> Author: Arek Kusztal 
>> Date:   Tue Oct 22 16:22:25 2019 +0200
>>
>>  crypto/qat: fix AES CMAC mininum digest size
>>
>>  [ upstream commit a7f8087bbdbe9a69fdd0bbc77237dd3a2014ce71 ]
>>
>>
>> commit ac0a49ed92588f961b1f5e659d27c70f078eea13
>> Author: Damian Nowak 
>> Date:   Fri Aug 9 11:29:01 2019 +0200
>>
>>  crypto/qat: fix null auth when using VFIO
>>
>>  [ upstream commit 65beb9abca6dbb2167a53ab31d79e03f0857357b ]
>>
>>
>> commit cde0c9ce68d3a5975a57ef09a28252c44cfe4ac6
>> Author: Fiona Trahe 
>> Date:   Tue Sep 10 17:32:10 2019 +0100
>>
>>  crypto/qat: fix digest length in XCBC capability
>>
>>  [ upstream commit 0996ed0d5ad65b6419e3ce66a420199c3ed45ca9 ]
>>
>> commit 8db57afd7ab9a3c12d73f1f5461415690b8c173c
>> Author: Julien Meunier 
>> Date:   Wed Oct 16 13:21:11 2019 +0300
>>
>>  cryptodev: fix checks related to device id
>>
>>  [ upstream commit 3dd4435cf473f5d10b99282098821fb40b72380f ]
>>
>> commit 8dec9eab6ac4eca67cb8df2dcdd5a09eaf86bc8e
>> Author: Julien Meunier 
>> Date:   Wed Aug 7 11:39:23 2019 +0300
>>
>>  cryptodev: fix initialization on multi-process
>>
>>  [ upstream commit 1a60db7f354a52add0c1ea66e55ba7beba1a9716 ]
>>
>>> 2. [dpdk-stable-18.11.6]Crypto: cryptodev_aesni_mb_autotest. Fail on 
>>> 18.11.2~18.11.6 with latest configuration.
>>>
>>
>> As you can see from that, I don't think the UT were ever really stable
>> and a lot of the stabilisation work came after 18.11. If the
>> maintainers/authors (cc) want to investigate, I can take patches or
>> revert if required. Otherwise, I won't investigate further or block the
>> release on UT fails.
>>
>> thanks,
>> Kevin.
>>
>>> Regards,
>>> Yu Ping
>>>
 -Original Message-
 From: Kevin Traynor [mailto:ktray...@redhat.com]
 Sent: Wednesday, December 18, 2019 7:42 PM
 To: sta...@dpdk.org
 Cc: dev@dpdk.org; Abhishek Marathe ;
 Akhil Goyal ; Ali Alnubani ;
 Walker, Benjamin ; David Christensen
 ; Hemant Agrawal ;
 Stokes, Ian ; Jerin Jacob ;
 Mcnamara, John ; Ju-Hyoung Lee
 ; Kevin Traynor ; Luca
 Boccassi ; Pei Zhang ; Yu, PingX
 ; Xu, Qian Q ; Raslan Darawsheh
 ; Thomas Monjalon ; Peng,
 Yuan ; Chen, Zhaoyan 
 Subject: 18.11.6 (LTS) patches review and test

 Hi all,

 Here i

Re: [dpdk-dev] [PATCH v2 2/6] build: skip processing docs folder if docs disabled

[Aaron Conole]

Bruce Richardson  writes:

> While each target is set to be ignored if the docs are disabled in the
> meson build, there is little reason to process the docs folder at all.
>
> Signed-off-by: Bruce Richardson 
> ---

Makes sense.

Acked-by: Aaron Conole 

Re: [dpdk-dev] [PATCH v2 3/6] doc/api: fix warning with meson build

[Aaron Conole]

Bruce Richardson  writes:

> The install parameter to configure_file is new in 0.50 and generates a
> warning since it is newer than our minimum version of 0.47.1. The
> parameter, however, is unneeded as the documentation states:
>
> "When omitted it defaults to true when install_dir is set and not empty,
> false otherwise."
>
> Given that install_dir is not set for this file, install defaults to false
> so no need to explicitly specify it.
>
> Fixes: 720b14db3ae2 ("build: generate API documentation with meson")
> Cc: bl...@debian.org
>
> Signed-off-by: Bruce Richardson 
> ---

Acked-by: Aaron Conole 

Re: [dpdk-dev] [PATCH v2 4/6] doc/guides: reduce whitespace in meson build file

[Aaron Conole]

Bruce Richardson  writes:

> For building the guides, we can make the meson.build easier to read by
> using the subdir_done function to quit early.
>
> Signed-off-by: Bruce Richardson 
> ---

Nice.

Acked-by: Aaron Conole 

Re: [dpdk-dev] [PATCH v2 0/4] net/mlx5: remove Tx descriptor reserved field usage

[Raslan Darawsheh]

Hi,

Series applied on next-net-mlx,

Kindest regards,
Raslan Darawsheh

> -Original Message-
> From: Viacheslav Ovsiienko 
> Sent: Thursday, January 9, 2020 12:56 PM
> To: dev@dpdk.org
> Cc: Matan Azrad ; Raslan Darawsheh
> ; Ori Kam 
> Subject: [PATCH v2 0/4] net/mlx5: remove Tx descriptor reserved field usage
> 
> The current Tx datapath implementation in mlx5 PMD uses the 16-bit
> reserved field within transmit descriptor to store the indices of the elts 
> array
> keeping the mbuf pointers to be freed on transmit completion. On
> completion PMD fetches the descriptor index, then fetches the elts array
> index from reserved field and frees the mbufs.
> 
> The new ConnectX-6DX NIC might use this reserved descriptor field and
> existing implementation might not work in intended way.
> To resolve this issue the dedicated buffer is introduced to store indices to
> instead of descriptor field.
> 
> Signed-off-by: Viacheslav Ovsiienko 
> 
> Viacheslav Ovsiienko (4):
>   net/mlx5: move Tx complete request routine
>   net/mlx5: update Tx error handling routine
>   net/mlx5: add free on completion queue
>   net/mlx5: engage free on completion queue
> 
>  drivers/net/mlx5/mlx5_rxtx.c | 153 -
> --
>  drivers/net/mlx5/mlx5_rxtx.h |  13 ++--  drivers/net/mlx5/mlx5_txq.c  |  19
> +-
>  3 files changed, 94 insertions(+), 91 deletions(-)
> 
> --
> v1:
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
> es.dpdk.org%2Fcover%2F64293%2F&data=02%7C01%7Crasland%40mell
> anox.com%7C56986b5d3d3c46f2725b08d794f297e6%7Ca652971c7d2e4d9ba6
> a4d149256f461b%7C0%7C0%7C637141641963098885&sdata=RP4VgjCQlp
> oJc5J38aajK9Rr8twtJ4d%2FSVP2JxM5C98%3D&reserved=0
> v2: resolve minor compilation per patch issues
> 
> 1.8.3.1

Re: [dpdk-dev] [PATCH v3 4/9] net/i40e: handle ESP tunnel

[Iremonger, Bernard]

Hi Qi,

> -Original Message-
> From: Zhang, Qi Z 
> Sent: Thursday, January 9, 2020 2:09 PM
> To: Iremonger, Bernard ; dev@dpdk.org;
> Xing, Beilei ; Doherty, Declan
> 
> Cc: Ananyev, Konstantin ; Byrne, Stephen1
> ; Zhang, Helin 
> Subject: RE: [PATCH v3 4/9] net/i40e: handle ESP tunnel
> 
> Hi Bernard:
> > -Original Message-
> > From: Iremonger, Bernard 
> > Sent: Thursday, January 9, 2020 8:16 PM
> > To: dev@dpdk.org; Xing, Beilei ; Zhang, Qi Z
> > ; Doherty, Declan 
> > Cc: Ananyev, Konstantin ; Byrne,
> > Stephen1 ; Zhang, Helin
> > ; Iremonger, Bernard
> > 
> > Subject: [PATCH v3 4/9] net/i40e: handle ESP tunnel
> >
> > handle ESP tunnel in rte_pmd_i40e.c
> 
>   Not sure if this should be part of the patch that enable the DDP that
> support ESP packet type, or at least it should be the one after that patch?

I think it is ok to be in a separate patch (easier to review).
The patch set may need to be reordered.

> 
> Regards
> Qi
> >
> > Signed-off-by: Bernard Iremonger 
> > ---
> >  drivers/net/i40e/rte_pmd_i40e.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/i40e/rte_pmd_i40e.c
> > b/drivers/net/i40e/rte_pmd_i40e.c index fdcb1a4..b987346 100644
> > --- a/drivers/net/i40e/rte_pmd_i40e.c
> > +++ b/drivers/net/i40e/rte_pmd_i40e.c
> > @@ -2172,7 +2172,8 @@ static int check_invalid_pkt_type(uint32_t
> pkt_type)
> > tnl != RTE_PTYPE_TUNNEL_GRENAT &&
> > tnl != RTE_PTYPE_TUNNEL_GTPC &&
> > tnl != RTE_PTYPE_TUNNEL_GTPU &&
> > -   tnl != RTE_PTYPE_TUNNEL_L2TP)
> > +   tnl != RTE_PTYPE_TUNNEL_L2TP &&
> > +   tnl != RTE_PTYPE_TUNNEL_ESP)
> > return -1;
> >
> > if (il2 &&
> > --
> > 2.7.4
> 

Thanks for review.

Regards,

Bernard.

Re: [dpdk-dev] [PATCH] mempool: fix mempool virt populate with small chunks

[Olivier Matz]

On Thu, Jan 09, 2020 at 01:52:41PM +, Burakov, Anatoly wrote:
> On 09-Jan-20 1:27 PM, Olivier Matz wrote:
> > To populate a mempool with a virtual area, the mempool code calls
> > rte_mempool_populate_iova() for each iova-contiguous area. It happens
> > (rarely) that this area is too small to store one object. In this case,
> > rte_mempool_populate_iova() returns an error, which is forwarded by
> > rte_mempool_populate_virt().
> > 
> > This case should not throw an error in
> > rte_mempool_populate_virt(). Instead, the area that is too small should
> > just be ignored.
> > 
> > To fix this issue, change the return value of
> > rte_mempool_populate_iova() to -ENOBUFS when no object can be populated,
> > so it can be ignored by the caller. As this would be an API change, add
> > a compat wrapper to keep the current API unchanged. The wrapper will be
> > removed for 20.11.
> > 
> > Fixes: 354788b60cfd ("mempool: allow populating with unaligned virtual 
> > area")
> > Cc: sta...@dpdk.org
> > 
> > Signed-off-by: Olivier Matz 
> > ---
> > 
> 
> The approach fixes the issue on my end, so
> 
> Tested-by: Anatoly Burakov 
> 
> > Is there a simple way to ensure that we won't forget to remove the
> > wrapper for 20.11? Anatoly suggested me to use versioned symbols, but
> > it's not clear to me how.
> > 
> 
> Yes, i'd like to do better than "ah shur we won't forget pinky swear".
> 
> Can't we do this with ABI versioning? E.g.
> 
> rte_populate_iova_v20() ... returns EINVAL
> 
> rte_populate_iova_v21() ... returns ENOBUFS
> 
> I'm pretty sure, even if it doesn't break, it will still be more likely to
> not be forgotten because there's almost a guarantee that someone will grep
> for symbol versioning macros across the codebase around 20.11 timeframe.

Without using symbol versionning, would this be ok too?

  int
  rte_mempool_populate_iova(struct rte_mempool *mp, char *vaddr,
 rte_iova_t iova, size_t len, rte_mempool_memchunk_free_cb_t *free_cb,
 void *opaque)
  {
 int ret;

 ret = __rte_mempool_populate_iova(mp, vaddr, iova, len, free_cb, 
opaque);

  #if RTE_VERSION < RTE_VERSION_NUM(20, 11, 0, 0)
 if (ret == -ENOBUFS)
 ret = -EINVAL;
  #endif

 return ret;
  }



> -- 
> Thanks,
> Anatoly

Re: [dpdk-dev] [dpdk-stable] [PATCH] net/mlx5: fix ConnectX-4LX Tx burst routines set

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Slava Ovsiienko 
> Sent: Thursday, January 9, 2020 1:10 PM
> To: Ferruh Yigit ; dev@dpdk.org
> Cc: Matan Azrad ; Raslan Darawsheh
> ; Ori Kam ;
> sta...@dpdk.org; Thomas Monjalon 
> Subject: RE: [dpdk-stable] [PATCH] net/mlx5: fix ConnectX-4LX Tx burst
> routines set
> 
> > -Original Message-
> > From: Ferruh Yigit 
> > Sent: Thursday, January 9, 2020 12:50
> > To: Slava Ovsiienko ; dev@dpdk.org
> > Cc: Matan Azrad ; Raslan Darawsheh
> > ; Ori Kam ;
> sta...@dpdk.org;
> > Thomas Monjalon 
> > Subject: Re: [dpdk-stable] [PATCH] net/mlx5: fix ConnectX-4LX Tx burst
> > routines set
> >
> > On 1/9/2020 9:03 AM, Slava Ovsiienko wrote:
> > >> -Original Message-
> > >> From: Ferruh Yigit 
> > >> Sent: Wednesday, January 8, 2020 17:55
> > >> To: Slava Ovsiienko ; dev@dpdk.org
> > >> Cc: Matan Azrad ; Raslan Darawsheh
> > >> ; Ori Kam ;
> > >> sta...@dpdk.org; Thomas Monjalon 
> > >> Subject: Re: [dpdk-stable] [PATCH] net/mlx5: fix ConnectX-4LX Tx
> > >> burst routines set
> > >>
> > >> On 1/8/2020 3:50 PM, Slava Ovsiienko wrote:
> > >>> Hi, Ferruh
> > >>>
> >  -Original Message-
> >  From: Ferruh Yigit 
> >  Sent: Wednesday, January 8, 2020 16:55
> >  To: Slava Ovsiienko ; dev@dpdk.org
> >  Cc: Matan Azrad ; Raslan Darawsheh
> >  ; Ori Kam ;
> >  sta...@dpdk.org; Thomas Monjalon 
> >  Subject: Re: [dpdk-stable] [PATCH] net/mlx5: fix ConnectX-4LX Tx
> >  burst routines set
> > 
> >  On 1/8/2020 2:53 PM, Ferruh Yigit wrote:
> > > On 12/20/2019 10:48 AM, Viacheslav Ovsiienko wrote:
> > >> The tx_burst routine supporting multi-segment packets with
> > >> legacy MPW and without inline was missed, and there was no
> > >> valid selection for these options, patch adds the missing routine.
> > >>
> > >> Fixes: 82e75f8323bf ("net/mlx5: fix legacy multi-packet Tx
> > >> descriptors")
> > >> Cc: sta...@dpdk.org
> > >>
> > >> Signed-off-by: Viacheslav Ovsiienko 
> > >>
> > >> <...>
> > >>
> > >> @@ -5297,6 +5305,7 @@ enum mlx5_txcmp_code {
> > >>  DRV_LOG(DEBUG, "port %u has no selected Tx
> > function"
> > >> " for requested offloads %04X",
> > >>  dev->data->port_id, olx);
> > >> +assert(false);
> > >>
> > >> <...>
> > >>
> > >>>
> > 
> > >
> > > I think we should avoid PMDs calling the assert unconditionally,
> > > specially in a code that debug level log is printed.
> > >
> > >>  return NULL;
> > >>  }
> > >>  DRV_LOG(DEBUG, "port %u has selected Tx function"
> > >>>
> > >>> Yes, I agree. We just do not have the check for the result
> > >>> returned by mlx5_select_tx_function(). I think we should check
> > >>> against NULL and report an error.  "assert" is a temporary
> > >>> solution till this upgrade (in debug mode we have a lot of
> > >>> messages and break on assert helps to locate the problem quickly,
> reporting error will do the same).
> > >>>
> > >>
> > >> Can it be possible to drop the patch from mlx tree and prepare a
> > >> new version without 'assert'?
> > > The selection routine error handling is rather generic and is not
> > > merely
> > related to ConnectX-4LX.
> > > I propose to prepare the dedicated patch, what do you  think?
> > >
> >
> > My concern is with the assert, the error handling can be another
> > patch, but can we have this change without an assert?
> 
> Yes, please: http://patches.dpdk.org/patch/64340/
> 
> With best regards, Slava
> 
> PS. Removing this assert urges me to add error handling ASAP 😊

This patch has been removed from next-net-mlx,
I'll apply the v2

Kindest regards,
Raslan Darawsheh