Re: [dpdk-dev] eventdev DSW question

[Mattias Rönnblom]

On 2019-12-06 01:26, Venky Venkatesh wrote:

I see that the provision in 18.11 eventdev DSW for maximum number of queues
is

#define DSW_MAX_QUEUES (16)



1. If the number of queues needed is to be increased to 7 bits (i.e.
128) is there any issue (correctness, scale, performance) other than
increased data structure size?


No.


2. I see that it is only used in the following structs:
   - struct dsw_evdev: struct dsw_queue queues[DSW_MAX_QUEUES];
   sizeof(struct dsw_queue) ~ DSW_MAX_FLOWS. So the total increase
   contribution here is (128-16)*DSW_MAX_FLOWS from about 0.5MB to 4MB
   - struct dsw_port: uint64_t queue_enqueued[DSW_MAX_QUEUES],
queue_dequeued[DSW_MAX_QUEUES];
   This increase is negligible (a few KB at most across all dsw_ports)


On x86_64, the size of the dsw_evdev-struct is increased by ~32 kB per 
queue added.



3. So is it enough if I changed the above define? (In other words I hope
there are no other hidden/implicit dependencies on the current value 16
elsewhere in the code). Also I suppose the only way is to directly change
this in the code, rite?



Yes, and yes.

The original reason for having that define was that I thought 16 queues 
would be enough for anyone. As so many in the past that has utter such 
statements, I might well have been wrong.


/M

Re: [dpdk-dev] discussion: creating a new class for vdpa driversxiao.w.w...@intel.com

[Andrew Rybchenko]

On 12/6/19 8:32 AM, Liang, Cunming wrote:
> 
> 
>> -Original Message-
>> From: Bie, Tiwei 
>> Sent: Friday, December 6, 2019 12:28 PM
>> To: Matan Azrad 
>> Cc: Wang, Xiao W ; Thomas Monjalon
>> ; maxime.coque...@redhat.com; Wang, Zhihong
>> ; Yigit, Ferruh ; Shahaf 
>> Shuler
>> ; Ori Kam ; dev@dpdk.org; Slava
>> Ovsiienko ; Asaf Penso ; Olga
>> Shern ; Liang, Cunming 
>> Subject: Re: discussion: creating a new class for vdpa
>> driversxiao.w.w...@intel.com
>>
>> On Thu, Dec 05, 2019 at 01:26:36PM +, Matan Azrad wrote:
>>> Hi all
>>>
>>> As described in RFC “[RFC] net: new vdpa PMD for Mellanox devices”, a
>>> new vdpa drivers is going to be added for Mellanox devices – mlx5_vdpa
>>>
>>> The only vdpa driver now is the IFC driver that is located in net directory.
>>>
>>> The IFC driver and the new mlx5_vdpa driver provide the vdpa ops and
>>> not the eth_dev ops.
>>>
>>> All the others drivers in net provide the eth-dev ops.
>>>
>>> I suggest to create a new class for vdpa drivers, to move IFC to this
>>> class and to add the mlx5_vdpa to this class too.
>>>
>>> Later, all the new drivers that implements the vdpa ops will be added
>>> to the vdpa class.
>>
>> +1. Sounds like a good idea to me.
> +1

vDPA drivers are vendor-specific and expected to talk to vendor
NIC. I.e. there are significant chances to share code with
network drivers (e.g. base driver). Should base driver be moved
to drivers/common in this case or is it still allows to have
vdpa driver in drivers/net together with ethdev driver?

Re: [dpdk-dev] discussion: creating a new class for vdpa driversxiao.w.w...@intel.com

[Maxime Coquelin]

On 12/6/19 10:05 AM, Andrew Rybchenko wrote:
> On 12/6/19 8:32 AM, Liang, Cunming wrote:
>>
>>
>>> -Original Message-
>>> From: Bie, Tiwei 
>>> Sent: Friday, December 6, 2019 12:28 PM
>>> To: Matan Azrad 
>>> Cc: Wang, Xiao W ; Thomas Monjalon
>>> ; maxime.coque...@redhat.com; Wang, Zhihong
>>> ; Yigit, Ferruh ; Shahaf 
>>> Shuler
>>> ; Ori Kam ; dev@dpdk.org; Slava
>>> Ovsiienko ; Asaf Penso ; Olga
>>> Shern ; Liang, Cunming 
>>> Subject: Re: discussion: creating a new class for vdpa
>>> driversxiao.w.w...@intel.com
>>>
>>> On Thu, Dec 05, 2019 at 01:26:36PM +, Matan Azrad wrote:
 Hi all

 As described in RFC “[RFC] net: new vdpa PMD for Mellanox devices”, a
 new vdpa drivers is going to be added for Mellanox devices – mlx5_vdpa

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

 The IFC driver and the new mlx5_vdpa driver provide the vdpa ops and
 not the eth_dev ops.

 All the others drivers in net provide the eth-dev ops.

 I suggest to create a new class for vdpa drivers, to move IFC to this
 class and to add the mlx5_vdpa to this class too.

 Later, all the new drivers that implements the vdpa ops will be added
 to the vdpa class.
>>>
>>> +1. Sounds like a good idea to me.
>> +1
> 
> vDPA drivers are vendor-specific and expected to talk to vendor
> NIC. I.e. there are significant chances to share code with
> network drivers (e.g. base driver). Should base driver be moved
> to drivers/common in this case or is it still allows to have
> vdpa driver in drivers/net together with ethdev driver?
> 

That's a good point.

For example, for the Virtio vDPA driver, I placed it in th Virtio PMD
directory, so that we can re-use the Virtio-pci layer.
On the other hand, for the specific Virtio case, it may be preferable
to have a common directory. Doing that, the Virtio-pci layer could be
reused by Virtio PMD, Virtio vDPA, but also Virtio Crypto drivers.

I plan to submit again my Virtio vDPA next week as it didn't make it in
v19.11. I'll wait for an agreement on this topic before proceeding.

Thanks,
Maxime

Re: [dpdk-dev] example/kni failed

[Ferruh Yigit]

On 12/5/2019 10:50 AM, hy_gzr wrote:
> when I run the example/kni -l0-4 -- -P -p1 -m --config="(0,1,2)" in my 
> physical machine,
> I don't get the dpdk virtual networke interface vEth(N) by ifconfig and the 
> virtual interface is not active.
> but, I run the example in vm (linux in vmware),I can get a active virtual 
> interface, 
> so,,,why is not active in physical machin ? thanks!
> dmesg of insmod igb_uio:
> [  634.971691] igb_uio: loading out-of-tree module taints kernel.
> [  634.971898] igb_uio: module verification failed: signature and/or required 
> key missing - tainting kernel
> [  634.972563] igb_uio: Use MSIX interrupt by default
> [  635.250107] igb :02:00.0: removed PHC on eth0
> [  635.318925] igb_uio :02:00.0: mapping 1K dma=0x82cae2000 
> host=99a96cae2000
> [  635.318950] igb_uio :02:00.0: unmapping 1K dma=0x82cae2000 
> host=99a96cae2000
> 
> 
> 
> dmesg of run example kni
> [  978.094385] igb_uio :02:00.0: irq 35 for MSI/MSI-X
> [  978.094435] igb_uio :02:00.0: uio device registered with irq 35
> [  978.402505] rte_kni: Creating kni...
> [ 1003.513392] rte_kni: Successfully release kni named vEth0
> 
> 
> OS:centos 7.2.1511
> kernel 3.10.0-1062.4.3.el7.x86_64
> network:I350 Gigabit Network Connection 1521
> thanks!
> 
> 

Hi hy_gzr,

It is working fine in my environment. Can you please run with
'--log-level=lib.eal:debug' eal argument and shared the logs? Specially
interested in line with 'IOVA' keyword, since that is the change in last 
release.

Regards,
ferruh

[dpdk-dev] dpdk-next-crypto rel notes 20.02

[Kusztal, ArkadiuszX]

Hi Akhil,

I cannot find release notes for 20.02 on dpdk-next-crypto tree.
http://git.dpdk.org/next/dpdk-next-crypto/tree/doc/guides/rel_notes
Or something changed?

Thanks,
Arek

Re: [dpdk-dev] [PATCH v8 1/1] fbarray: fix duplicated fbarray file in secondary

[Burakov, Anatoly]

On 27-Nov-19 8:48 AM, Yasufumi Ogawa wrote:

From: Yasufumi Ogawa 

In secondary_msl_create_walk(), it creates a file for fbarrays with its
PID for reserving unique name among secondary processes. However, it
does not work if several secondaries run as app containers because each
of containerized secondary has PID 1, and failed to reserve unique name
other than first one. To reserve unique name in each of containers, use
hostname in addition to PID.

Signed-off-by: Yasufumi Ogawa 
---
  lib/librte_eal/common/include/rte_fbarray.h |  7 ++-
  lib/librte_eal/linux/eal/eal_memalloc.c | 11 ---
  2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/lib/librte_eal/common/include/rte_fbarray.h 
b/lib/librte_eal/common/include/rte_fbarray.h
index 6dccdbec9..df003b8dc 100644
--- a/lib/librte_eal/common/include/rte_fbarray.h
+++ b/lib/librte_eal/common/include/rte_fbarray.h
@@ -39,7 +39,12 @@ extern "C" {
  #include 
  #include 
  
-#define RTE_FBARRAY_NAME_LEN 64

+/* Filename of fbarray is defined as a combination of several params
+ * such as "fbarray_memseg-1048576k-0-0_PID_HOSTNAME".
+ * The length of string before PID can be 32bytes, and the length of
+ * PID can be 7bytes maximamly. Final 1 byte is for null terminator.
+ */
+#define RTE_FBARRAY_NAME_LEN (32 + 7 + 1 + HOST_NAME_MAX + 1)
  


This breaks ABI, but i believe this doesn't break *stable* ABI, so it is OK.

Reviewed-by: Anatoly Burakov 

--
Thanks,
Anatoly

Re: [dpdk-dev] time taken for allocation of mempool.

[Burakov, Anatoly]

On 18-Nov-19 4:43 PM, Venumadhav Josyula wrote:

Hi Anatoly,

After using iova-mode=va, i see my ports are not getting detected ? I 
thought it's working but I see following problem


what could be the problem?
i) I see allocation is faster
ii) But my ports are not getting detected
I take my word back that it entirely working..

Thanks,
Regards,
Venu



"Ports are not getting detected" is a pretty vague description of the 
problem. Could you please post the EAL initialization log (preferably 
with --log-level=eal,8 added, so that there's more output)?


--
Thanks,
Anatoly

Re: [dpdk-dev] time taken for allocation of mempool.

[Venumadhav Josyula]

Hi Anatoly,

I was able to resolve the problem, which problem in our script.

Thanks and regards
Venu

On Fri, 6 Dec 2019 at 16:17, Burakov, Anatoly 
wrote:

> On 18-Nov-19 4:43 PM, Venumadhav Josyula wrote:
> > Hi Anatoly,
> >
> > After using iova-mode=va, i see my ports are not getting detected ? I
> > thought it's working but I see following problem
> >
> > what could be the problem?
> > i) I see allocation is faster
> > ii) But my ports are not getting detected
> > I take my word back that it entirely working..
> >
> > Thanks,
> > Regards,
> > Venu
> >
>
> "Ports are not getting detected" is a pretty vague description of the
> problem. Could you please post the EAL initialization log (preferably
> with --log-level=eal,8 added, so that there's more output)?
>
> --
> Thanks,
> Anatoly
>

Re: [dpdk-dev] [PATCH v3] build: add dockerfile for building docker image

[Halim, Abdul]

> -Original Message-
> From: Yasufumi Ogawa 
> Sent: Thursday, December 5, 2019 7:52 PM
> To: Ruifeng Wang (Arm Technology China) ;
> Halim, Abdul ; dev@dpdk.org
> Cc: Kinsella, Ray ; nd 
> Subject: Re: [dpdk-dev] [PATCH v3] build: add dockerfile for building docker
> image
> 
> On 2019/12/05 23:13, Ruifeng Wang (Arm Technology China) wrote:
> >
> >> -Original Message-
> >> From: dev  On Behalf Of Abdul Halim
> >> Sent: Tuesday, December 3, 2019 19:42
> >> To: dev@dpdk.org
> >> Cc: ray.kinse...@intel.com; yasufu...@gmail.com; Abdul Halim
> >> 
> >> Subject: [dpdk-dev] [PATCH v3] build: add dockerfile for building
> >> docker image
> >>
> >> Adding a Dockerfile with Ubuntu bionic base image to build dpdk as
> >> shared library. This docker image could be used as base image to
> >> build and run dpdk applications in containers.
> >>
> >> Signed-off-by: Abdul Halim 
> >>
> [...]
> >> diff --git a/extras/README.md b/extras/README.md new file mode
> 100644
> >> index 000..f38d7f1
> >> --- /dev/null
> >> +++ b/extras/README.md
> >> @@ -0,0 +1,52 @@
> >> +# Build DPDK Docker image
> >> +
> >> +To build a docker image run the following command from dpdk root
> >> directory.
> >> +
> >> +```
> >> +DOCKER_TAG="dpdk"
> >> +docker build -t ${DOCKER_TAG} -f extras/Dockerfile.bionic .
> >> +```
> >> +
> >> +# Example of how to use this dpdk library image
> >> +
> >> +The following steps shows how to use the dpdk shared library
> >> +container to build and run a dpdk application without having to
> >> +build dpdk library for each application.
> >> +
> >> +## Create a dpdk sample app docker file with 'dpdk' as the base
> >> +image
> >> +
> >> +Create a docker file to build the dpdk helloworld application.
> >> +Since, we are creating a docker file for dpdk helloworld app we need
> >> +to add the dpdk source files, thus create the following docker file
> >> +in dpdk root
> >> directory.
> >> +
> >> +```
> >> +cat << EOF > Dockerfile.dpdkSampleApp FROM dpdk
> >> +
> >> +ADD . /opt/dpdk
> >> +
> >> +WORKDIR /opt/dpdk/examples/helloworld RUN make && cp
> >> +build/helloworld-shared /usr/local/bin/helloworld EOF ```
> >> +
> >> +## Build sample app docker image
> >> +
> >> +```
> >> +DOCKERAPP_TAG="dpdk-helloworld"
> >> +docker build -t ${DOCKERAPP_TAG} -f Dockerfile.dpdkSampleApp .
> >> +```
> >
> > Hi Abdul,
> >
> > I tried the steps on AArch64 platform, and hit error as below:
> >
> > $ sudo docker build -t ${DOCKERAPP_TAG} -f Dockerfile.dpdkSampleApp .
> > Sending build context to Docker daemon   2.55GB
> > Step 1/4 : FROM dpdk
> >   ---> 955448007987
> > Step 2/4 : ADD . /opt/dpdk
> >   ---> d8b58019a7e2
> > Step 3/4 : WORKDIR /opt/dpdk/examples/helloworld
> >   ---> Running in 14fc89f7d3cd
> > Removing intermediate container 14fc89f7d3cd
> >   ---> 065a682c58fd
> > Step 4/4 : RUN make && cp build/helloworld-shared
> /usr/local/bin/helloworld
> >   ---> Running in 11e755a7180b
> > Makefile:44: *** "Please define RTE_SDK environment variable".  Stop.
> > The command '/bin/sh -c make && cp build/helloworld-shared
> > /usr/local/bin/helloworld' returned a non-zero code: 2
> >
> > Missing define of RTE_SDK and RTE_TARGET?
> 
> Hi Ruifeng,
> 
> I think you run you run the command in dpdk/extras. However, this
> 'Dockerfile.dpdkSampleApp' is expected to be run in dpdk's root dir so that it
> is mounted as '/opt/dpdk' in the second step above. I have tested this
> Dockerfile on Ubuntu 18.04 and compiled without any error.
> RTE_SDK is set correctly, but dpdk's directory is not mounted in the
> container.
> 
> Abdul,
> 
>  >> +docker build -t ${DOCKERAPP_TAG} -f Dockerfile.dpdkSampleApp .
> 
> I think this line should be corrected as following, and make it clear it 
> should
> be run in dpdk's root.
> 
>docker build -t ${DOCKERAPP_TAG} -f extras/Dockerfile.dpdkSampleApp .
> 
> Even if the container image is built successfully, there is another problem in
> running app because it isn't run in privileged mode.
> 
> root@0d2a309dfd2c:/opt/dpdk/examples/helloworld# helloworld
> EAL: Detected 16 lcore(s)
> EAL: Detected 1 NUMA nodes
> ...
> EAL: Failed to get current mempolicy: Operation not permitted. Assuming
> MPOL_DEFAULT.
> set_mempolicy: Operation not permitted
> set_mempolicy: Operation not permitted
> EAL: error allocating rte services array
> EAL: FATAL: rte_service_init() failed
> EAL: rte_service_init() failed
> PANIC in main():
> Cannot init EAL
> 5: [helloworld(+0x84a) [0x484a]]
> 4: [/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)
> [0x77721b97]]
> 3: [helloworld(+0x818) [0x4818]]
> 2: [/usr/local/lib/x86_64-linux-gnu/librte_eal.so.20.1(__rte_panic+0xbd)
> [0x77afb410]]
> 1:
> [/usr/local/lib/x86_64-linux-gnu/librte_eal.so.20.1(rte_dump_stack+0x2e)
> [0x77b1598e]]
> Aborted (core dumped)
> 
> I think '--privileged' option should be added to avoid the error.
> 
> $ docker run --rm --privileged -it  -v /dev/hugepages:/dev/hugepages dpdk-
> helloworld
> 
> I have

Re: [dpdk-dev] discussion: creating a new class for vdpa driversxiao.w.w...@intel.com

[Tiwei Bie]

On Fri, Dec 06, 2019 at 11:04:43AM +0100, Maxime Coquelin wrote:
> On 12/6/19 10:05 AM, Andrew Rybchenko wrote:
> > On 12/6/19 8:32 AM, Liang, Cunming wrote:
> >>> -Original Message-
> >>> From: Bie, Tiwei 
> >>> Sent: Friday, December 6, 2019 12:28 PM
> >>> To: Matan Azrad 
> >>> Cc: Wang, Xiao W ; Thomas Monjalon
> >>> ; maxime.coque...@redhat.com; Wang, Zhihong
> >>> ; Yigit, Ferruh ; Shahaf 
> >>> Shuler
> >>> ; Ori Kam ; dev@dpdk.org; Slava
> >>> Ovsiienko ; Asaf Penso ; 
> >>> Olga
> >>> Shern ; Liang, Cunming 
> >>> Subject: Re: discussion: creating a new class for vdpa
> >>> driversxiao.w.w...@intel.com
> >>>
> >>> On Thu, Dec 05, 2019 at 01:26:36PM +, Matan Azrad wrote:
>  Hi all
> 
>  As described in RFC “[RFC] net: new vdpa PMD for Mellanox devices”, a
>  new vdpa drivers is going to be added for Mellanox devices – mlx5_vdpa
> 
>  The only vdpa driver now is the IFC driver that is located in net 
>  directory.
> 
>  The IFC driver and the new mlx5_vdpa driver provide the vdpa ops and
>  not the eth_dev ops.
> 
>  All the others drivers in net provide the eth-dev ops.
> 
>  I suggest to create a new class for vdpa drivers, to move IFC to this
>  class and to add the mlx5_vdpa to this class too.
> 
>  Later, all the new drivers that implements the vdpa ops will be added
>  to the vdpa class.
> >>>
> >>> +1. Sounds like a good idea to me.
> >> +1
> > 
> > vDPA drivers are vendor-specific and expected to talk to vendor
> > NIC. I.e. there are significant chances to share code with
> > network drivers (e.g. base driver). Should base driver be moved
> > to drivers/common in this case or is it still allows to have
> > vdpa driver in drivers/net together with ethdev driver?
> > 
> 
> That's a good point.
> 
> For example, for the Virtio vDPA driver, I placed it in th Virtio PMD
> directory, so that we can re-use the Virtio-pci layer.
> On the other hand, for the specific Virtio case, it may be preferable
> to have a common directory. Doing that, the Virtio-pci layer could be
> reused by Virtio PMD, Virtio vDPA, but also Virtio Crypto drivers.

For the virtio case, I also prefer to have a common directory
to allow different virtio drivers to share the virtio-pci layer.

Thanks,
Tiwei

> 
> I plan to submit again my Virtio vDPA next week as it didn't make it in
> v19.11. I'll wait for an agreement on this topic before proceeding.
> 
> Thanks,
> Maxime
> 

Re: [dpdk-dev] [PATCH v8 1/1] fbarray: fix duplicated fbarray file in secondary

[Yasufumi Ogawa]

On 2019/12/06 19:44, Burakov, Anatoly wrote:

On 27-Nov-19 8:48 AM, Yasufumi Ogawa wrote:

From: Yasufumi Ogawa 

In secondary_msl_create_walk(), it creates a file for fbarrays with its
PID for reserving unique name among secondary processes. However, it
does not work if several secondaries run as app containers because each
of containerized secondary has PID 1, and failed to reserve unique name
other than first one. To reserve unique name in each of containers, use
hostname in addition to PID.

Signed-off-by: Yasufumi Ogawa 
---
  lib/librte_eal/common/include/rte_fbarray.h |  7 ++-
  lib/librte_eal/linux/eal/eal_memalloc.c | 11 ---
  2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/lib/librte_eal/common/include/rte_fbarray.h 
b/lib/librte_eal/common/include/rte_fbarray.h

index 6dccdbec9..df003b8dc 100644
--- a/lib/librte_eal/common/include/rte_fbarray.h
+++ b/lib/librte_eal/common/include/rte_fbarray.h
@@ -39,7 +39,12 @@ extern "C" {
  #include 
  #include 
-#define RTE_FBARRAY_NAME_LEN 64
+/* Filename of fbarray is defined as a combination of several params
+ * such as "fbarray_memseg-1048576k-0-0_PID_HOSTNAME".
+ * The length of string before PID can be 32bytes, and the length of
+ * PID can be 7bytes maximamly. Final 1 byte is for null terminator.
+ */
+#define RTE_FBARRAY_NAME_LEN (32 + 7 + 1 + HOST_NAME_MAX + 1)


This breaks ABI, but i believe this doesn't break *stable* ABI, so it is 
OK.

Thank you so much!

Yasufumi


Reviewed-by: Anatoly Burakov 

[dpdk-dev] FW: IP fragmentation chunk getting dropped on egress

[Steve Banville]

 

Hi,

 

I'm seeing an issue with DPDK and IP frag where the first chunk is getting 
dropped on egress. I'm using the igb_e1000 driver with DPDK v18.x. My scenario 
is that I'm allocating a new buffer to store an outer L3 tunnel header, I clone 
the original received buffer which is a little over 3K, I link the newly cloned 
buffer to the allocated buffers nextptr and copy the meta data from the 
original packet buffer to the new allocated buffer. After calling   
rte_ipv4_fragment_packet, I notice that the number of chunks created form the 
jumbo packet seems correct. What's strange is that the 1st fragmented chunk has 
a segment with a data_len = 0. All subsequent chunks appear to be fine. I've 
ran rte_mbuf_sanity_check against my new packet which succeeds. After adjusting 
the packet for L2 and adding the Ethernet header, I send the packet out but 
only chunks 1 + 2 are received off the wire. The first chunk (0) is never 
received and the NICs eth stats reflect this as well.

 

 

I'm hoping someone could shed some light on this issue and provide a solution.

 

Thanks,

 

Steve

 

Code example:

 

  copybuf = rte_pktmbuf_alloc(getMbufPool());

// Add L3 tunnel header

Clone_buffer = rte_pktmbuf_clone(pkt_info->mblk, getClonePool());





// Link the outer trace header

copybuf->next = clone_buffer;

copybuf->pkt_len += clone_buffer->pkt_len;   // update overall 
packet length

clone_buffer->pkt_len = clone_buffer->data_len;  // packet len only 
in first segment

copybuf->nb_segs = (uint8_t)(clone_buffer->nb_segs + 1);





/* copy metadata from source packet */

copybuf->vlan_tci = pkt_info->mblk->vlan_tci;

copybuf->vlan_tci_outer = pkt_info->mblk->vlan_tci_outer;

copybuf->port = pkt_info->mblk->port;

copybuf->tx_offload = pkt_info->mblk->tx_offload;

copybuf->hash = pkt_info->mblk->hash;

copybuf->ol_flags = pkt_info->mblk->ol_flags;

 

rte_mbuf_sanity_check(copybuf, 1);

 

 

Rice# dump mbuf at 0x3100ae8e56c0, iova=42e8e5880, buf_len=2176

  pkt_len=3687, ol_flags=182, nb_segs=4, in_port=0

  segment at 0x3100ae8e56c0, data=0x3100ae8e5900, data_len=20

  Dump data at [0x3100ae8e5900], len=20

: 45 00 0E 67 00 00 00 00 80 04 82 0B C0 A8 94 6E | E..g...n

0010: C0 A8 94 C8 |  |  |  |  |  |  |  |  |  |  |  |  | 

  segment at 0x3100a6f319c0, data=0x3100a73b9b0e, data_len=1500

  Dump data at [0x3100a73b9b0e], len=80

: 45 00 0E 53 27 22 00 00 40 11 C4 DE AC 10 94 0A | E..S'"..@...

0010: AC 10 94 6E 13 C4 13 C4 0E 3F 00 1F 49 4E 56 49 | ...n.?..INVI

0020: 54 45 20 73 69 70 3A 73 65 72 76 69 63 65 40 31 | TE sip:service@1

0030: 37 32 2E 31 36 2E 31 34 38 2E 31 31 30 3A 35 30 | 72.16.148.110:50

0040: 36 30 20 53 49 50 2F 32 2E 30 0D 0A 56 69 61 3A | 60 SIP/2.0..Via:

  segment at 0x3100a6f31900, data=0x3100a73b90a2, data_len=1480

  segment at 0x3100a6f31840, data=0x3100a73b8622, data_len=687

 

Chunk 0: l2 len 0 l3 len 20, pkt len 1514, data len 34, nsegs 3

dump mbuf at 0x3100ae8e4c40, iova=42e8e4e00, buf_len=2176

  pkt_len=1514, ol_flags=40, nb_segs=3, in_port=65535

  segment at 0x3100ae8e4c40, data=0x3100ae8e4e72, data_len=34

  Dump data at [0x3100ae8e4e72], len=34

: 00 21 F6 69 02 A3 00 08 25 25 63 A4 08 00 45 00 | .!.i%%c...E.

0010: 05 DC FA CF 20 00 80 04 6F C6 C0 A8 94 6E C0 A8 |  ...on..

0020: 94 C8 |  |  |  |  |  |  |  |  |  |  |  |  |  |  | ..

  segment at 0x3100ae8e41c0, data=0x3100ae8e5914, data_len=0

  segment at 0x3100ae8e3740, data=0x3100a73b9b0e, data_len=1480

  Dump data at [0x3100a73b9b0e], len=66

: 45 00 0E 53 27 22 00 00 40 11 C4 DE AC 10 94 0A | E..S'"..@...

0010: AC 10 94 6E 13 C4 13 C4 0E 3F 00 1F 49 4E 56 49 | ...n.?..INVI

0020: 54 45 20 73 69 70 3A 73 65 72 76 69 63 65 40 31 | TE sip:service@1

0030: 37 32 2E 31 36 2E 31 34 38 2E 31 31 30 3A 35 30 | 72.16.148.110:50

0040: 36 30 |  |  |  |  |  |  |  |  |  |  |  |  |  |  | 60

Sending packet: txQ 1, L2 len 14, L3 len 20, protocol 4, flags 0 mtu 1500 
egress intf 537919488

 

Chunk 1: l2 len 0 l3 len 20, pkt len 1514, data len 34, nsegs 3

dump mbuf at 0x3100ae8e2cc0, iova=42e8e2e80, buf_len=2176

  pkt_len=1514, ol_flags=40, nb_segs=3, in_port=65535

  segment at 0x3100ae8e2cc0, data=0x3100ae8e2ef2, data_len=34

  Dump data at [0x3100ae8e2ef2], len=34

: 00 21 F6 69 02 A3 00 08 25 25 63 A4 08 00 45 00 | .!.i%%c...E.

0010: 05 DC FA CF 20 B9 80 04 6F 0D C0 A8 94 6E C0 A8 |  ...on..

0020: 94 C8 |  |  |  |  |  |  |  |  |  |  |  |  |  |  | ..

  segment at 0x3100ae8e2240, data=0x3100a73ba0d6, data_len=20

  Dump data at [0x3100a73ba0d6], len=20

: 37 32 2E 31 36 2E 31 34 38 2E 31 30 3A 35 30 36 | 72.16.148.10:506

0010: 30 3

Re: [dpdk-dev] [dpdk-users] Sharing Data structure between logical cores in DPDK- regarding

[Stephen Hemminger]

On Thu, 5 Dec 2019 10:54:59 +
"Van Haaren, Harry"  wrote:

>  I have a small doubt, can we share a data structure between
> > multiple logical cores in DPDK without locking?  

Sure, learn to use RCU!!

Re: [dpdk-dev] eventdev DSW question

[Venky Venkatesh]

Thanks Mattias for the clarifications.

1 more question: This time it is about the inflight accounting for DSW.
Here is my understanding: it seems to consider only the events which
are *inside
the scheduler* as in flight. I am trying to distinguish it from those which
have been currently given to cores by the scheduler. The latter are not
considered in flight since we dsw_port_return_credits as soon as
dsw_event_dequeue_burst . So if these events which are in core currently do
a FORWARD, there is a chance that those can fail. Ideally those FORWARDs
should not fail -- which can happen with the current design as some NEWs
can hog those credits freed up by the ones which have been dequeued by
cores. Is this design of DSW intentional or an omission? If it is an
omission I can work on a possible fix and run it by you.

Thanks
-Venky

On Fri, Dec 6, 2019 at 12:34 AM Mattias Rönnblom <
mattias.ronnb...@ericsson.com> wrote:

> On 2019-12-06 01:26, Venky Venkatesh wrote:
> > I see that the provision in 18.11 eventdev DSW for maximum number of
> queues
> > is
> >
> > #define DSW_MAX_QUEUES (16)
> >
> >
> >
> > 1. If the number of queues needed is to be increased to 7 bits (i.e.
> > 128) is there any issue (correctness, scale, performance) other than
> > increased data structure size?
>
> No.
>
> > 2. I see that it is only used in the following structs:
> >- struct dsw_evdev: struct dsw_queue queues[DSW_MAX_QUEUES];
> >sizeof(struct dsw_queue) ~ DSW_MAX_FLOWS. So the total increase
> >contribution here is (128-16)*DSW_MAX_FLOWS from about 0.5MB to
> 4MB
> >- struct dsw_port: uint64_t queue_enqueued[DSW_MAX_QUEUES],
> > queue_dequeued[DSW_MAX_QUEUES];
> >This increase is negligible (a few KB at most across all
> dsw_ports)
>
> On x86_64, the size of the dsw_evdev-struct is increased by ~32 kB per
> queue added.
>
> > 3. So is it enough if I changed the above define? (In other words I
> hope
> > there are no other hidden/implicit dependencies on the current value
> 16
> > elsewhere in the code). Also I suppose the only way is to directly
> change
> > this in the code, rite?
> >
>
> Yes, and yes.
>
> The original reason for having that define was that I thought 16 queues
> would be enough for anyone. As so many in the past that has utter such
> statements, I might well have been wrong.
>
> /M
>

Re: [dpdk-dev] [dpdk-users] Sharing Data structure between logical cores in DPDK- regarding

[Van Haaren, Harry]

> -Original Message-
> From: Stephen Hemminger 
> Sent: Friday, December 6, 2019 4:31 PM
> To: Van Haaren, Harry 
> Cc: Tom Barbette ; Perugu Hemasai Chandra Prasad
> ; us...@dpdk.org; dev@dpdk.org
> Subject: Re: [dpdk-users] [dpdk-dev] Sharing Data structure between logical
> cores in DPDK- regarding

Hey Stephen,

[OT] Please watch your snipping of > characters and Wrote: strings, I'm not the 
original author of the question, but from snipping it looks like that below.


> On Thu, 5 Dec 2019 10:54:59 +
> "Van Haaren, Harry"  wrote:
> 
> >  I have a small doubt, can we share a data structure between
> > > multiple logical cores in DPDK without locking?
> 
> Sure, learn to use RCU!!

Good suggestion, apart from Atomics or Mutex based locking schemes, RCU (Read 
Copy Update) is another method of (semi) synchronizing/sharing data-structures 
across threads.

DPDK has some RCU mechanics in lib/librte_rcu/ library, perhaps they are of 
interest. The implementation here is particularly for reclaiming memory after a 
Quiescent State point has been reached by all threads.

Re: [dpdk-dev] Interrupt is catched in kernel, but not handled

[Stephen Hemminger]

On Sun, 1 Dec 2019 20:16:59 +0200
Ranran  wrote:

> בתאריך יום א׳, 1 בדצמ׳ 2019, 19:07, מאת Stephen Hemminger ‏<
> step...@networkplumber.org>:
> 
> > On Sat, 30 Nov 2019 19:49:16 +0200
> > Ranran  wrote:
> >
> > > > >
> > > > > I also verified that there are no additional irq numbered 23 except
> > > > > for our device.
> > > > >
> > > > > How can it be that irq is catched, but not delivered to userspace ?
> > > > > Any suggestion is much appreciated,
> > > > >
> > > > > ran
> > > >
> > > > UIO PCI generic does not support interrupts.
> > > > You need to use VFIO (preferred) or igb_uio
> > > >
> >
> > Actually UIO PCI generic does support interrupts but only legacy INTx,
> > it does not support MSI or MSI-x modes.
> >
> 
> Right.
> The device I work with is FPGA xilinx which should support INTx. Yet, even
> though irqhandler is called, it does not pass pci_check_and_mask_intx, and
> therefore irq is not handled, as I written in the original post.

Your problem may be that the FPGA is not correctly implementing the PCI spec.
I saw this before with VMWare.

The kernel expects to be able to read the PCI_COMMAND register to
see if IRQ is pending and then write back INTX_DISABLE bit.

Re: [dpdk-dev] [dpdk-users] Sharing Data structure between logical cores in DPDK- regarding

[Stephen Hemminger]

On Fri, 6 Dec 2019 16:51:40 +
"Van Haaren, Harry"  wrote:

> > -Original Message-
> > From: Stephen Hemminger 
> > Sent: Friday, December 6, 2019 4:31 PM
> > To: Van Haaren, Harry 
> > Cc: Tom Barbette ; Perugu Hemasai Chandra Prasad
> > ; us...@dpdk.org; dev@dpdk.org
> > Subject: Re: [dpdk-users] [dpdk-dev] Sharing Data structure between logical
> > cores in DPDK- regarding  
> 
> Hey Stephen,
> 
> [OT] Please watch your snipping of > characters and Wrote: strings, I'm not 
> the original author of the question, but from snipping it looks like that 
> below.

Harry, I just use bottom posting as is commonly done in open source mailing 
lists.
So if your comments are mixed in with earlier text it will get confusing

[dpdk-dev] [PATCH v2] cryptodev: add chacha20-poly1305 aead algorithm

[Arek Kusztal]

This patch adds Chacha20-Poly1305 AEAD algorithm to Cryptodev.

Signed-off-by: Arek Kusztal 
---
v2:
- moved release notes to 20.02

 doc/guides/cryptodevs/features/default.ini | 13 +++--
 doc/guides/rel_notes/release_20_02.rst |  4 
 lib/librte_cryptodev/rte_crypto_sym.h  |  9 +
 3 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/doc/guides/cryptodevs/features/default.ini 
b/doc/guides/cryptodevs/features/default.ini
index b7f9a0a..2a3ff48 100644
--- a/doc/guides/cryptodevs/features/default.ini
+++ b/doc/guides/cryptodevs/features/default.ini
@@ -93,12 +93,13 @@ SHA3_512 HMAC   =
 ; Supported AEAD algorithms of a default crypto driver.
 ;
 [AEAD]
-AES GCM (128) =
-AES GCM (192) =
-AES GCM (256) =
-AES CCM (128) =
-AES CCM (192) =
-AES CCM (256) =
+AES GCM (128) =
+AES GCM (192) =
+AES GCM (256) =
+AES CCM (128) =
+AES CCM (192) =
+AES CCM (256) =
+CHACHA20-POLY1305 =
 ;
 ; Supported Asymmetric algorithms of a default crypto driver.
 ;
diff --git a/doc/guides/rel_notes/release_20_02.rst 
b/doc/guides/rel_notes/release_20_02.rst
index 0eaa45a..6b60f47 100644
--- a/doc/guides/rel_notes/release_20_02.rst
+++ b/doc/guides/rel_notes/release_20_02.rst
@@ -56,6 +56,10 @@ New Features
  Also, make sure to start the actual text at the margin.
  =
 
+* **Added Chacha20-Poly1305 algorithm to Cryptodev API.**
+
+  Chacha20-Poly1305 AEAD algorithm can now be supported in Cryptodev.
+
 
 Removed Items
 -
diff --git a/lib/librte_cryptodev/rte_crypto_sym.h 
b/lib/librte_cryptodev/rte_crypto_sym.h
index ffa038d..bc356f6 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -348,6 +348,8 @@ enum rte_crypto_aead_algorithm {
/**< AES algorithm in CCM mode. */
RTE_CRYPTO_AEAD_AES_GCM,
/**< AES algorithm in GCM mode. */
+   RTE_CRYPTO_AEAD_CHACHA20_POLY1305,
+   /**< Chacha20 cipher with poly1305 authenticator */
RTE_CRYPTO_AEAD_LIST_END
 };
 
@@ -391,6 +393,11 @@ struct rte_crypto_aead_xform {
 * be allocated, even though the length field will
 * have a value less than this.
 *
+* - For Chacha20-Poly1305 it is 96-bit nonce.
+* PMD sets initial counter for Poly1305 key generation
+* part to 0 and for Chacha20 encryption to 1 as per
+* rfc8439 2.8. AEAD construction.
+*
 * For optimum performance, the data pointed to SHOULD
 * be 8-byte aligned.
 */
@@ -407,6 +414,8 @@ struct rte_crypto_aead_xform {
 *
 * - For CCM mode, this is the length of the nonce,
 * which can be in the range 7 to 13 inclusive.
+*
+* - For Chacha20-Poly1305 this field is always 12.
 */
} iv;   /**< Initialisation vector parameters */
 
-- 
2.1.0

[dpdk-dev] [PATCH 0/2] Add chacha20-poly1305 algorithm to QAT

[Arek Kusztal]

This patchset adds chacha20-poly1305 algorithm to Intel QuickAssit
Technology Driver and corresponding test cases.

This patchset depends on the "cryptodev: add chacha20-poly1305 aead algorithm" 
[1].

[1] http://patchwork.dpdk.org/patch/63610/

Arek Kusztal (2):
  crypto/qat: add chacha poly implementation
  test/cryptodev: add chacha poly test cases to cryptodev

 app/test/test_cryptodev.c   | 35 +
 app/test/test_cryptodev_aead_test_vectors.h | 77 +
 doc/guides/cryptodevs/qat.rst   |  1 +
 doc/guides/rel_notes/release_20_02.rst  |  4 ++
 drivers/common/qat/qat_adf/icp_qat_hw.h | 17 ++-
 drivers/crypto/qat/qat_sym_capabilities.h   | 32 
 drivers/crypto/qat/qat_sym_pmd.c| 11 -
 drivers/crypto/qat/qat_sym_session.c| 20 ++--
 8 files changed, 190 insertions(+), 7 deletions(-)

-- 
2.1.0

[dpdk-dev] [PATCH 2/2] test/cryptodev: add chacha poly test cases to cryptodev

[Arek Kusztal]

This patch adds Chacha20-Poly1305 implementation to
cryptodev tests.

Signed-off-by: Arek Kusztal 
---
 app/test/test_cryptodev.c   | 35 +
 app/test/test_cryptodev_aead_test_vectors.h | 77 +
 2 files changed, 112 insertions(+)

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 1b56145..222e768 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -7541,6 +7541,7 @@ test_authenticated_encryption(const struct aead_test_data 
*tdata)
 {
struct crypto_testsuite_params *ts_params = &testsuite_params;
struct crypto_unittest_params *ut_params = &unittest_params;
+   struct rte_cryptodev_sym_capability_idx cap_idx;
 
int retval;
uint8_t *ciphertext, *auth_tag;
@@ -7554,6 +7555,15 @@ test_authenticated_encryption(const struct 
aead_test_data *tdata)
tdata->key.data, tdata->key.len,
tdata->aad.len, tdata->auth_tag.len,
tdata->iv.len);
+
+   cap_idx.type = RTE_CRYPTO_SYM_XFORM_AEAD;
+   cap_idx.algo.aead = tdata->algo;
+
+   if (rte_cryptodev_sym_capability_get(ts_params->valid_devs[0],
+   &cap_idx) == NULL) {
+   return -ENOTSUP;
+   }
+
if (retval < 0)
return retval;
 
@@ -8431,6 +8441,7 @@ test_authenticated_decryption(const struct aead_test_data 
*tdata)
 {
struct crypto_testsuite_params *ts_params = &testsuite_params;
struct crypto_unittest_params *ut_params = &unittest_params;
+   struct rte_cryptodev_sym_capability_idx cap_idx;
 
int retval;
uint8_t *plaintext;
@@ -8446,6 +8457,14 @@ test_authenticated_decryption(const struct 
aead_test_data *tdata)
if (retval < 0)
return retval;
 
+   cap_idx.type = RTE_CRYPTO_SYM_XFORM_AEAD;
+   cap_idx.algo.aead = tdata->algo;
+
+   if (rte_cryptodev_sym_capability_get(ts_params->valid_devs[0],
+   &cap_idx) == NULL) {
+   return -ENOTSUP;
+   }
+
/* alloc mbuf and set payload */
if (tdata->aad.len > MBUF_SIZE) {
ut_params->ibuf = rte_pktmbuf_alloc(ts_params->large_mbuf_pool);
@@ -8499,6 +8518,18 @@ test_authenticated_decryption(const struct 
aead_test_data *tdata)
 }
 
 static int
+test_chacha20_poly1305_encrypt_test_case_rfc8439(void)
+{
+   return test_authenticated_encryption(&chacha20_poly1305_case_rfc8439);
+}
+
+static int
+test_chacha20_poly1305_decrypt_test_case_rfc8439(void)
+{
+   return test_authenticated_decryption(&chacha20_poly1305_case_rfc8439);
+}
+
+static int
 test_AES_GCM_authenticated_decryption_test_case_1(void)
 {
return test_authenticated_decryption(&gcm_test_case_1);
@@ -11908,6 +11939,10 @@ static struct unit_test_suite cryptodev_qat_testsuite  
= {
TEST_CASE_ST(ut_setup, ut_teardown,
test_AES_CCM_authenticated_decryption_test_case_128_3),
 
+   TEST_CASE_ST(ut_setup, ut_teardown,
+   test_chacha20_poly1305_encrypt_test_case_rfc8439),
+   TEST_CASE_ST(ut_setup, ut_teardown,
+   test_chacha20_poly1305_decrypt_test_case_rfc8439),
/** AES GCM Authenticated Encryption */
TEST_CASE_ST(ut_setup, ut_teardown,
test_AES_GCM_auth_encrypt_SGL_in_place_1500B),
diff --git a/app/test/test_cryptodev_aead_test_vectors.h 
b/app/test/test_cryptodev_aead_test_vectors.h
index a4a3a25..b107510 100644
--- a/app/test/test_cryptodev_aead_test_vectors.h
+++ b/app/test/test_cryptodev_aead_test_vectors.h
@@ -84,6 +84,83 @@ struct gmac_test_data {
 
 };
 
+static uint8_t chacha_aad_rfc8439[] = {
+   0x50, 0x51, 0x52, 0x53, 0xc0, 0xc1, 0xc2, 0xc3,
+   0xc4, 0xc5, 0xc6, 0xc7
+};
+
+static const struct aead_test_data chacha20_poly1305_case_rfc8439 = {
+   .algo = RTE_CRYPTO_AEAD_CHACHA20_POLY1305,
+   .key = {
+   .data = {
+   0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87,
+   0x88, 0x89, 0x8a, 0x8b, 0x8c, 0x8d, 0x8e, 0x8f,
+   0x90, 0x91, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97,
+   0x98, 0x99, 0x9a, 0x9b, 0x9c, 0x9d, 0x9e, 0x9f
+   },
+   .len = 32
+   },
+   .iv = {
+   .data = {
+   0x07, 0x00, 0x00, 0x00, 0x40, 0x41, 0x42, 0x43, 
0x44,
+   0x45, 0x46, 0x47
+   },
+  .len = 12
+   },
+   .aad = {
+  .data = chacha_aad_rfc8439,
+  .len = 12
+   },
+   .plaintext = {
+  .data = {
+  0x4c, 0x61, 0x64, 0x69, 0x65, 0x73, 0x20, 0x61,
+  0x6e, 0x64, 0x20, 0x47, 0x65, 0x6e, 0x74, 0x6c,
+  

[dpdk-dev] [PATCH 1/2] crypto/qat: add chacha poly implementation

[Arek Kusztal]

This patchset adds Chacha20-Poly1305 implementation to Intel
QuickAssist Technology pmd.

Signed-off-by: Arek Kusztal 
---
 doc/guides/cryptodevs/qat.rst |  1 +
 doc/guides/rel_notes/release_20_02.rst|  4 
 drivers/common/qat/qat_adf/icp_qat_hw.h   | 17 ++--
 drivers/crypto/qat/qat_sym_capabilities.h | 32 +++
 drivers/crypto/qat/qat_sym_pmd.c  | 11 ++-
 drivers/crypto/qat/qat_sym_session.c  | 20 +++
 6 files changed, 78 insertions(+), 7 deletions(-)

diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index 6197875..479f5cc 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -70,6 +70,7 @@ Supported AEAD algorithms:
 
 * ``RTE_CRYPTO_AEAD_AES_GCM``
 * ``RTE_CRYPTO_AEAD_AES_CCM``
+* ``RTE_CRYPTO_AEAD_CHACHA20_POLY1305``
 
 
 Limitations
diff --git a/doc/guides/rel_notes/release_20_02.rst 
b/doc/guides/rel_notes/release_20_02.rst
index 6b60f47..72504ab 100644
--- a/doc/guides/rel_notes/release_20_02.rst
+++ b/doc/guides/rel_notes/release_20_02.rst
@@ -60,6 +60,10 @@ New Features
 
   Chacha20-Poly1305 AEAD algorithm can now be supported in Cryptodev.
 
+* **Updated the Intel QuickAssist Technology (QAT) symmetric crypto PMD.**
+
+  Added Chacha20-Poly1305 AEAD algorithm.
+
 
 Removed Items
 -
diff --git a/drivers/common/qat/qat_adf/icp_qat_hw.h 
b/drivers/common/qat/qat_adf/icp_qat_hw.h
index cef6486..ed04178 100644
--- a/drivers/common/qat/qat_adf/icp_qat_hw.h
+++ b/drivers/common/qat/qat_adf/icp_qat_hw.h
@@ -51,7 +51,10 @@ enum icp_qat_hw_auth_algo {
ICP_QAT_HW_AUTH_ALGO_SHA3_256 = 17,
ICP_QAT_HW_AUTH_RESERVED_3 = 18,
ICP_QAT_HW_AUTH_ALGO_SHA3_512 = 19,
-   ICP_QAT_HW_AUTH_ALGO_DELIMITER = 20
+   ICP_QAT_HW_AUTH_ALGO_SHAKE_128 = 20,
+   ICP_QAT_HW_AUTH_ALGO_SHAKE_256 = 21,
+   ICP_QAT_HW_AUTH_ALGO_POLY = 22,
+   ICP_QAT_HW_AUTH_ALGO_DELIMITER = 23
 };
 
 enum icp_qat_hw_auth_mode {
@@ -204,7 +207,9 @@ enum icp_qat_hw_cipher_algo {
ICP_QAT_HW_CIPHER_ALGO_KASUMI = 7,
ICP_QAT_HW_CIPHER_ALGO_SNOW_3G_UEA2 = 8,
ICP_QAT_HW_CIPHER_ALGO_ZUC_3G_128_EEA3 = 9,
-   ICP_QAT_HW_CIPHER_DELIMITER = 10
+   ICP_QAT_HW_CIPHER_ALGO_SM4 = 10,
+   ICP_QAT_HW_CIPHER_ALGO_CHACHA20_POLY1305 = 11,
+   ICP_QAT_HW_CIPHER_DELIMITER = 12
 };
 
 enum icp_qat_hw_cipher_mode {
@@ -306,6 +311,14 @@ enum icp_qat_hw_cipher_convert {
 #define ICP_QAT_HW_ZUC_3G_EEA3_KEY_SZ 16
 #define ICP_QAT_HW_ZUC_3G_EEA3_IV_SZ 16
 #define ICP_QAT_HW_MODE_F8_NUM_REG_TO_CLEAR 2
+#define ICP_QAT_HW_SM4_KEY_SZ 16
+#define ICP_QAT_HW_SM4_IV_SZ 16
+#define ICP_QAT_HW_CHACHAPOLY_KEY_SZ 32
+#define ICP_QAT_HW_CHACHAPOLY_IV_SZ 12
+#define ICP_QAT_HW_CHACHAPOLY_BLK_SZ 64
+#define ICP_QAT_HW_SPC_CTR_SZ 16
+#define ICP_QAT_HW_CHACHAPOLY_ICV__SZ 16
+#define ICP_QAT_HW_CHACHAPOLY_AAD_MAX_LOG 14
 
 #define ICP_QAT_HW_CIPHER_MAX_KEY_SZ ICP_QAT_HW_AES_256_F8_KEY_SZ
 
diff --git a/drivers/crypto/qat/qat_sym_capabilities.h 
b/drivers/crypto/qat/qat_sym_capabilities.h
index 028a56c..acc5045 100644
--- a/drivers/crypto/qat/qat_sym_capabilities.h
+++ b/drivers/crypto/qat/qat_sym_capabilities.h
@@ -594,4 +594,36 @@
}, }\
}
 
+#define QAT_EXTRA_GEN3_SYM_CAPABILITIES
\
+   {   /* Chacha20-Poly1305 */ \
+   .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, \
+   {.sym = {   \
+   .xform_type = RTE_CRYPTO_SYM_XFORM_AEAD,\
+   {.aead = {  \
+   .algo = RTE_CRYPTO_AEAD_CHACHA20_POLY1305,  
\
+   .block_size = 64,   \
+   .key_size = {   \
+   .min = 32,  \
+   .max = 32,  \
+   .increment = 0  \
+   },  \
+   .digest_size = {\
+   .min = 16,  \
+   .max = 16,  \
+   .increment = 0  \
+   },  \
+   .aad_size = {   \
+   .min = 0,   \
+   .max = 240, \
+   .increment = 1  \
+   }, 

Re: [dpdk-dev] [PATCH v2] cryptodev: add chacha20-poly1305 aead algorithm

[Trahe, Fiona]

> -Original Message-
> From: Kusztal, ArkadiuszX 
> Sent: Friday, December 6, 2019 6:02 PM
> To: dev@dpdk.org
> Cc: akhil.go...@nxp.com; Trahe, Fiona ; Kusztal, 
> ArkadiuszX
> 
> Subject: [PATCH v2] cryptodev: add chacha20-poly1305 aead algorithm
> 
> This patch adds Chacha20-Poly1305 AEAD algorithm to Cryptodev.
> 
> Signed-off-by: Arek Kusztal 
Acked-by: Fiona Trahe 

Re: [dpdk-dev] eventdev DSW question

[Mattias Rönnblom]

On 2019-12-06 17:32, Venky Venkatesh wrote:

Thanks Mattias for the clarifications.

1 more question: This time it is about the inflight accounting for DSW.
Here is my understanding: it seems to consider only the events which
are *inside
the scheduler* as in flight.


Yes, like all event devices, I believe.


I am trying to distinguish it from those which
have been currently given to cores by the scheduler. The latter are not
considered in flight since we dsw_port_return_credits as soon as
dsw_event_dequeue_burst.


A new dequeue means an implicit release of all unreleased events 
dequeued in the previous call. It's standard Eventdev semantics.



So if these events which are in core currently do
a FORWARD, there is a chance that those can fail. Ideally those FORWARDs
should not fail -- which can happen with the current design as some NEWs
can hog those credits freed up by the ones which have been dequeued by
cores.


What you do to avoid this situation is set the new_event_threshold 
low-enough, so NEW events don't block FORWARDed ones.



Is this design of DSW intentional or an omission? If it is an
omission I can work on a possible fix and run it by you.



This is not really a DSW design, but rather how Eventdev works.

[dpdk-dev] Segmentation fault in aes_cmac_subkey_gen_avx512 and avx512 usage [dpdk-users]

[Suraj R Gupta]

Hi all,
I am encountering some issues in using intel multi buffer library with dpdk
crypto library.




*DPDK version used - 18.05.1Intel Multibuffer library version - 0.52
( https://github.com/intel/intel-ipsec-mb/tree/v0.52
 )CPU - InfoIntel(R)
Core(TM) i7-8700 CPU @ 3.20GHz*

1. When I am using aes cmac with intel multi buffer library from DPDK. I am
receiving an segmentation fault in aes_cmac_subkey_gen_avx512().
This segmentation fault appears at times.
Thread 5 "lcore-slave-1" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7feff43fe700 (LWP 24301)]
0x7730ab04 in aes_cmac_subkey_gen_avx512 () from
/usr/lib/libIPSec_MB.so.0

2. On compiling the above intel multi buffer library and running LibTestApp
from multi buffer library. It is showing Illegal Instruction.
AES-CFB128 standard test vectors:

...Pass
SHA standard test vectors (N jobs = 1):

...Pass
Testing AVX512 interface
Illegal instruction (core dumped)

I am not able to understand the issue. Request you to help me in this
regard.
Please revert for any clarification.
-- 
Thanks and Regards
Suraj R Gupta

Re: [dpdk-dev] [dpdk-users] Segmentation fault in aes_cmac_subkey_gen_avx512 and avx512 usage

[Suraj R Gupta]

Some more Info.
Basically the CPU does not support AVX512.
So, I think I need to disable avx512 instructions when compiling
multibuffer library, DPDK and the application itself.
I tried using some -mno-avx512x flags but still error persisted.
Is the observation valid? I need help in disabling avx512 functions then.
would it affect performances nd usage?

On Sat, Dec 7, 2019 at 2:10 AM Suraj R Gupta  wrote:

> Hi all,
> I am encountering some issues in using intel multi buffer library with dpdk
> crypto library.
>
>
>
>
> *DPDK version used - 18.05.1Intel Multibuffer library version - 0.52
> ( https://github.com/intel/intel-ipsec-mb/tree/v0.52
>  )CPU - InfoIntel(R)
> Core(TM) i7-8700 CPU @ 3.20GHz*
>
> 1. When I am using aes cmac with intel multi buffer library from DPDK. I am
> receiving an segmentation fault in aes_cmac_subkey_gen_avx512().
> This segmentation fault appears at times.
> Thread 5 "lcore-slave-1" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7feff43fe700 (LWP 24301)]
> 0x7730ab04 in aes_cmac_subkey_gen_avx512 () from
> /usr/lib/libIPSec_MB.so.0
>
> 2. On compiling the above intel multi buffer library and running LibTestApp
> from multi buffer library. It is showing Illegal Instruction.
> AES-CFB128 standard test vectors:
> 
> ...Pass
> SHA standard test vectors (N jobs = 1):
> 
> ...Pass
> Testing AVX512 interface
> Illegal instruction (core dumped)
>
> I am not able to understand the issue. Request you to help me in this
> regard.
> Please revert for any clarification.
> --
> Thanks and Regards
> Suraj R Gupta
>


-- 
Thanks and Regards
Suraj R Gupta

[dpdk-dev] RFC - adding filter to packet capture API

[Stephen Hemminger]

In the process of updating packet capture to take a filter program, there
is one open question about API/ABI.

The example is:

int
rte_pdump_enable(uint16_t port, uint16_t queue, uint32_t flags,
struct rte_ring *ring,
struct rte_mempool *mp,
void *filter);

For the new version want to add ability to pass a BPF (classic) program
from libcap. This is described in most pcap API's as "struct bpf_program".

The filter parameter was left as a placeholder, but in typical YAGNI
fashion. When we do need to use it, it is not going to work out.

Since the existing filter argument was never used, there are a bunch
of options (in order from best to worse).

1. Introduce new API which takes a filter. 

int
rte_pdump_enable_bpf(uint16_t port, uint16_t queue, uint32_t flags,
struct rte_ring *ring,
struct rte_mempool *mp,
const struct bpf_program *filter);

The old API is just the same as calling new API with NULL as filter.
This solution is safe but adds minor bloat.

2. Use API versioning.  This solves the ABI problem but it is still
   an API breakage since program that was passing junk would still
   not compile.

3. Change the function signature of existing API. This risks breaking
   at compile time some program that was passing some other value.
   Similarly, a program could have passed garbage, we never checked.

4. Keep existing function signature, but be type unsafe.
   This keeps API, but still is ABI breakage for programs that passed
   garbage. Plus C is unsafe enough already.

Re: [dpdk-dev] eventdev DSW question

[Venky Venkatesh]

To my understanding, per eventdev API, events are considered in flight
between NEW to RELEASE (implicit/explicit). Now consider an event (event-1)
going thru the following stages:

   1. NEW from core-3
   2. dequeued by core-1
   3. FORWARD
   4. core-1 does a next dequeue
   5. dequeued by core-2
   6. RELEASE by core-2/implicit release on next dequeue by core-2

The way I understand DSW implementation this event would use credit at step
1 AND step 3 while releasing in step2 -- right now credit usage is for
non_release (i.e NEW and FORWARD). So if between step-2 and step-3 another
core puts in a NEW of event-2 that could utilize all the credits of the
system and could thus fail step-3 of event-1.
This to my knowledge is not conformant with eventdev. One way to address
this is to track the credits for that which are currently in core and not
make those credits available to NEW but only for FORWARDs ... there are
more details of course.

Hope this explains
Thanks
-Venky



On Fri, Dec 6, 2019 at 12:37 PM Mattias Rönnblom <
mattias.ronnb...@ericsson.com> wrote:

> On 2019-12-06 17:32, Venky Venkatesh wrote:
> > Thanks Mattias for the clarifications.
> >
> > 1 more question: This time it is about the inflight accounting for DSW.
> > Here is my understanding: it seems to consider only the events which
> > are *inside
> > the scheduler* as in flight.
>
> Yes, like all event devices, I believe.
>
> > I am trying to distinguish it from those which
> > have been currently given to cores by the scheduler. The latter are not
> > considered in flight since we dsw_port_return_credits as soon as
> > dsw_event_dequeue_burst.
>
> A new dequeue means an implicit release of all unreleased events
> dequeued in the previous call. It's standard Eventdev semantics.
>
> > So if these events which are in core currently do
> > a FORWARD, there is a chance that those can fail. Ideally those FORWARDs
> > should not fail -- which can happen with the current design as some NEWs
> > can hog those credits freed up by the ones which have been dequeued by
> > cores.
>
> What you do to avoid this situation is set the new_event_threshold
> low-enough, so NEW events don't block FORWARDed ones.
>
> > Is this design of DSW intentional or an omission? If it is an
> > omission I can work on a possible fix and run it by you.
> >
>
> This is not really a DSW design, but rather how Eventdev works.
>

[dpdk-dev] [PATCH v2 2/2] net/netvsc: disable before changing RSS parameters

[Stephen Hemminger]

In order to change RSS parameters, the host requires that RSS
is disable first.

Fixes: 92d23a57cafe ("net/netvsc: support configuring RSS parameters")
Cc: sta...@dpdk.org
Tested-by: Abhishek Marathe 
Signed-off-by: Dexuan Cui 
Signed-off-by: Stephen Hemminger 
---
 drivers/net/netvsc/hn_ethdev.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/net/netvsc/hn_ethdev.c b/drivers/net/netvsc/hn_ethdev.c
index 5ef7a452cc69..159116f7f691 100644
--- a/drivers/net/netvsc/hn_ethdev.c
+++ b/drivers/net/netvsc/hn_ethdev.c
@@ -292,6 +292,13 @@ static int hn_rss_reta_update(struct rte_eth_dev *dev,
hv->rss_ind[i] = reta_conf[idx].reta[shift];
}
 
+   err = hn_rndis_conf_rss(hv, NDIS_RSS_FLAG_DISABLE);
+   if (err) {
+   PMD_DRV_LOG(NOTICE,
+   "rss disable failed");
+   return err;
+   }
+
err = hn_rndis_conf_rss(hv, 0);
if (err) {
PMD_DRV_LOG(NOTICE,
@@ -579,6 +586,13 @@ static int hn_dev_configure(struct rte_eth_dev *dev)
return err;
}
 
+   err = hn_rndis_conf_rss(hv, NDIS_RSS_FLAG_DISABLE);
+   if (err) {
+   PMD_DRV_LOG(NOTICE,
+   "rss disable failed");
+   return err;
+   }
+
err = hn_rndis_conf_rss(hv, 0);
if (err) {
PMD_DRV_LOG(NOTICE,
-- 
2.20.1

[dpdk-dev] [PATCH v2 1/2] net/netvsc: fix RSS offload flag

[Stephen Hemminger]

The change to add OFFLOAD_RSS_HASH broke use of netvsc PMD
with testpmd. The netvsc driver fails during configure step:

Configuring Port 1 (socket 0)
hn_dev_configure(): unsupported RX offload: 0x8

Fixes: 5d308972954c ("ethdev: add mbuf RSS update as an offload")
Cc: pbhagavat...@marvell.com
Cc: sta...@dpdk.org
Signed-off-by: Stephen Hemminger 
---
 drivers/net/netvsc/hn_ethdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/netvsc/hn_ethdev.c b/drivers/net/netvsc/hn_ethdev.c
index 164e9ad174a7..5ef7a452cc69 100644
--- a/drivers/net/netvsc/hn_ethdev.c
+++ b/drivers/net/netvsc/hn_ethdev.c
@@ -42,7 +42,8 @@
DEV_TX_OFFLOAD_VLAN_INSERT)
 
 #define HN_RX_OFFLOAD_CAPS (DEV_RX_OFFLOAD_CHECKSUM | \
-   DEV_RX_OFFLOAD_VLAN_STRIP)
+   DEV_RX_OFFLOAD_VLAN_STRIP | \
+   DEV_RX_OFFLOAD_RSS_HASH)
 
 int hn_logtype_init;
 int hn_logtype_driver;
-- 
2.20.1

[dpdk-dev] [PATCH v2 0/2] bugfix to netvsc PMD in 19.11

[Stephen Hemminger]

This is a resend of earlier bug fix and an additional
fix for RSS flags

Stephen Hemminger (2):
  net/netvsc: fix RSS offload flag
  net/netvsc: disable before changing RSS parameters

 drivers/net/netvsc/hn_ethdev.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

-- 
2.20.1

[dpdk-dev] [PATCH 1/3] ethdev: add RSS hash level

[Ajit Khaparde]

This patch adds ability to configure RSS hash level in hardware.
This feature will allow an application to select RSS hash calculation
on outer or inner headers for tunneled packets.

Signed-off-by: Ajit Khaparde 
---
 lib/librte_ethdev/rte_ethdev.h | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 18a9defc2..5189bdbab 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -444,11 +444,35 @@ struct rte_vlan_filter_conf {
  * The *rss_hf* field of the *rss_conf* structure indicates the different
  * types of IPv4/IPv6 packets to which the RSS hashing must be applied.
  * Supplying an *rss_hf* equal to zero disables the RSS feature.
+ *
+ * The *rss_level* field of the *rss_conf* structure indicates the
+ * Packet encapsulation level RSS hash @p types apply to.
+ *
+ * - @p 0 requests the default behavior. Depending on the packet
+ *   type, it can mean outermost, innermost, anything in between or
+ *   even no RSS.
+ *
+ *   It basically stands for the innermost encapsulation level RSS
+ *   can be performed on according to PMD and device capabilities.
+ *
+ * - @p 1 requests RSS to be performed on the outermost packet
+ *   encapsulation level.
+ *
+ * - @p 2 and subsequent values request RSS to be performed on the
+ *   specified inner packet encapsulation level, from outermost to
+ *   innermost (lower to higher values).
+ *
+ * Support for values other than @p 0 is dependent on the underlying
+ * hardware in use.
+ *
+ * Requesting a specific RSS level on unrecognized traffic results
+ * in undefined behavior.
  */
 struct rte_eth_rss_conf {
uint8_t *rss_key;/**< If not NULL, 40-byte hash key. */
uint8_t rss_key_len; /**< hash key length in bytes. */
uint64_t rss_hf; /**< Hash functions to apply - see below. */
+   uint32_t rss_level;  /**< RSS hash level */
 };
 
 /*
@@ -599,6 +623,8 @@ rte_eth_rss_hf_refine(uint64_t rss_hf)
ETH_RSS_GENEVE | \
ETH_RSS_NVGRE)
 
+#define ETH_RSS_LEVEL_DEFAULT  0
+
 /*
  * Definitions used for redirection table entry size.
  * Some RSS RETA sizes may not be supported by some drivers, check the
@@ -1103,6 +1129,7 @@ struct rte_eth_conf {
 #define DEV_RX_OFFLOAD_SCTP_CKSUM  0x0002
 #define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM  0x0004
 #define DEV_RX_OFFLOAD_RSS_HASH0x0008
+#define DEV_RX_OFFLOAD_RSS_LEVEL   0x0010
 
 #define DEV_RX_OFFLOAD_CHECKSUM (DEV_RX_OFFLOAD_IPV4_CKSUM | \
 DEV_RX_OFFLOAD_UDP_CKSUM | \
-- 
2.21.0 (Apple Git-122.2)

[dpdk-dev] [PATCH 0/3] add support for RSS level

[Ajit Khaparde]

Some of NICs can allow a DPDK application to select the RSS level
to perform RSS hash on an incoming encapsulated packets. But it is
not possible to set this currently because rte_eth_rss_conf does
not have any field to indicate the RSS level while specifying RSS
configuration parameters.

This patchset extends rte_eth_rss_conf by adding rss_level.
An application can specify the RSS level based on the packet
encapsulation level and apply the setting to the specified device.

- rss_level of 0 requests the default behavior.
- rss_level of 1 requests RSS to be performed on the outermost packet
encapsulation level.
- rss_level of 2 and subsequent values request RSS to be performed
on the specified inner packet encapsulation level, from outermost to
innermost.

Patch 1/3 extends rte_ethdev.h to add this support.
Patch 2/3 has modifications to testpmd to use this feature.
Patch 3/3 has bnxt modifications to configure rss_level based on the
settings passed by the application.


Please review.


Ajit Khaparde (3):
  ethdev: add RSS hash level
  app/testpmd: support RSS hash level setting
  net/bnxt: add support to set RSS hash level

 app/test-pmd/cmdline.c | 187 +
 app/test-pmd/config.c  |   7 ++
 app/test-pmd/parameters.c  |   6 +-
 app/test-pmd/testpmd.c |   8 ++
 app/test-pmd/testpmd.h |   1 +
 drivers/net/bnxt/bnxt.h|   1 +
 drivers/net/bnxt/bnxt_ethdev.c |   7 ++
 drivers/net/bnxt/bnxt_hwrm.c   |   9 +-
 drivers/net/bnxt/bnxt_rxq.c|   3 +
 drivers/net/bnxt/bnxt_vnic.c   |  75 +
 drivers/net/bnxt/bnxt_vnic.h   |   4 +
 lib/librte_ethdev/rte_ethdev.h |  27 +
 12 files changed, 332 insertions(+), 3 deletions(-)

-- 
2.21.0 (Apple Git-122.2)

[dpdk-dev] [PATCH 2/3] app/testpmd: support RSS hash level setting

[Ajit Khaparde]

This patch adds support to configure RSS hash level for the device.

Example testpmd commands to set the RSS hash level using testpmd cli:

port config  rss_level 
port config all rss_level 

Example command to set the RSS hash level using an argument to testpmd:

./build/app/testpmd -l1-4 -n2 -- -i --rxq= --txq= --rss-level=

Example testpmd commands to get the RSS hash level:

show port  rss-hash

Signed-off-by: Ajit Khaparde 
---
 app/test-pmd/cmdline.c| 187 ++
 app/test-pmd/config.c |   7 ++
 app/test-pmd/parameters.c |   6 +-
 app/test-pmd/testpmd.c|   8 ++
 app/test-pmd/testpmd.h|   1 +
 5 files changed, 208 insertions(+), 1 deletion(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 2d74df896..225ec3034 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -795,6 +795,9 @@ static void cmd_help_long_parsed(void *parsed_result,
"port config port-id rss reta 
(hash,queue)[,(hash,queue)]\n"
"Set the RSS redirection table.\n\n"
 
+   "port config (port_id|all) rss_level (value)\n"
+   "Set the RSS hash level for the port.\n\n"
+
"port config (port_id) dcb vt (on|off) (traffic_class)"
" pfc (on|off)\n"
"Set the DCB mode.\n\n"
@@ -2303,6 +2306,7 @@ cmd_config_rss_parsed(void *parsed_result,
return;
}
rss_conf.rss_key = NULL;
+   rss_conf.rss_level = rss_level;
/* Update global configuration for RSS types. */
RTE_ETH_FOREACH_DEV(i) {
struct rte_eth_rss_conf local_rss_conf;
@@ -2360,6 +2364,187 @@ cmdline_parse_inst_t cmd_config_rss = {
},
 };
 
+/* *** configure rss level all ports *** */
+struct cmd_config_rss_level {
+   cmdline_fixed_string_t port;
+   cmdline_fixed_string_t keyword;
+   cmdline_fixed_string_t all;
+   cmdline_fixed_string_t name;
+   uint32_t value;
+};
+
+static void
+cmd_config_rss_level_parsed(void *parsed_result,
+   __attribute__((unused)) struct cmdline *cl,
+   __attribute__((unused)) void *data)
+{
+   struct cmd_config_rss_level *res = parsed_result;
+   int all_updated = 1;
+   int diag;
+   uint16_t i;
+
+   /* Update global configuration for RSS hash level. */
+   RTE_ETH_FOREACH_DEV(i) {
+   struct rte_eth_rss_conf rss_conf;
+   struct rte_eth_dev_info dev_info;
+
+   diag = eth_dev_info_get_print_err(i, &dev_info);
+   if (diag != 0)
+   return;
+
+   if (!(dev_info.rx_offload_capa & DEV_RX_OFFLOAD_RSS_LEVEL)) {
+   printf("Port %d does not support RSS hash level "
+  "selection\n", i);
+   return;
+   }
+
+   rss_conf.rss_key = NULL;
+   diag = rte_eth_dev_rss_hash_conf_get(i, &rss_conf);
+   if (diag) {
+   printf("Port %d failed to get RSS hash config with "
+  "error (%d): %s.\n",
+  i, -diag, strerror(-diag));
+   return;
+   }
+
+   if (rss_conf.rss_level == res->value)
+   return;
+
+   printf("Port %d modifying RSS hash level based on "
+  "hardware support. Requested:%d Current:%d\n",
+   i, res->value, rss_conf.rss_level);
+
+   rss_conf.rss_level = res->value;
+   diag = rte_eth_dev_rss_hash_update(i, &rss_conf);
+   if (diag < 0) {
+   all_updated = 0;
+   printf("Configuration of RSS hash at ethernet port %d "
+   "failed with error (%d): %s.\n",
+   i, -diag, strerror(-diag));
+   }
+   }
+   if (all_updated)
+   rss_level = res->value;
+}
+
+cmdline_parse_token_string_t cmd_config_rss_level_port =
+   TOKEN_STRING_INITIALIZER(struct cmd_config_rss_level, port, "port");
+cmdline_parse_token_string_t cmd_config_rss_level_keyword =
+   TOKEN_STRING_INITIALIZER(struct cmd_config_rss_level, keyword,
+"config");
+cmdline_parse_token_string_t cmd_config_rss_level_all =
+   TOKEN_STRING_INITIALIZER(struct cmd_config_rss_level, all, "all");
+cmdline_parse_token_string_t cmd_config_rss_level_item =
+   TOKEN_STRING_INITIALIZER(struct cmd_config_rss_level, name,
+"rss_level");
+cmdline_parse_token_num_t cmd_config_rss_level_value =
+   TOKEN_NUM_INITIALIZER(struct cmd_config_rss_level, value, UINT16);
+
+cmdline_parse_inst_t cmd_config_rss_level = {
+   .f = cmd_config_rss_level_parsed,
+   .data = NULL,
+   .help_str = "po

[dpdk-dev] [PATCH 3/3] net/bnxt: add support to set RSS hash level

[Ajit Khaparde]

This patch adds support to configure RSS hash level in the hardware,
if the firmware advertises such a capability.

Signed-off-by: Ajit Khaparde 
---
 drivers/net/bnxt/bnxt.h|  1 +
 drivers/net/bnxt/bnxt_ethdev.c |  7 
 drivers/net/bnxt/bnxt_hwrm.c   |  9 +++-
 drivers/net/bnxt/bnxt_rxq.c|  3 ++
 drivers/net/bnxt/bnxt_vnic.c   | 75 ++
 drivers/net/bnxt/bnxt_vnic.h   |  4 ++
 6 files changed, 97 insertions(+), 2 deletions(-)

diff --git a/drivers/net/bnxt/bnxt.h b/drivers/net/bnxt/bnxt.h
index e259c8239..d796ac539 100644
--- a/drivers/net/bnxt/bnxt.h
+++ b/drivers/net/bnxt/bnxt.h
@@ -536,6 +536,7 @@ struct bnxt {
 
uint32_tvnic_cap_flags;
 #define BNXT_VNIC_CAP_COS_CLASSIFY BIT(0)
+#define BNXT_VNIC_CAP_OUTER_RSSBIT(1)
unsigned intrx_nr_rings;
unsigned intrx_cp_nr_rings;
unsigned intrx_num_qs_per_vnic;
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index c70b072bf..a12aecc26 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -524,6 +524,8 @@ static int bnxt_dev_info_get_op(struct rte_eth_dev *eth_dev,
dev_info->rx_offload_capa = BNXT_DEV_RX_OFFLOAD_SUPPORT;
if (bp->flags & BNXT_FLAG_PTP_SUPPORTED)
dev_info->rx_offload_capa |= DEV_RX_OFFLOAD_TIMESTAMP;
+   if (bp->vnic_cap_flags & BNXT_VNIC_CAP_OUTER_RSS)
+   dev_info->rx_offload_capa |= DEV_RX_OFFLOAD_RSS_LEVEL;
dev_info->tx_offload_capa = BNXT_DEV_TX_OFFLOAD_SUPPORT;
dev_info->flow_type_rss_offloads = BNXT_ETH_RSS_SUPPORT;
 
@@ -1404,6 +1406,8 @@ static int bnxt_rss_hash_update_op(struct rte_eth_dev 
*eth_dev,
/* Update the default RSS VNIC(s) */
vnic = BNXT_GET_DEFAULT_VNIC(bp);
vnic->hash_type = bnxt_rte_to_hwrm_hash_types(rss_conf->rss_hf);
+   vnic->hash_mode = bnxt_rte_to_hwrm_hash_level(bp, rss_conf->rss_level,
+ rss_conf->rss_hf);
 
/*
 * If hashkey is not specified, use the previously configured
@@ -1438,6 +1442,9 @@ static int bnxt_rss_hash_conf_get_op(struct rte_eth_dev 
*eth_dev,
 
/* RSS configuration is the same for all VNICs */
if (vnic && vnic->rss_hash_key) {
+   rss_conf->rss_level =
+   bnxt_hwrm_to_rte_rss_level(bp, vnic->hash_mode);
+
if (rss_conf->rss_key) {
len = rss_conf->rss_key_len <= HW_HASH_KEY_SIZE ?
  rss_conf->rss_key_len : HW_HASH_KEY_SIZE;
diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
index b1f908ee4..aba1ef34b 100644
--- a/drivers/net/bnxt/bnxt_hwrm.c
+++ b/drivers/net/bnxt/bnxt_hwrm.c
@@ -704,6 +704,7 @@ int bnxt_hwrm_func_qcaps(struct bnxt *bp)
 int bnxt_hwrm_vnic_qcaps(struct bnxt *bp)
 {
int rc = 0;
+   uint32_t flags;
struct hwrm_vnic_qcaps_input req = {.req_type = 0 };
struct hwrm_vnic_qcaps_output *resp = bp->hwrm_cmd_resp_addr;
 
@@ -715,12 +716,16 @@ int bnxt_hwrm_vnic_qcaps(struct bnxt *bp)
 
HWRM_CHECK_RESULT();
 
-   if (rte_le_to_cpu_32(resp->flags) &
-   HWRM_VNIC_QCAPS_OUTPUT_FLAGS_COS_ASSIGNMENT_CAP) {
+   flags = rte_le_to_cpu_32(resp->flags);
+
+   if (flags & HWRM_VNIC_QCAPS_OUTPUT_FLAGS_COS_ASSIGNMENT_CAP) {
bp->vnic_cap_flags |= BNXT_VNIC_CAP_COS_CLASSIFY;
PMD_DRV_LOG(INFO, "CoS assignment capability enabled\n");
}
 
+   if (flags & HWRM_VNIC_QCAPS_OUTPUT_FLAGS_OUTERMOST_RSS_CAP)
+   bp->vnic_cap_flags |= BNXT_VNIC_CAP_OUTER_RSS;
+
bp->max_tpa_v2 = rte_le_to_cpu_16(resp->max_aggs_supported);
 
HWRM_UNLOCK();
diff --git a/drivers/net/bnxt/bnxt_rxq.c b/drivers/net/bnxt/bnxt_rxq.c
index 457ebede0..fabc4663c 100644
--- a/drivers/net/bnxt/bnxt_rxq.c
+++ b/drivers/net/bnxt/bnxt_rxq.c
@@ -177,6 +177,9 @@ int bnxt_mq_rx_configure(struct bnxt *bp)
vnic = &bp->vnic_info[i];
vnic->hash_type =
bnxt_rte_to_hwrm_hash_types(rss->rss_hf);
+   vnic->hash_mode =
+   bnxt_rte_to_hwrm_hash_level(bp, rss->rss_level,
+   rss->rss_hf);
 
/*
 * Use the supplied key if the key length is
diff --git a/drivers/net/bnxt/bnxt_vnic.c b/drivers/net/bnxt/bnxt_vnic.c
index 104342e13..8aebb6069 100644
--- a/drivers/net/bnxt/bnxt_vnic.c
+++ b/drivers/net/bnxt/bnxt_vnic.c
@@ -261,3 +261,78 @@ uint16_t bnxt_rte_to_hwrm_hash_types(uint64_t rte_type)
 
return hwrm_type;
 }
+
+int bnxt_rte_to_hwrm_hash_level(struct bnxt *bp,
+   uint32_t rss_level,
+   uint64_t hash_f)
+{
+   int mode = HWRM_VNIC_RSS_CFG_INPUT_HASH_