[dpdk-dev] [PATCH v2] tools: add crypto device details

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Eoin Breen
> Sent: Thursday, August 25, 2016 6:52 AM
> To: Jain, Deepak K; Trahe, Fiona; Griffin, John
> Cc: dev at dpdk.org; Breen, Eoin
> Subject: [dpdk-dev] [PATCH v2] tools: add crypto device details
> 
> Adding the support to bind/unbind crypto devices with
> dpdk-devbind.py script, as now it is not restricted
> to network devices anymore.
> 
> Signed-off-by: Eoin Breen 
> ---
> Changes since v1:
> * Resolved coding issues
> 
>  tools/dpdk-devbind.py | 107
> ++
>  1 file changed, 99 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/dpdk-devbind.py b/tools/dpdk-devbind.py
> index b69ca2a..c7576b9 100755
> --- a/tools/dpdk-devbind.py
> +++ b/tools/dpdk-devbind.py

...

> +# check what is the interface if any for an ssh connection if
> +# any to this host, so we can mark it later.
> +ssh_if = []
> +route = check_output(["ip", "-o", "route"])
> +# filter out all lines for 169.254 routes
> +route = "\n".join(filter(lambda ln: not ln.startswith("169.254"),
> + route.decode().splitlines()))
> +rt_info = route.split()
> +for i in range(len(rt_info) - 1):
> +if rt_info[i] == "dev":
> +ssh_if.append(rt_info[i+1])

This is relevant only to network devices, so it should not be included here.
> +
> +# based on the basic info, get extended text details
> +for d in devices.keys():
> +# get additional info and add it to existing data
> +devices[d] = devices[d].copy()
> +devices[d].update(get_pci_device_details(d).items())
> +
> +for _if in ssh_if:
> +if _if in devices[d]["Interface"].split(","):
> +devices[d]["Ssh_if"] = True
> +devices[d]["Active"] = "*Active*"
> +break

Same here.

> +
> +# add igb_uio to list of supporting modules if needed
> +if "Module_str" in devices[d]:
> +for driver in dpdk_drivers:
> +if driver not in devices[d]["Module_str"]:
> +devices[d]["Module_str"] = \
> +devices[d]["Module_str"] + ",%s" % driver
> +else:
> +devices[d]["Module_str"] = ",".join(dpdk_drivers)
> +
> +# make sure the driver and module strings do not have any duplicates
> +if has_driver(d):
> +modules = devices[d]["Module_str"].split(",")
> +if devices[d]["Driver_str"] in modules:
> +modules.remove(devices[d]["Driver_str"])
> +devices[d]["Module_str"] = ",".join(modules)
> +
> +
>  def dev_id_from_dev_name(dev_name):
>  '''Take a device "name" - a string passed in by user to identify a NIC
>  device, and determine the device id - i.e. the domain:bus:slot.func - for
> @@ -480,15 +546,16 @@ def show_status():
>  dpdk_drv = []
>  no_drv = []
> 
> -# split our list of devices into the three categories above
> +# split our list of network devices into the three categories above
>  for d in devices.keys():
> -if not has_driver(d):
> -no_drv.append(devices[d])
> -continue
> -if devices[d]["Driver_str"] in dpdk_drivers:
> -dpdk_drv.append(devices[d])
> -else:
> -kernel_drv.append(devices[d])
> +if (NETWORK_BASE_CLASS in devices[d]["Class"]):
> +if not has_driver(d):
> +no_drv.append(devices[d])
> +continue
> +if devices[d]["Driver_str"] in dpdk_drivers:
> +dpdk_drv.append(devices[d])
> +else:
> +kernel_drv.append(devices[d])
> 
>  # print each category separately, so we can clearly see what's used by
> DPDK
>  display_devices("Network devices using DPDK-compatible driver",
> dpdk_drv,
> @@ -498,6 +565,28 @@ def show_status():
>  "unused=%(Module_str)s %(Active)s")
>  display_devices("Other network devices", no_drv,
> "unused=%(Module_str)s")
> 
> +# split our list of crypto devices into the three categories above
> +kernel_drv = []
> +dpdk_drv = []
> +no_drv = []
> +
> +for d in devices.keys():
> +if (CRYPTO_BASE_CLASS in devices[d]["Class"]):
> +if not has_driver(d):
> +no_drv.append(devices[d])
> +continue
> +if devices[d]["Driver_str"] in dpdk_drivers:
> +dpdk_drv.append(devices[d])
> +else:
> +kernel_drv.append(devices[d])
> +
> +display_devices("Crypto devices using DPDK-compatible driver",
> dpdk_drv,
> +"drv=%(Driver_str)s unused=%(Module_str)s")
> +display_devices("Crypto devices using kernel driver", kernel_drv,
> +"if=%(Interface)s drv=%(Driver_str)s "
> +"unused=%(Module_str)s %(Active)s")
> +

[dpdk-dev] [PATCH] rte_delay_us can be replaced with user function

[Thomas Monjalon]

Hi,

Sorry for late review.
This patch was in a summer hole :/

First a general comment: please check your patch with
scripts/checkpatches.sh.
In order to ease tracking of this patch, please increment the version
when sending a new one in the same thread:
git send-email -1 -v3 --annotate --to dev at dpdk.org \
--in-reply-to 1469016644-6521-1-git-send-email-jozmarti at cisco.com

More comments below.

2016-07-20 14:10, jozmarti at cisco.com:
> +void rte_delay_us_callback_register(void (*userfunc)(unsigned))
> +{
> +if (userfunc == NULL)
> +rte_delay_us = rte_delay_us_block;

Here you are creating an exception for rte_delay_us_block which is
mapped as a NULL handler.
What will happen if we need to provide more builtin handlers?
I still think that rte_delay_us_block can be exported and initialized
as the default handler. Other opinions are obviously welcome.

> +else
> +rte_delay_us = userfunc;
> +}
> +
> +static void __attribute__((constructor))
> +rte_timer_init(void)
> +{
> +/* set rte_delay_us_block as a delay function */
> +rte_delay_us_callback_register(NULL);
> +}
> diff --git a/lib/librte_eal/common/include/generic/rte_cycles.h 
> b/lib/librte_eal/common/include/generic/rte_cycles.h
> index 8cc21f2..7a45b58 100644
> --- a/lib/librte_eal/common/include/generic/rte_cycles.h
> +++ b/lib/librte_eal/common/include/generic/rte_cycles.h
> @@ -182,13 +182,16 @@ rte_get_timer_hz(void)
>  }
>  
>  /**
> + *

useless newline

>   * Wait at least us microseconds.
> + * This function can be replaced with user-defined function using
> + * rte_delay_us_callback_register

I think you can use @see to point to rte_delay_us_callback_register.

>   *
>   * @param us
>   *   The number of microseconds to wait.
>   */
>  void
> -rte_delay_us(unsigned us);
> +(*rte_delay_us)(unsigned us);
>  
>  /**
>   * Wait at least ms milliseconds.
> @@ -202,4 +205,14 @@ rte_delay_ms(unsigned ms)
>   rte_delay_us(ms * 1000);
>  }
>  
> +/**
> + * Replace rte_delay_us with user defined function.
> + *
> + * @param userfunc
> + *   User function which replaces rte_delay_us. NULL restores
> + *   buildin block delay function.

buildin -> builtin ?

> + */
> +void rte_delay_us_callback_register(void(*userfunc)(unsigned));

[dpdk-dev] [PATCH v2 0/2] Add HMAC_MD5 to Intel QuickAssist Technology driver

[De Lara Guarch, Pablo]

> -Original Message-
> From: Jain, Deepak K
> Sent: Friday, September 09, 2016 8:45 AM
> To: dev at dpdk.org
> Cc: De Lara Guarch, Pablo; Jain, Deepak K
> Subject: [PATCH v2 0/2] Add HMAC_MD5 to Intel QuickAssist Technology
> driver
> 
> This patchset add capability to use HMAC_MD5 hash algorithm to Intel
> QuickAssist Technology driver and test cases to cryptodev test files.
> 
> This patchset depends on the following patches/patchsets:
> 
> "crypto/qat: make the session struct variable in size"
> (http://dpdk.org/dev/patchwork/patch/15125/)
> 
> Arkadiusz Kusztal (2):
>   crypto/qat: add MD5 HMAC capability to Intel QAT driver
>   app/test: add test cases for MD5 HMAC for Intel QAT driver
> 
> Changes from v1:
> * Added new feature information in release_16_11.rst file.
> 
>  app/test/test_cryptodev.c| 185 
> +++
>  app/test/test_cryptodev_hmac_test_vectors.h  | 121 +++
>  doc/guides/cryptodevs/qat.rst|   1 +
>  doc/guides/rel_notes/release_16_11.rst   |   5 +
>  drivers/crypto/qat/qat_adf/qat_algs_build_desc.c |  34 +
>  drivers/crypto/qat/qat_crypto.c  |  28 +++-
>  6 files changed, 372 insertions(+), 2 deletions(-)
>  create mode 100644 app/test/test_cryptodev_hmac_test_vectors.h
> 
> --
> 2.5.5

Applied to dpdk-next-crypto.
Thanks,

Pablo

[dpdk-dev] [PATCH] vhost: change the vhost library to a common framework which can support more VIRTIO devices

[Yuanhan Liu]

On Tue, Sep 13, 2016 at 03:24:53PM +0200, Thomas Monjalon wrote:
> 2016-09-13 20:58, Yuanhan Liu:
> > rte_virtio_net.h is the header file will be exported for applications.
> > Every change there would mean either an API or ABI breakage. Thus, we
> > should try to avoid touching it. Don't even to say you added yet another
> > header file, rte_virtio_dev.h.
> > 
> > I confess that the rte_virtio_net.h filename isn't that right: it sticks
> > to virtio-net so tightly. We may could rename it to rte_vhost.h, but I
> > doubt it's worthwhile: as said, it breaks the API.
> > 
> > The fortunate thing about this file is that, the context is actually not
> > sticking to virtio-net too much. I mean, all the APIs are using the "vid",
> > which is just a number. Well, except the virtio_net_device_ops() structure,
> > which also should be renamed to vhost_device_ops(). Besides that, the
> > three ops, "new_device", "destroy_device" and "vring_state_changed", are
> > actually not limited to virtio-net device.
> > 
> > That is to say, we could have two options here:
> > 
> > - rename the header file and the structure properly, to not limited to
> >   virtio-net
> > 
> > - live with it, let it be a legacy issue, and document it at somewhere,
> >   say, "due to history reason, that virtio-net is the first one supported
> >   in DPDK, we kept the header filename as rte_virtio_net.h, but not ..."
> > 
> > I personally would prefer the later one, which saves us from breaking
> > applications again. I don't have strong objection to the first one though.
> > 
> > Thomas, any comments?
> 
> I don't think keeping broken names for historical reasons is a good
> long term maintenance.

Good point.

> It could be a FIXME comment that we would fix when we have other reasons
> to break the API.
> However, in this case, it is easy to keep the compatibility, I think,
> by including rte_virtio.h in rte_virtio_net.h.

Nice trick!

> Note: renames can also generally be managed with symlinks.
> 
> I also don't really understand why this file name is rte_virtio_net.h and
> not rte_vhost_net.h.

No idea. It's just named so since the beginning. Also I missed this file
while doing the ABI/API refactoring, otherwise, it would be no pain at
this stage.

--yliu

[dpdk-dev] [PATCH] nfp: using random mac address if not a configured mac

[Thomas Monjalon]

2016-09-13 18:10, Ferruh Yigit:
> Hi Alejandro,
> 
> On 8/16/2016 4:15 PM, Alejandro Lucero wrote:
> > Signed-off-by: Alejandro Lucero 
> > ---
> 
> There are following checkpatch warnings, also check-git-log complains:
> 
> Headline too long:
> nfp: unregister interrupt callback function when closing device

Just a tip to keep headlines short: you can often remove some common words.
Here we still understand the idea without "function" and "device".
nfp: unregister interrupt callback when closing

[dpdk-dev] [PATCH] vhost: change the vhost library to a common framework which can support more VIRTIO devices

[Yuanhan Liu]

On Wed, Sep 14, 2016 at 08:15:00PM +0800, Changpeng Liu wrote:
> For storage virtualization use cases, vhost-scsi becomes a more popular
> solution to support VMs. However a user space vhost-scsi-user solution
> does not exist currently. SPDK(Storage Performance Development Kit,
> https://github.com/spdk/spdk) will provide a user space vhost-scsi target
> to support multiple VMs through Qemu. Originally SPDK is built on top
> of DPDK libraries, so we would like to use DPDK vhost library as the
> communication channel between Qemu and vhost-scsi target application.
> 
> Currently DPDK vhost library can only support VIRTIO_ID_NET device type,
> we would like to extend the library to support VIRTIO_ID_SCSI and
> VIRTIO_ID_BLK. Most of DPDK vhost library can be reused only several
> differences:
> 1. VIRTIO SCSI device has different vring queues compared with VIRTIO NET
> device, at least 3 vring queues needed for SCSI device type;
> 2. VIRTIO SCSI will need several extra message operation code, such as
> SCSI_SET_ENDPIONT/SCSI_CLEAR_ENDPOINT;
> 
> First, we would like to extend DPDK vhost library as a common framework

I don't see how common it becomes with this patch applied.

> which be friendly to add other VIRTIO device types, to implement this feature,
> we add a new data structure virtio_dev, which can deliver socket messages
> to different VIRTIO devices, each specific VIRTIO device will register
> callback to virtio_dev.
> 
> Secondly, we would to upstream a patch to Qemu community to add vhost-scsi
> specific operation command such as SCSI_SET_ENDPOINT and SCSI_CLEAR_ENDOINT,
> and user space feature bits.
> 
> Finally, after the Qemu patch set was merged, we will add VIRTIO_ID_SCSI
> support to DPDK vhost library

You actually should send this part out with this patchset. You are making
changes for adding the vhost-scsi support, however, you don't show us how
the code to support vhost-scsi looks like. That means, it's hard for us to
understand why you are doing those changes.

What I said is DPDK will not consider merging vhost-scsi patches unless
QEMU have merged the vhost-scsi part. This doesn't mean you can't send
out the DPDK vhost-scsi patches before that.

> and an example vhost-scsi target which can
> add a SCSI device to VM through this example application.
> 
> This patch set changed the vhost library as a common framework which
> can add other VIRTIO device type in future.
> 
> Signed-off-by: Changpeng Liu 
> ---
>  lib/librte_vhost/Makefile |   4 +-
>  lib/librte_vhost/rte_virtio_dev.h | 140 
>  lib/librte_vhost/rte_virtio_net.h |  97 +-

rte_virtio_net.h is the header file will be exported for applications.
Every change there would mean either an API or ABI breakage. Thus, we
should try to avoid touching it. Don't even to say you added yet another
header file, rte_virtio_dev.h.

I confess that the rte_virtio_net.h filename isn't that right: it sticks
to virtio-net so tightly. We may could rename it to rte_vhost.h, but I
doubt it's worthwhile: as said, it breaks the API.

The fortunate thing about this file is that, the context is actually not
sticking to virtio-net too much. I mean, all the APIs are using the "vid",
which is just a number. Well, except the virtio_net_device_ops() structure,
which also should be renamed to vhost_device_ops(). Besides that, the
three ops, "new_device", "destroy_device" and "vring_state_changed", are
actually not limited to virtio-net device.

That is to say, we could have two options here:

- rename the header file and the structure properly, to not limited to
  virtio-net

- live with it, let it be a legacy issue, and document it at somewhere,
  say, "due to history reason, that virtio-net is the first one supported
  in DPDK, we kept the header filename as rte_virtio_net.h, but not ..."

I personally would prefer the later one, which saves us from breaking
applications again. I don't have strong objection to the first one though.

Thomas, any comments?

>  lib/librte_vhost/socket.c |   6 +-
>  lib/librte_vhost/vhost.c  | 421 
>  lib/librte_vhost/vhost.h  | 288 -
>  lib/librte_vhost/vhost_device.h   | 230 +
>  lib/librte_vhost/vhost_net.c  | 659 
> ++
>  lib/librte_vhost/vhost_net.h  | 126 
>  lib/librte_vhost/vhost_user.c | 451 +-
>  lib/librte_vhost/vhost_user.h |  17 +-
>  lib/librte_vhost/virtio_net.c |  37 ++-

That basically means you are heading the wrong way. For example,

> +struct virtio_dev_table {
> + int (*vhost_dev_ready)(struct virtio_dev *dev);
> + struct vhost_virtqueue* (*vhost_dev_get_queues)(struct virtio_dev *dev, 
> uint16_t queue_id);
> + void (*vhost_dev_cleanup)(struct virtio_dev *dev, int destroy);
> + void (*vhost_dev_free)(struct virtio_dev *dev);
> + void (*vhost_dev_reset)(struct virtio_dev *dev);
> + uint64_t 

[dpdk-dev] [RFC][PATCH V2 2/3] examples/vhost: Add vswitch command line options

[Yuanhan Liu]

On Mon, Sep 05, 2016 at 04:24:30PM +0530, Pankaj Chauhan wrote:
> Add command line options for selecting switch implementation
> and maximum ports for the vswitch.following are two new command
> line options:
> 
> --switch  [char string, Selects the switch imlementation]
> --max-ports [int, selects maximum number of ports to support]
> 
> For example:
> 
> $ ./vhost-switch -c 3 -n 2 --socket-mem 1024 --huge-dir /hugetlbfs -- -p
> 0x1 --dev-basename sock1

That means you were basing on the master branch. You should base on
next-virtio instead: http://dpdk.org/browse/next/dpdk-next-virtio/

> --switch "vmdq" --max-ports 3

Normally, we should keep the old behaviour first. Say, making the vmdq
as the default switch mode.

However, actually, I don't quite like to make the vhost-switch to bind
to a hardare feature that tightly, that you may want to make a standalone
patch as the last one in this patchset to make the "switch" mode be the
default one.

> 
> Signed-off-by: Pankaj Chauhan 
> ---
>  examples/vhost/main.c | 43 +++
>  1 file changed, 43 insertions(+)
> 
> diff --git a/examples/vhost/main.c b/examples/vhost/main.c
> index c949df4..a4e51ae 100644
> --- a/examples/vhost/main.c
> +++ b/examples/vhost/main.c
> @@ -142,6 +142,10 @@ static uint32_t burst_rx_retry_num = BURST_RX_RETRIES;
>  /* Character device basename. Can be set by user. */
>  static char dev_basename[MAX_BASENAME_SZ] = "vhost-net";
>  
> +/* vswitch device name and maximum number of ports */
> +static char switch_dev[MAX_BASENAME_SZ] = "vmdq";

First of all, limiting it with MAX_BASENAME_SZ makes no sense here.

Secondly, you don't have to represent the switch mode with string,
you could simply use some numeric macros, or enum.

Besides, I just had a quick glimplse of your patches (still couldn't
make a detailed look so far), and I'd ask you to do few more things
for v3:

- I'm hoping you could split this patchset further, say **maybe**
  one patch to introduce vswitch_port, one to introduce vswitch_ops
  and another one to introduce vswitch_dev. This helps review.

- make sure each commit is buldable.


And few more generic comments to the whole set:

- use "__rte_unused" but not "__attribute__((unused))"
  And we normally use it after but not before the key word.

- follow the DPDK prefered way to define a function, the return type
  and function name takes two lines.

- run scripts/{checkpatches.sh,check-git-log.sh} and fix real warnings
  if any before sending them out.

  This would at least help you catch "line over 80 chars" issue. 

Thanks.
--yliu

[dpdk-dev] [PATCH] nfp: using random mac address if not a configured mac

[Ferruh Yigit]

On 9/13/2016 6:10 PM, Ferruh Yigit wrote:
> Hi Alejandro,
> 
> On 8/16/2016 4:15 PM, Alejandro Lucero wrote:
>> Signed-off-by: Alejandro Lucero 
>> ---
> 
> There are following checkpatch warnings, also check-git-log complains:
> 
> Headline too long:
> nfp: unregister interrupt callback function when closing device
> 

copy-paste error, this one gives following, again because of "mac" usage:

Wrong headline lowercase:
nfp: using random mac address if not a configured mac


> ...
> 
>>  
>> +static void nfp_net_read_mac(struct nfp_net_hw *hw) {
>> +
> 
> ERROR:OPEN_BRACE: open brace '{' following function declarations go on
> the next line
> #45: FILE: drivers/net/nfp/nfp_net.c:620:
> +static void nfp_net_read_mac(struct nfp_net_hw *hw) {
> 
> ...
> 
>> +if (!is_valid_assigned_ether_addr((struct ether_addr 
>> *)>mac_addr[0]))
> 
> WARNING:LONG_LINE: line over 80 characters
> #67: FILE: drivers/net/nfp/nfp_net.c:2419:
> +   if (!is_valid_assigned_ether_addr((struct ether_addr
> *)>mac_addr[0]))
> 
>> +/* Using random mac addresses for VFs */
> 

[dpdk-dev] [PATCH] nfp: unregister interrupt callback function when closing device

[Ferruh Yigit]

On 8/16/2016 4:57 PM, Alejandro Lucero wrote:
> With an app using hotplug feature, when a device is unplugged without
> unregistering makes the interrupt handling unstable.
> 
> Fixes: 6c53f87b3497 ("nfp: add link status interrupt")
> 
> Signed-off-by: Alejandro Lucero 

Headline too long:
nfp: unregister interrupt callback function when closing device

[dpdk-dev] [PATCH] nfp: fixing bug when copying mac address

[Ferruh Yigit]

On 8/16/2016 4:31 PM, Alejandro Lucero wrote:
> Fixes: defb9a5dd156 ("nfp: introduce driver initialization")
> 
> Signed-off-by: Alejandro Lucero 

check-git-log warning, looks like because of "mac" which should be
uppercase:

Wrong headline lowercase:
nfp: fixing bug when copying mac address

[dpdk-dev] [PATCH] nfp: using random mac address if not a configured mac

[Ferruh Yigit]

Hi Alejandro,

On 8/16/2016 4:15 PM, Alejandro Lucero wrote:
> Signed-off-by: Alejandro Lucero 
> ---

There are following checkpatch warnings, also check-git-log complains:

Headline too long:
nfp: unregister interrupt callback function when closing device

...

>  
> +static void nfp_net_read_mac(struct nfp_net_hw *hw) {
> +

ERROR:OPEN_BRACE: open brace '{' following function declarations go on
the next line
#45: FILE: drivers/net/nfp/nfp_net.c:620:
+static void nfp_net_read_mac(struct nfp_net_hw *hw) {

...

> + if (!is_valid_assigned_ether_addr((struct ether_addr 
> *)>mac_addr[0]))

WARNING:LONG_LINE: line over 80 characters
#67: FILE: drivers/net/nfp/nfp_net.c:2419:
+   if (!is_valid_assigned_ether_addr((struct ether_addr
*)>mac_addr[0]))

> + /* Using random mac addresses for VFs */

[dpdk-dev] [PATCH] net/vhost: Add function to retreive the 'vid' for a given port id.

[Thomas Monjalon]

2016-09-13 14:47, Ciara Loftus:
> In some cases when using the vHost PMD, certain vHost library functions
> may still need to be accessed. One such example is the
> rte_vhost_get_queue_num function which returns the number of virtqueues
> reported by the guest - information which is not exposed by the PMD.
> 
> This commit introduces a new rte_eth_vhost function that returns the
> 'vid' associated with a given port id. This allows the PMD user to call
> vHost library functions which require the 'vid' value.

I think we should not add any API to the PMDs.
Maybe you are looking for a generic API in ethdev.

[dpdk-dev] [PATCH] app/testpmd: fix timeout in Rx queue flushing

[Ferruh Yigit]

On 9/8/2016 10:49 AM, James Poole wrote:
> When testpmd is run, the application would hang on the second time
> that "start" is executed. This is because the timer limit would get
> multiplied to an unreachably high number.
> 
> At the start of flush_fwd_rx_queues(), the timer limit now resets
> to stop it from getting to this high number.
> 
> The timer has been made local for this function.
> 
> Fixes: f487715f36f5 ("app/testpmd: add timeout in Rx queue flushing")
> 
> Signed-off-by: James Poole 

Acked-by: 

[dpdk-dev] [PATCH] scripts: hide double git reference check error

[Thomas Monjalon]

2016-08-29 10:35, Thomas Monjalon:
> When checking a git reference which does not exist, a git error
> with the long git-branch usage is printed:
> 
> % scripts/check-git-log.sh '-1 3780cbd'
> error: malformed object name 2de9f8551ff9
> usage: git branch ...
>   [a lot of lines]
> Wrong 'Fixes' reference:
>   Fixes: 2de9f8551ff9 ("ethdev: fix documentation for queue start/stop")
> 
> The error from the script is sufficient so the git error can be hidden.
> 
> Signed-off-by: Thomas Monjalon 

Applied

[dpdk-dev] [PATCH] scripts: remove useless checkpatch notes

[Thomas Monjalon]

2016-08-29 11:12, Thomas Monjalon:
> Depending of the checkpatch version in use, more or less notes are
> printed below the report.
> Only 6 lines were stripped, resulting to such note being printed:
> NOTE: If any of the errors are false positives, please report
>   them to the maintainer, see CHECKPATCH in MAINTAINERS.
> 
> The stripping is now more reliable because based on a very stable pattern.
> 
> Signed-off-by: Thomas Monjalon 

Applied

[dpdk-dev] [PATCH] scripts: reverse order of checked commits

[Thomas Monjalon]

2016-09-09 15:42, David Marchand:
> On Fri, Sep 9, 2016 at 1:11 PM, Thomas Monjalon
>  wrote:
> > The list of git commits to check was in the reversed order.
> > Also add a comment in the help of checkpatches.sh about list input.
> >
> > Signed-off-by: Thomas Monjalon 
> 
> Thanks Thomas.
> Tested-by: David Marchand 

Applied

[dpdk-dev] [PATCH v5 00/10] Fix build errors related to exported headers

[Thomas Monjalon]

2016-09-08 14:25, Adrien Mazarguil:
> DPDK uses GNU C language extensions in most of its code base. This is fine
> for internal source files whose compilation flags are controlled by DPDK,
> however user applications that use exported "public" headers may experience
> compilation failures when enabling strict error/standard checks (-std and
> -pedantic for instance).
> 
> Exported headers are installed system-wide and must be as clean as possible
> so applications do not have to resort to workarounds.
> 
> This patchset affects exported headers only, compilation problems are
> addressed as follows:
> 
> - Adding the __extension__ keyword to nonstandard constructs (same method
>   as existing libraries when there is no other choice).
> - Adding the __extension__ keyword to C11 constructs to remain compatible
>   with pure C99.
> - Adding missing includes so exported files can be included out of order
>   and on their own.
> - Fixing GNU printf-like variadic macros as there is no magic keyword for
>   these.

Applied, thanks

The script is a bit slow so it is not integrated in test-build.sh yet.
But it should allow us to take care of our exported headers in the future.
Adrien, you'll be welcome to remind us how to keep things standard :)

[dpdk-dev] [PATCH] vhost: change the vhost library to a common framework which can support more VIRTIO devices

[Thomas Monjalon]

2016-09-13 20:58, Yuanhan Liu:
> rte_virtio_net.h is the header file will be exported for applications.
> Every change there would mean either an API or ABI breakage. Thus, we
> should try to avoid touching it. Don't even to say you added yet another
> header file, rte_virtio_dev.h.
> 
> I confess that the rte_virtio_net.h filename isn't that right: it sticks
> to virtio-net so tightly. We may could rename it to rte_vhost.h, but I
> doubt it's worthwhile: as said, it breaks the API.
> 
> The fortunate thing about this file is that, the context is actually not
> sticking to virtio-net too much. I mean, all the APIs are using the "vid",
> which is just a number. Well, except the virtio_net_device_ops() structure,
> which also should be renamed to vhost_device_ops(). Besides that, the
> three ops, "new_device", "destroy_device" and "vring_state_changed", are
> actually not limited to virtio-net device.
> 
> That is to say, we could have two options here:
> 
> - rename the header file and the structure properly, to not limited to
>   virtio-net
> 
> - live with it, let it be a legacy issue, and document it at somewhere,
>   say, "due to history reason, that virtio-net is the first one supported
>   in DPDK, we kept the header filename as rte_virtio_net.h, but not ..."
> 
> I personally would prefer the later one, which saves us from breaking
> applications again. I don't have strong objection to the first one though.
> 
> Thomas, any comments?

I don't think keeping broken names for historical reasons is a good
long term maintenance.
It could be a FIXME comment that we would fix when we have other reasons
to break the API.
However, in this case, it is easy to keep the compatibility, I think,
by including rte_virtio.h in rte_virtio_net.h.
Note: renames can also generally be managed with symlinks.

I also don't really understand why this file name is rte_virtio_net.h and
not rte_vhost_net.h.

[dpdk-dev] [PATCH v3] doc/guides: add info on how to enable QAT

[Deepak Kumar Jain]

From: Eoin Breen 

Signed-off-by: Eoin Breen 
Signed-off-by: Deepak Kumar Jain 
---
Changes in v3:
* Add console code-block
* Modified the command to replace n with y in build/.config

Changes in v2:
* Incorporated comments received on v1.


 doc/guides/cryptodevs/qat.rst | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index 3ee2312..2480ce2 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -83,6 +83,17 @@ Installation
 To use the DPDK QAT PMD an SRIOV-enabled QAT kernel driver is required. The
 VF devices exposed by this driver will be used by QAT PMD.

+To enable QAT in DPDK, follow the instructions mentioned in
+http://dpdk.org/doc/guides/linux_gsg/build_dpdk.html
+
+Quick instructions as follows:
+
+.. code-block:: console
+
+   make config T=x86_64-native-linuxapp-gcc
+   sed -i 's,\(CONFIG_RTE_LIBRTE_PMD_QAT\)=n,\1=y,' build/.config
+   make
+
 If you are running on kernel 4.4 or greater, see instructions for
 `Installation using kernel.org driver`_ below. If you are on a kernel earlier
 than 4.4, see `Installation using 01.org QAT driver`_.
-- 
2.5.5

[dpdk-dev] [RFC][PATCH V2 1/3] examples/vhost: Add vswitch (generic switch) framework

[Tan, Jianfeng]

Hi Pankaj,


On 9/12/2016 6:55 PM, Pankaj Chauhan wrote:
> On 9/9/2016 2:26 PM, Tan, Jianfeng wrote:
>> Hi Pankaj,
>>
>> Thanks for the massive and great work.
>
> Hi Jianfeng,
>
> Thanks for the review.
>>
>> On 9/5/2016 6:54 PM, Pankaj Chauhan wrote:
>>> Introduce support for a generic framework for handling of switching
>>> between
>>> physical and vhost devices. The vswitch framework introduces the
>>> following
>>> concept:
>>>
>>> 1. vswitch_dev: Vswitch device is a logical switch which can have
>>> physical and
>>> virtio devices. The devices are operated/used using standard rte_eth
>>> API for
>>> physical devices and lib_vhost API for vhost devices, PMD API is not 
>>> used
>>> for vhost devices.
>>>
>>> 2. vswitch_port: Any physical or virtio device that is added to
>>> vswitch. The
>>> port can have its own tx/rx functions for doing data transfer, which
>>> are exposed
>>> to the framework using generic function pointers
>>> (vs_port->do_tx/do_rx). This way
>>> the generic code can do tx/rx without understanding the type of device
>>> (Physical or
>>> virtio). Similarly each port has its own functions to select tx/rx
>>> queues. The framework
>>> provides default tx/rx queue selection functions to the port when port
>>> is added
>>> (for both physical and vhost devices). But the framework allows the
>>> switch implementation
>>> to override the queue selection functions (vs_port->get_txq/rxq) if
>>> required.
>>>
>>> 3. vswitch_ops: The ops is set of function pointers which are used to
>>> do operations
>>> like learning, unlearning, add/delete port, lookup_and_forward. The
>>> user of vswitch
>>> framework (vhost/main.[c,h])uses these function pointers to perform
>>> above mentioned
>>> operations, thus it remains agnostic of the underlying implementation.
>>>
>>> Different switching logics can implement their vswitch_device and
>>> vswitch_ops, and
>>> register with the framework. This framework makes vhost-switch
>>> application scalable
>>> in terms of:
>>>
>>> 1. Different switching logics (one of them is vmdq, vhost/vmdq.[c,h]
>>> 2. Number of ports.
>>> 3. Policies of selecting ports for rx and tx.
>>>
>>> Signed-off-by: Pankaj Chauhan 
>>
>> After this patch set, how's mapping relationship between cores and
>> vswitch_dev? Old vhost example does not have the concept of switch, so
>> each core is binded with some VDEVs. Now, we still keep original logic?
>>
>> (a) If yes, provided that phys device could has no direct relationship
>> with vdevs in other switching logics, we may need to bind those physical
>> devices to cores too? In that case, switch_worker() will receiving pkts
>> from all devices (phys or virtual) and dispatch, which looks like:
>>
>> switch_worker() {
>> FOR each port binding to this core {
>>  rx(port, pkts[], count);
>>  vs_lookup_n_fwd( information_needed );
>> }
>> }
>
> Since we support only one switch device running at one time. We bind 
> the ports of the switchdev to the core. But The switch might have it's 
> own logic to bind the port to the core. For example
> VMDQ only supports one Physical port, other switch can support more 
> than one Physical port. In order to take care of that i have added two 
> ops in swithdev_ops:
>
> 1. vs_sched_rx_port:
>
> struct vswitch_port *vs_sched_rx_port(struct vswitch_dev *vs_dev, enum
>   vswitch_port_type ptype, 
> uint16_t core_id)
>
> 2. vs_sched_tx_port:
>
> struct vswitch_port *vs_sched_tx_port(struct vswitch_dev *vs_dev, enum
>   vswitch_port_type ptype, uint16_t
> core_id)
>
> The idea of providing these functions is that vhost/main requests the 
> underlying switch implementation to schedule a port for rx or Tx, the 
> current running core_id is also passed as parameter. So the switch can
> take a decision which port to do rx or tx based on core id, and may be 
> some other custom policy.
>
> For example VMDQ always returns the one single Physical port in 
> response to these functions called from any core. The other switch
> can return the ports bound to the cores.
>
> Similarly there are two port operations (vs_port->get_rxq and 
> vs_port->get_txq), here also we pass core_id as parameter so that
> the underlying switch implementation can schedule the rx or tx queue 
> based on the core_id.
>
> The above mentioned ops are used in drain_eth_rx() and 
> do_drain_mbuf_table() (main.c) currently, and they leave binding of 
> physical port and the queues to the underlying implementation. This
> way we can accommodate VMDQ which uses only one physical port and 
> rxqueues based on VMDQ, OR any other switch which uses multiple 
> physical port and rx/tx queue scheduling based on some other logic.
>
> Please suggest if this way of scheduling ports and tx/rx queues is 
> fine or not?

According to above explanation, in VMDQ switch, we cannot schedule two 
queues (belongs to the same port) on the same core, right?


>>
>> (b) 

[dpdk-dev] [PATCH] net/vhost: Add function to retreive the 'vid' for a given port id.

[Ciara Loftus]

In some cases when using the vHost PMD, certain vHost library functions
may still need to be accessed. One such example is the
rte_vhost_get_queue_num function which returns the number of virtqueues
reported by the guest - information which is not exposed by the PMD.

This commit introduces a new rte_eth_vhost function that returns the
'vid' associated with a given port id. This allows the PMD user to call
vHost library functions which require the 'vid' value.

Signed-off-by: Ciara Loftus 
---
 drivers/net/vhost/rte_eth_vhost.c   | 29 +
 drivers/net/vhost/rte_eth_vhost.h   |  9 +
 drivers/net/vhost/rte_pmd_vhost_version.map |  6 ++
 3 files changed, 44 insertions(+)

diff --git a/drivers/net/vhost/rte_eth_vhost.c 
b/drivers/net/vhost/rte_eth_vhost.c
index 7539cd4..091517d 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -428,6 +428,35 @@ rte_eth_vhost_get_queue_event(uint8_t port_id,
return -1;
 }

+int
+rte_eth_vhost_get_vid_from_port_id(uint8_t port_id)
+{
+   struct internal_list *list;
+   struct rte_eth_dev *eth_dev;
+   struct vhost_queue *vq;
+   int vid = -1;
+
+   if (!rte_eth_dev_is_valid_port(port_id))
+   return -1;
+
+   pthread_mutex_lock(_list_lock);
+
+   TAILQ_FOREACH(list, _list, next) {
+   eth_dev = list->eth_dev;
+   if (eth_dev->data->port_id == port_id) {
+   vq = eth_dev->data->rx_queues[0];
+   if (vq) {
+   vid = vq->vid;
+   }
+   break;
+   }
+   }
+
+   pthread_mutex_unlock(_list_lock);
+
+   return vid;
+}
+
 static void *
 vhost_driver_session(void *param __rte_unused)
 {
diff --git a/drivers/net/vhost/rte_eth_vhost.h 
b/drivers/net/vhost/rte_eth_vhost.h
index ff5d877..7c98b1a 100644
--- a/drivers/net/vhost/rte_eth_vhost.h
+++ b/drivers/net/vhost/rte_eth_vhost.h
@@ -102,6 +102,15 @@ struct rte_eth_vhost_queue_event {
 int rte_eth_vhost_get_queue_event(uint8_t port_id,
struct rte_eth_vhost_queue_event *event);

+/**
+ * Get the 'vid' value associated with the specified port.
+ *
+ * @return
+ *  - On success, the 'vid' associated with 'port_id'.
+ *  - On failure, a negative value.
+ */
+int rte_eth_vhost_get_vid_from_port_id(uint8_t port_id);
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/drivers/net/vhost/rte_pmd_vhost_version.map 
b/drivers/net/vhost/rte_pmd_vhost_version.map
index 65bf3a8..0533a83 100644
--- a/drivers/net/vhost/rte_pmd_vhost_version.map
+++ b/drivers/net/vhost/rte_pmd_vhost_version.map
@@ -8,3 +8,9 @@ DPDK_16.04 {

local: *;
 };
+
+DPDK_16.11 {
+   global:
+
+   rte_eth_vhost_get_vid_from_port_id;
+}
-- 
2.4.3

[dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add internal callback functions

[Jerin Jacob]

On Fri, Sep 09, 2016 at 04:32:07PM +, ZELEZNIAK, ALEX wrote:
> Use case could be to inform application managing SRIOV about VM's intention
> to modify parameters like add VLAN which might not be the one which is 
> assigned to VF or inform about VF reset and reapply settings like strip/insert
> VLAN id based on policy.

Is there any other way(more portable way) where we can realize the same
use case?

Something like,

1) The assigned VM operates/control the VF
2) A centralized entity post messages through UNIX socket or
something(like vhost user communicates with VM).
On message receive, VM can take necessary action on assigned VF.

This will avoid the need of defining specifics of PF to VF mailbox
communication in normative ethdev specification.

And I guess it will work almost the PMD drivers as their is no
PMD specific work here.

Just a thought.

> 
> > -Original Message-
> > From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
> > Sent: Friday, September 09, 2016 10:11 AM
> > To: Bernard Iremonger 
> > Cc: rahul.r.shah at intel.com; wenzhuo.lu at intel.com; dev at dpdk.org;
> > ZELEZNIAK, ALEX 
> > Subject: Re: [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add internal
> > callback functions
> > 
> > On Fri, Aug 26, 2016 at 10:10:16AM +0100, Bernard Iremonger wrote:
> > > add _rte_eth_dev_callback_process_vf function.
> > > add _rte_eth_dev_callback_process_generic function
> > >
> > > Adding a callback to the user application on VF to PF mailbox message,
> > > allows passing information to the application controlling the PF
> > > when a VF mailbox event message is received, such as VF reset.
> > >
> > > Signed-off-by: azelezniak 
> > > Signed-off-by: Bernard Iremonger 
> > > ---
> > >  lib/librte_ether/rte_ethdev.c  | 17 ++
> > >  lib/librte_ether/rte_ethdev.h  | 61
> > ++
> > >  lib/librte_ether/rte_ether_version.map |  7 
> > >  3 files changed, 85 insertions(+)
> > >
> > > diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> > > index f62a9ec..1388ea3 100644
> > > --- a/lib/librte_ether/rte_ethdev.c
> > > +++ b/lib/librte_ether/rte_ethdev.c
> > > @@ -2690,6 +2690,20 @@ void
> > >  _rte_eth_dev_callback_process(struct rte_eth_dev *dev,
> > >   enum rte_eth_event_type event)
> > >  {
> > > + return _rte_eth_dev_callback_process_generic(dev, event, NULL);
> > > +}
> > > +
> > > +void
> > > +_rte_eth_dev_callback_process_vf(struct rte_eth_dev *dev,
> > > + enum rte_eth_event_type event, void *param)
> > > +{
> > > + return _rte_eth_dev_callback_process_generic(dev, event, param);
> > > +}
> > > +
> > > +void
> > > +_rte_eth_dev_callback_process_generic(struct rte_eth_dev *dev,
> > > + enum rte_eth_event_type event, void *param)
> > > +{
> > >   struct rte_eth_dev_callback *cb_lst;
> > >   struct rte_eth_dev_callback dev_cb;
> > >
> > > @@ -2699,6 +2713,9 @@ _rte_eth_dev_callback_process(struct
> > rte_eth_dev *dev,
> > >   continue;
> > >   dev_cb = *cb_lst;
> > >   cb_lst->active = 1;
> > > + if (param != NULL)
> > > + dev_cb.cb_arg = (void *) param;
> > > +
> > >   rte_spinlock_unlock(_eth_dev_cb_lock);
> > >   dev_cb.cb_fn(dev->data->port_id, dev_cb.event,
> > >   dev_cb.cb_arg);
> > > diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> > > index b0fe033..4fb0b9c 100644
> > > --- a/lib/librte_ether/rte_ethdev.h
> > > +++ b/lib/librte_ether/rte_ethdev.h
> > > @@ -3047,9 +3047,27 @@ enum rte_eth_event_type {
> > >   /**< queue state event (enabled/disabled)
> > */
> > >   RTE_ETH_EVENT_INTR_RESET,
> > >   /**< reset interrupt event, sent to VF on PF reset */
> > > + RTE_ETH_EVENT_VF_MBOX,  /**< PF mailbox processing callback */
> > >   RTE_ETH_EVENT_MAX   /**< max value of this enum */
> > >  };
> > >
> > > +/**
> > > + * Response sent back to ixgbe driver from user app after callback
> > > + */
> > > +enum rte_eth_mb_event_rsp {
> > > + RTE_ETH_MB_EVENT_NOOP_ACK,  /**< skip mbox request and ACK
> > */
> > > + RTE_ETH_MB_EVENT_NOOP_NACK, /**< skip mbox request and
> > NACK */
> > > + RTE_ETH_MB_EVENT_PROCEED,  /**< proceed with mbox request
> > */
> > > + RTE_ETH_MB_EVENT_MAX   /**< max value of this enum */
> > > +};
> > 
> > Do we really need to define the specifics of PF to VF MBOX communication
> > in normative ethdev specification?
> > Each drivers may have different PF to VF MBOX definitions so it may not be
> > very portable.
> > What is the use-case here? If its for VF configuration, I think we can
> > do it as separate 'sync' functions for each functionality so that
> > PMDs will have room hiding the specifics on MBOX definitions.
> 

[dpdk-dev] [PATCH] kni: unregister an unregisterd net_device could cause a kernel crash

[Ferruh Yigit]

On 9/11/2016 10:59 AM, zhouyangchao wrote:
> Signed-off-by: zhouyangchao 
> ---

There is a typo in the patch subject, I suggest:
kni: fix error rollback kernel crash

Fixes: 9c61145ff6f9 ("kni: allow multiple threads")

Acked-by: Ferruh Yigit 

[dpdk-dev] [PATCH v2] doc/guides: add info on how to enable QAT

[Thomas Monjalon]

2016-09-13 11:47, Deepak Kumar Jain:
> +#. ``make config T=x86_64-native-linuxapp-gcc``
> +#. Open the ``./build/.config`` file
> +#. Replace ``CONFIG_RTE_LIBRTE_PMD_QAT=n`` with 
> ``CONFIG_RTE_LIBRTE_PMD_QAT=y``

It is better to put commands after "code-block:: console"
Then I suggest this command:
sed -i 's,\(CONFIG_RTE_LIBRTE_PMD_QAT\)=n,\1=y,' build/.config

> +#. ``make``

[dpdk-dev] [PATCH v2] doc/guides: add info on how to enable QAT

[Jain, Deepak K]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, September 13, 2016 12:51 PM
> To: Jain, Deepak K 
> Cc: dev at dpdk.org; De Lara Guarch, Pablo  intel.com>;
> Breen, Eoin 
> Subject: Re: [dpdk-dev] [PATCH v2] doc/guides: add info on how to enable
> QAT
> 
> 2016-09-13 11:47, Deepak Kumar Jain:
> > +#. ``make config T=x86_64-native-linuxapp-gcc`` #. Open the
> > +``./build/.config`` file #. Replace ``CONFIG_RTE_LIBRTE_PMD_QAT=n``
> > +with ``CONFIG_RTE_LIBRTE_PMD_QAT=y``
> 
> It is better to put commands after "code-block:: console"
> Then I suggest this command:
>   sed -i 's,\(CONFIG_RTE_LIBRTE_PMD_QAT\)=n,\1=y,' build/.config

Thanks. I will update and send v3 of the patch.


> > +#. ``make``
> 

[dpdk-dev] [PATCH 1/3] lib/librte_table: enabling cuckoo hash into table library

[Yuanhan Liu]

On Fri, Aug 26, 2016 at 05:01:16PM -0700, Sankar Chokkalingam wrote:
> This patch provides table apis for dosig version of cuckoo hash via
>  rte_table_hash_cuckoo_dosig_ops
> 
> The following apis are implemented for cuckoo hash
>   rte_table_hash_cuckoo_create
>   rte_table_hash_cuckoo_free
>   rte_table_hash_cuckoo_entry_add
>   rte_table_hash_cuckoo_entry_delete
>   rte_table_hash_cuckoo_lookup_dosig
>   rte_table_hash_cuckoo_stats_read
> 
> Signed-off-by: Sankar Chokkalingam 
> Signed-off-by: Guruprasad Rao 

Hi,

FYI, my robot caught a clang build error (gcc builds fine).

--yliu

---
x86_64-native-linuxapp-clang: config-all-yes

lib/librte_table/rte_table_hash_cuckoo.c:304:22: error: cast from 'uint8_t **' 
(aka 'unsigned char **') to 'const void **' must have all intermediate pointers 
const qualified to be safe [-Werror,-Wcast-qual]
(const void **) keys,
^
1 error generated.
make[5]: *** [rte_table_hash_cuckoo.o] Error 1
make[5]: *** Waiting for unfinished jobs
make[4]: *** [librte_table] Error 2
make[3]: *** [lib] Error 2
make[2]: *** [all] Error 2
make[1]: *** [pre_install] Error 2
make: *** [install] Error 2
error: build failed

[dpdk-dev] [RFC PATCH v2 5/5] app/test_pmd: add tests for new API's

[Yuanhan Liu]

On Mon, Sep 12, 2016 at 03:57:19PM +, Iremonger, Bernard wrote:
> > /root/dpdk/x86_64-native-linuxapp-
> > clang/include/cmdline_parse_num.h:107:3: note: expanded from macro
> > 'TOKEN_NUM_INITIALIZER'
> > numtype,/* type */  \
> > ^~~
> > /root/dpdk/app/test-pmd/cmdline.c:11156:8: error: expression which
> > evaluates to zero treated as a null pointer constant of type 'const char *' 
> > [-
> > Werror,-Wnon-literal-null-conversion]
> >  on, UINT8);
> >  ^
> > /root/dpdk/x86_64-native-linuxapp-
> > clang/include/cmdline_parse_num.h:107:3: note: expanded from macro
> > 'TOKEN_NUM_INITIALIZER'
> > numtype,/* type */  \
> > ^~~
> > 7 errors generated.
> > make[5]: *** [cmdline.o] Error 1
> > make[5]: *** Waiting for unfinished jobs
> > make[4]: *** [test-pmd] Error 2
> > make[4]: *** Waiting for unfinished jobs
> > make[3]: *** [app] Error 2
> > make[2]: *** [all] Error 2
> > make[1]: *** [pre_install] Error 2
> > make: *** [install] Error 2
> > error: build failed
> 
> I am not seeing the above errors when I build with the following commands:
> 
> make config T=x86_64-native-linuxapp-clang
> make install T=x86_64-native-linuxapp-clang -j
> 
> Are you using a different clang config file?

Not really (well, I disabled KNI and UIO stuff). FYI, I'm using the
default clang compiler from ubuntu 16.04-x86_64.

--yliu

[dpdk-dev] [PATCH] doc/guides: fix name of algorithm

[Deepak Kumar Jain]

Update documentation with correct names of algorithm supported.

Fixes: 1703e94ac5cee ("qat: add driver for QuickAssist devices")

Signed-off-by: Deepak Kumar Jain 
---
 doc/guides/cryptodevs/qat.rst | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index 325004c..72c116a 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -42,13 +42,13 @@ The QAT PMD has support for:

 Cipher algorithms:

-* ``RTE_CRYPTO_SYM_CIPHER_AES128_CBC``
-* ``RTE_CRYPTO_SYM_CIPHER_AES192_CBC``
-* ``RTE_CRYPTO_SYM_CIPHER_AES256_CBC``
-* ``RTE_CRYPTO_SYM_CIPHER_AES128_CTR``
-* ``RTE_CRYPTO_SYM_CIPHER_AES192_CTR``
-* ``RTE_CRYPTO_SYM_CIPHER_AES256_CTR``
-* ``RTE_CRYPTO_SYM_CIPHER_SNOW3G_UEA2``
+* ``RTE_CRYPTO_CIPHER_AES128_CBC``
+* ``RTE_CRYPTO_CIPHER_AES192_CBC``
+* ``RTE_CRYPTO_CIPHER_AES256_CBC``
+* ``RTE_CRYPTO_CIPHER_AES128_CTR``
+* ``RTE_CRYPTO_CIPHER_AES192_CTR``
+* ``RTE_CRYPTO_CIPHER_AES256_CTR``
+* ``RTE_CRYPTO_CIPHER_SNOW3G_UEA2``
 * ``RTE_CRYPTO_CIPHER_AES_GCM``
 * ``RTE_CRYPTO_CIPHER_NULL``

-- 
2.5.5

[dpdk-dev] [PATCH v2] doc/guides: add info on how to enable QAT

[Deepak Kumar Jain]

From: Eoin Breen 

Signed-off-by: Eoin Breen 
Signed-off-by: Deepak Kumar Jain 
---
Changes in v2:
Incorporated comments received on v1.

 doc/guides/cryptodevs/qat.rst | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index 3ee2312..325004c 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -83,6 +83,16 @@ Installation
 To use the DPDK QAT PMD an SRIOV-enabled QAT kernel driver is required. The
 VF devices exposed by this driver will be used by QAT PMD.

+To enable QAT in DPDK, follow the instructions mentioned in
+http://dpdk.org/doc/guides/linux_gsg/build_dpdk.html
+
+Quick instructions as follows:
+
+#. ``make config T=x86_64-native-linuxapp-gcc``
+#. Open the ``./build/.config`` file
+#. Replace ``CONFIG_RTE_LIBRTE_PMD_QAT=n`` with ``CONFIG_RTE_LIBRTE_PMD_QAT=y``
+#. ``make``
+
 If you are running on kernel 4.4 or greater, see instructions for
 `Installation using kernel.org driver`_ below. If you are on a kernel earlier
 than 4.4, see `Installation using 01.org QAT driver`_.
-- 
2.5.5

[dpdk-dev] [PATCH v4] crypto/qat: add Intel QuickAssist C62x device

[Deepak Kumar Jain]

From: Deepak Kumar JAIN 

Signed-off-by: Deepak Kumar Jain 
Acked-by: Fiona Trahe 
---
Changes in v4:
Fixed the issues in qat.rst file.

Changes in v3:
Added new feature information

Changes in v2:
Removed trialing white spaces

 doc/guides/cryptodevs/qat.rst  | 86 --
 doc/guides/rel_notes/release_16_11.rst |  4 ++
 drivers/crypto/qat/rte_qat_cryptodev.c |  3 ++
 3 files changed, 88 insertions(+), 5 deletions(-)

diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index bb62f22..3ee2312 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -27,11 +27,12 @@
 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

-Quick Assist Crypto Poll Mode Driver
-
+Intel(R) QuickAssist (QAT) Crypto Poll Mode Driver
+==

 The QAT PMD provides poll mode crypto driver support for **Intel QuickAssist
-Technology DH895xxC** hardware accelerator.
+Technology DH895xxC** and **Intel QuickAssist Technology C62x**
+hardware accelerator.


 Features
@@ -86,10 +87,15 @@ If you are running on kernel 4.4 or greater, see 
instructions for
 `Installation using kernel.org driver`_ below. If you are on a kernel earlier
 than 4.4, see `Installation using 01.org QAT driver`_.

+For **Intel QuickAssist Technology C62x** device, kernel 4.5 or greater is
+needed. See instructions for `Installation using kernel.org driver`_ below.
+

 Installation using 01.org QAT driver
 

+NOTE: There is no driver available for **Intel QuickAssist Technology C62x** 
on 01.org.
+
 Download the latest QuickAssist Technology Driver from `01.org
 
`_
 Consult the *Getting Started Guide* at the same URL for further information.
@@ -166,6 +172,7 @@ If the build or install fails due to mismatching kernel 
sources you may need to
 Installation using kernel.org driver
 

+For **Intel QuickAssist Technology DH895xxC**:
 Assuming you are running on at least a 4.4 kernel, you can use the stock 
kernel.org QAT
 driver to start the QAT hardware.

@@ -185,9 +192,9 @@ You should see the following output::
 qat_dh895xcc5626  0
 intel_qat  82336  1 qat_dh895xcc

-Next, you need to expose the VFs using the sysfs file system.
+Next, you need to expose the Virtual Functions (VFs) using the sysfs file 
system.

-First find the bdf of the DH895xCC device::
+First find the bdf of the physical function (PF) of the DH895xCC device::

 lspci -d : 435

@@ -225,10 +232,54 @@ cd to your linux source root directory and start the qat 
kernel modules:
 ``IOMMU should be enabled for SR-IOV to work correctly``


+For **Intel QuickAssist Technology C62x**:
+Assuming you are running on at least a 4.5 kernel, you can use the stock 
kernel.org QAT
+driver to start the QAT hardware.
+
+The steps below assume you are:
+
+* Running DPDK on a platform with one ``C62x`` device.
+* On a kernel at least version 4.5.
+
+In BIOS ensure that SRIOV is enabled and VT-d is disabled.
+
+Ensure the QAT driver is loaded on your system, by executing::
+
+lsmod | grep qat
+
+You should see the following output::
+
+qat_c62x   16384  0
+intel_qat 122880  1 qat_c62x
+
+Next, you need to expose the VFs using the sysfs file system.
+
+First find the bdf of the C62x device::
+
+lspci -d:37c8
+
+You should see output similar to::
+
+1a:00.0 Co-processor: Intel Corporation Device 37c8
+3d:00.0 Co-processor: Intel Corporation Device 37c8
+3f:00.0 Co-processor: Intel Corporation Device 37c8
+
+For each c62x device there are 3 PFs.
+Using the sysfs, for each PF, enable the 16 VFs::
+
+echo 16 > /sys/bus/pci/drivers/c6xx/\:1a\:00.0/sriov_numvfs
+
+If you get an error, it's likely you're using a QAT kernel driver earlier than 
kernel 4.5.
+
+To verify that the VFs are available for use - use ``lspci -d:37c9`` to confirm
+the bdf of the 48 VF devices are available per ``C62x`` device.
+
+To complete the installation - follow instructions in `Binding the available 
VFs to the DPDK UIO driver`_.

 Binding the available VFs to the DPDK UIO driver
 

+For **Intel(R) QuickAssist Technology DH895xcc** device:
 The unbind command below assumes ``bdfs`` of ``03:01.00-03:04.07``, if yours 
are different adjust the unbind command below::

cd $RTE_SDK
@@ -245,3 +296,28 @@ The unbind command below assumes ``bdfs`` of 
``03:01.00-03:04.07``, if yours are
echo "8086 0443" > /sys/bus/pci/drivers/igb_uio/new_id

 You can use ``lspci -vvd:443`` to confirm that all devices are now in use by 
igb_uio kernel driver.
+
+For **Intel(R) QuickAssist 

[dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF management

[Thomas Monjalon]

2016-09-12 16:28, Iremonger, Bernard:
> > On Fri, Aug 26, 2016 at 10:10:18AM +0100, Bernard Iremonger wrote:
> > > Add new API functions to configure and manage VF's on a NIC.
> > >
> > > add rte_eth_dev_vf_ping function.
> > > add rte_eth_dev_set_vf_vlan_anti_spoof function.
> > > add rte_eth_dev_set_vf_mac_anti_spoof function.
> > >
> > > Signed-off-by: azelezniak 
> > >
> > > add rte_eth_dev_set_vf_vlan_strip function.
> > > add rte_eth_dev_set_vf_vlan_insert function.
> > > add rte_eth_dev_set_loopback function.
> > > add rte_eth_dev_set_all_queues_drop function.
> > > add rte_eth_dev_set_vf_split_drop_en function add
> > > rte_eth_dev_set_vf_mac_addr function.
> > 
> > Do we really need to expose VF specific functions here?
> > It can be generic(PF/VF) function indexed only through port_id.
> > (example: as rte_eth_dev_set_vlan_anti_spoof(uint8_t port_id, uint8_t on))
> > For instance, In Thunderx PMD, We are not exposing a separate port_id for
> > PF. We only enumerate 0..N VFs as 0..N ethdev port_id
> 
> Our intention with this patch is to control the VF from the PF.
> 
> The following librte_ether functions already work in a similar way:
> 
> rte_eth_dev_set_vf_rxmode(uint8_t port_id,  uint16_t vf, uint16_t rx_mode, 
> uint8_t on)
> 
> rte_eth_dev_set_vf_rx(uint8_t port_id, uint16_t vf, uint8_t on)
> 
> rte_eth_dev_set_vf_tx(uint8_t port_id, uint16_t vf, uint8_t on)
> 
> int rte_eth_set_vf_rate_limit(uint8_t port_id, uint16_t vf, uint16_t tx_rate, 
> uint64_t q_msk)

I have a bad feeling with these functions dedicated to VF from PF.
Are we sure there is no other way?
I mean we just need to know the VF with a port ID.

[dpdk-dev] [PATCH v2 2/2] kni: add support for core_id param in single threaded mode

[Vladyslav Buslov]

Hi Ferruh,

Thanks for reviewing my code.

Regarding creating kthread within locked mutex section: It is executed in 
context of ioctl_unlocked so I assume we may have race condition otherwise if 
multiple threads in same task try to create KNI interface simultaneously.
My kernel programming knowledge is limited so correct me if I'm wrong.

Regards,
Vlad

-Original Message-
From: Ferruh Yigit [mailto:ferruh.yi...@intel.com] 
Sent: Monday, September 12, 2016 8:08 PM
To: Vladyslav Buslov; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2 2/2] kni: add support for core_id param in 
single threaded mode

On 9/10/2016 2:50 PM, Vladyslav Buslov wrote:
> Allow binding KNI thread to specific core in single threaded mode by 
> setting core_id and force_bind config parameters.
> 
> Signed-off-by: Vladyslav Buslov 
> ---
> 
> v2:
> * Fixed formatting.
> * Refactored kthread create/bind functionality into separate function.
> * Moved thread mode print into kni_init.
> * Added short description to KNI Programmer's Gude doc.
> * Fixed outdated mbuf processing description in KNI Programmer's Gude doc.
> 
>  doc/guides/prog_guide/kernel_nic_interface.rst |  5 +-
>  lib/librte_eal/linuxapp/kni/kni_misc.c | 72 
> +-
>  2 files changed, 51 insertions(+), 26 deletions(-)
> 
> diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst 
> b/doc/guides/prog_guide/kernel_nic_interface.rst
> index fac1960..0fdc307 100644
> --- a/doc/guides/prog_guide/kernel_nic_interface.rst
> +++ b/doc/guides/prog_guide/kernel_nic_interface.rst
> @@ -102,6 +102,9 @@ Refer to rte_kni_common.h in the DPDK source code for 
> more details.
>  
>  The physical addresses will be re-mapped into the kernel address space and 
> stored in separate KNI contexts.
>  
> +The affinity of kernel RX thread (both single and multi-threaded 
> +modes) is controlled by force_bind and core_id config parameters.
> +
>  The KNI interfaces can be deleted by a DPDK application dynamically after 
> being created.
>  Furthermore, all those KNI interfaces not deleted will be deleted on 
> the release operation  of the miscellaneous device (when the DPDK application 
> is closed).
> @@ -128,7 +131,7 @@ Use Case: Ingress
>  On the DPDK RX side, the mbuf is allocated by the PMD in the RX thread 
> context.
>  This thread will enqueue the mbuf in the rx_q FIFO.
>  The KNI thread will poll all KNI active devices for the rx_q.
> -If an mbuf is dequeued, it will be converted to a sk_buff and sent to the 
> net stack via netif_rx().
> +If an mbuf is dequeued, it will be converted to a sk_buff and sent to the 
> net stack via netif_rx_ni().

Although this is small and correct modification, unrelated to this patch. It is 
good to remove from this patch, and feel free to create a separate patch if you 
want.

>  The dequeued mbuf must be freed, so the same pointer is sent back in the 
> free_q FIFO.
>  
>  The RX thread, in the same main loop, polls this FIFO and frees the mbuf 
> after dequeuing it.
> diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c 
> b/lib/librte_eal/linuxapp/kni/kni_misc.c
> index 5e7cf21..c79f5a8 100644
> --- a/lib/librte_eal/linuxapp/kni/kni_misc.c
> +++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
> @@ -172,6 +172,11 @@ kni_init(void)
>   return -EINVAL;
>   }
>  
> + if (multiple_kthread_on == 0)
> + KNI_PRINT("Single kernel thread for all KNI devices\n");
> + else
> + KNI_PRINT("Multiple kernel thread mode enabled\n");
> +

Instead of fixing these in a second patch, why not do the correct one in first 
patch? Or I think it is better to have a single patch instead of two. What 
about squashing second patch into first?

>  #ifdef HAVE_SIMPLIFIED_PERNET_OPERATIONS
>   rc = register_pernet_subsys(_net_ops);
>  #else
> @@ -240,12 +245,6 @@ kni_open(struct inode *inode, struct file *file)
>   if (test_and_set_bit(KNI_DEV_IN_USE_BIT_NUM, >device_in_use))
>   return -EBUSY;
>  
> - /* Create kernel thread for single mode */
> - if (multiple_kthread_on == 0)
> - KNI_PRINT("Single kernel thread for all KNI devices\n");
> - else
> - KNI_PRINT("Multiple kernel thread mode enabled\n");
> -
>   file->private_data = get_net(net);
>   KNI_PRINT("/dev/kni opened\n");
>  
> @@ -391,6 +390,32 @@ kni_check_param(struct kni_dev *kni, struct 
> rte_kni_device_info *dev)
>   return 0;
>  }
>  
> +__printf(5, 6) static struct task_struct * kni_run_thread(int 
> +(*threadfn)(void *data),
> + void *data,
> + uint8_t force_bind,
> + unsigned core_id,
> + const char namefmt[], ...)

Syntax should be updated.

> +{
> + struct task_struct *kni_thread = NULL;
> + char task_comm[TASK_COMM_LEN];
> + va_list args;
> +
> + va_start(args, namefmt);
> + vsnprintf(task_comm, sizeof(task_comm), namefmt, args);
> + va_end(args);

What about just using a "char *" and make things simpler, instead of 

[dpdk-dev] [PATCH 1/2] examples/tep_term: fix offload on VXLAN failure

[Yuanhan Liu]

On Mon, Sep 12, 2016 at 11:36:01AM +0200, Thomas Monjalon wrote:
> 2016-09-12 08:42, Tan, Jianfeng:
> > From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
> > > FYI, my testrobot caught some errors when this patch is applied.
> > 
> > It's because this patch set has dependency on a previous patch set, which 
> > seems a difficult scenario to handle. There's no standard to state the 
> > dependency, right?
> 
> No there is no standard to state the dependency.

Yes.

> We need one.

We could.

> Actually, there are 3 kinds of dependencies:
>   - a well know dependency when sending a patch

Not quite sure what it is.

>   - implicit dependency on the HEAD

If the HEAD is in one of the DPDK public three (no matter which it is),
no issue. My robot will try to apply a patchset to all available trees,
one by one, until it succeeds.

If the HEAD is a local commit (say, like this case, you made a patch
based on some patches from community that haven't been applied yet),
it's hard. The only way we can do is that we can do some brute force
to get the right combination if no hint given. But I think of no reason
to do that: it just brings complexity. So, we could either ask a hint
from the author (the tag you mentioned below, or provide a git tree
(the alternative I'd suggest, details go below).

>   (can fail if a conflicting patch is pushed)

It also can be fixed quite easily: when failed, it could go few commits
backwards, until a right base is found.

>   - dependency on a specific tree (next-*)

Not an issue, as stated above.

> 
> I suggest using:
>   Depends-on: pw | 
> Examples:
>   Depends-on: pw 33000

This one is necessary, both for an auto tools and for some people to have
a try.

>   Depends-on: master 3643b0f
>   Depends-on: next-net f33e00

I see no good reason to do that, for that's typically where patches apply.
And since we have introduced sub-trees, it then should be obvious (for
frequent contributors) that if you are making a patch to a PMD driver,
you should grab the next-net tree and make patch there. Vice verse, if
you got a PMD patch from mailing list and want to have a try, you should
try to apply it to the next-net tree. Well, it may fail because the patch
author doesn't know this generic rule, that he made patches based on master,
you then could have a try with master.

Besides, it just adds extra burden to developers: think that we have to
add such tag to every patch.

> 
> It won't work well when a patch depends on a pending patch series
> because the cover letter has no patchwork identifier.
> It will be solved with the next version of patchwork (in few months).
> In the meantime, we can point to the first patch of the series.
> 
> Comments/ideas?

The alternative I'd suggest is to use git trees. I'm going to add the
support of git-tree-based test (hopefully, I could do that this weekend).

I'd suggest all frequent contributors to have its own DPDK tree (publicly,
say at github, or internally, only works for intel). Every one has a local
git, what you need to do is to push your local git to a remote tree. You
then tell me the tree URL, my robot will fetch your tree timely. Once you
have pushed something, it will start the build test. You could even get a
report when it finishes, if you wish.

In such case, there is no dependency at all: because the developer already
fixed that if any.

As stated, it's an alternative. People could choose the one they prefer.

--yliu

[dpdk-dev] [PATCH v3] crypto/qat: add Intel QuickAssist C62x device

[Deepak Kumar Jain]

From: Deepak Kumar JAIN 

Signed-off-by: Deepak Kumar Jain 
Acked-by: Fiona Trahe 
---
Changes in v3:
Added new feature information

Changes in v2:
Removed trialing white spaces

 doc/guides/cryptodevs/qat.rst  | 82 --
 doc/guides/rel_notes/release_16_11.rst |  4 ++
 drivers/crypto/qat/rte_qat_cryptodev.c |  3 ++
 3 files changed, 85 insertions(+), 4 deletions(-)

diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index bb62f22..f6091dd 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -27,11 +27,12 @@
 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

-Quick Assist Crypto Poll Mode Driver
+Intel(R) QuickAssist (QAT) Crypto Poll Mode Driver
 

 The QAT PMD provides poll mode crypto driver support for **Intel QuickAssist
-Technology DH895xxC** hardware accelerator.
+Technology DH895xxC** and **Intel QuickAssist Technology C62x**
+hardware accelerator.


 Features
@@ -86,9 +87,13 @@ If you are running on kernel 4.4 or greater, see 
instructions for
 `Installation using kernel.org driver`_ below. If you are on a kernel earlier
 than 4.4, see `Installation using 01.org QAT driver`_.

+For **Intel QuickAssist Technology C62x** device, kernel 4.5 or greater is
+needed. See instructions for `instructions using kernel.org driver`_ below.
+

 Installation using 01.org QAT driver
 
+NOTE: There is no driver available for **Intel QuickAssist Technology C62x** 
on 01.org.

 Download the latest QuickAssist Technology Driver from `01.org
 
`_
@@ -166,6 +171,7 @@ If the build or install fails due to mismatching kernel 
sources you may need to
 Installation using kernel.org driver
 

+For **Intel QuickAssist Technology DH895xxC**:
 Assuming you are running on at least a 4.4 kernel, you can use the stock 
kernel.org QAT
 driver to start the QAT hardware.

@@ -185,9 +191,9 @@ You should see the following output::
 qat_dh895xcc5626  0
 intel_qat  82336  1 qat_dh895xcc

-Next, you need to expose the VFs using the sysfs file system.
+Next, you need to expose the Virtual Functions (VFs) using the sysfs file 
system.

-First find the bdf of the DH895xCC device::
+First find the bdf of the physical function (PF) of the DH895xCC device::

 lspci -d : 435

@@ -225,10 +231,53 @@ cd to your linux source root directory and start the qat 
kernel modules:
 ``IOMMU should be enabled for SR-IOV to work correctly``


+For **Intel QuickAssist Technology C62x**:
+Assuming you are running on at least a 4.5 kernel, you can use the stock 
kernel.org QAT
+driver to start the QAT hardware.
+
+The steps below assume you are:
+
+* Running DPDK on a platform with one ``C62x`` device.
+* On a kernel at least version 4.5.
+
+In BIOS ensure that SRIOV is enabled and VT-d is disabled.
+
+Ensure the QAT driver is loaded on your system, by executing::
+
+lsmod | grep qat
+
+You should see the following output::
+
+qat_c62x   16384  0
+intel_qat 122880  1 qat_c62x
+
+Next, you need to expose the VFs using the sysfs file system.
+
+First find the bdf of the C62x device::
+
+lspci -d:37c8
+
+You should see output similar to::
+
+1a:00.0 Co-processor: Intel Corporation Device 37c8
+3d:00.0 Co-processor: Intel Corporation Device 37c8
+3f:00.0 Co-processor: Intel Corporation Device 37c8
+
+For each c62x device there are 3 PFs.
+Using the sysfs, for each PF, enable the 16 VFs::
+
+echo 16 > /sys/bus/pci/drivers/c6xx/\:1a\:00.0/sriov_numvfs
+
+If you get an error, it's likely you're using a QAT kernel driver earlier than 
kernel 4.5.

+To verify that the VFs are available for use - use ``lspci -d:37c9`` to confirm
+the bdf of the 48 VF devices are available per ``C62x`` device.
+
+To complete the installation - follow instructions in `Binding the available 
VFs to the DPDK UIO driver`_.
 Binding the available VFs to the DPDK UIO driver
 

+For **Intel(R) QuickAssist Technology DH895xcc** device:
 The unbind command below assumes ``bdfs`` of ``03:01.00-03:04.07``, if yours 
are different adjust the unbind command below::

cd $RTE_SDK
@@ -245,3 +294,28 @@ The unbind command below assumes ``bdfs`` of 
``03:01.00-03:04.07``, if yours are
echo "8086 0443" > /sys/bus/pci/drivers/igb_uio/new_id

 You can use ``lspci -vvd:443`` to confirm that all devices are now in use by 
igb_uio kernel driver.
+
+For **Intel(R) QuickAssist Technology C62x** device:
+The unbind command below assumes ``bdfs`` of ``1a:01.00-1a:02.07``, 
``3d:01.00-3d:02.07`` and ``3f:01.00-3f:02.07``,
+if yours are different adjust the 

[dpdk-dev] [PATCH v3 2/2] app/test: add test cases for NULL for Intel QAT driver

[Deepak Kumar Jain]

From: Deepak Kumar JAIN 

Added NULL algorithm to test file for Intel(R) QuickAssist
Technology Driver

Signed-off-by: Deepak Kumar Jain 
---
 app/test/test_cryptodev.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 8553759..67ca912 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -4136,6 +4136,16 @@ static struct unit_test_suite cryptodev_qat_testsuite  = 
{
TEST_CASE_ST(ut_setup, ut_teardown,
test_MD5_HMAC_verify_case_2),

+   /** NULL tests */
+   TEST_CASE_ST(ut_setup, ut_teardown,
+   test_null_auth_only_operation),
+   TEST_CASE_ST(ut_setup, ut_teardown,
+   test_null_cipher_only_operation),
+   TEST_CASE_ST(ut_setup, ut_teardown,
+   test_null_cipher_auth_operation),
+   TEST_CASE_ST(ut_setup, ut_teardown,
+   test_null_auth_cipher_operation),
+
TEST_CASES_END() /**< NULL terminate unit test array */
}
 };
-- 
2.5.5

[dpdk-dev] [PATCH v3 1/2] crypto/qat: add NULL capability to Intel QAT driver

[Deepak Kumar Jain]

From: Deepak Kumar JAIN 

enabled NULL crypto for Intel(R) QuickAssist Technology

Signed-off-by: Deepak Kumar Jain 
---
 doc/guides/cryptodevs/qat.rst|  3 +-
 doc/guides/rel_notes/release_16_11.rst   |  1 +
 drivers/crypto/qat/qat_adf/qat_algs_build_desc.c |  2 ++
 drivers/crypto/qat/qat_crypto.c  | 45 
 4 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index 78a734f..bb62f22 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -49,6 +49,7 @@ Cipher algorithms:
 * ``RTE_CRYPTO_SYM_CIPHER_AES256_CTR``
 * ``RTE_CRYPTO_SYM_CIPHER_SNOW3G_UEA2``
 * ``RTE_CRYPTO_CIPHER_AES_GCM``
+* ``RTE_CRYPTO_CIPHER_NULL``

 Hash algorithms:

@@ -60,7 +61,7 @@ Hash algorithms:
 * ``RTE_CRYPTO_AUTH_AES_XCBC_MAC``
 * ``RTE_CRYPTO_AUTH_SNOW3G_UIA2``
 * ``RTE_CRYPTO_AUTH_MD5_HMAC``
-
+* ``RTE_CRYPTO_AUTH_NULL``

 Limitations
 ---
diff --git a/doc/guides/rel_notes/release_16_11.rst 
b/doc/guides/rel_notes/release_16_11.rst
index 9b2f102..9b2c775 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -42,6 +42,7 @@ New Features
   * Added support for MD5_HMAC algorithm.
   * Added support for SHA224-HMAC algorithm.
   * Added support for SHA384-HMAC algorithm.
+  * Added support for NULL algorithm.


 Resolved Issues
diff --git a/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c 
b/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
index af8c176..d9437bc 100644
--- a/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
+++ b/drivers/crypto/qat/qat_adf/qat_algs_build_desc.c
@@ -720,6 +720,8 @@ int qat_alg_aead_session_create_content_desc_auth(struct 
qat_session *cdesc,
}
state2_size = ICP_QAT_HW_MD5_STATE2_SZ;
break;
+   case ICP_QAT_HW_AUTH_ALGO_NULL:
+   break;
default:
PMD_DRV_LOG(ERR, "Invalid HASH alg %u", cdesc->qat_hash_alg);
return -EFAULT;
diff --git a/drivers/crypto/qat/qat_crypto.c b/drivers/crypto/qat/qat_crypto.c
index 60e2ba2..bc8d5b1 100644
--- a/drivers/crypto/qat/qat_crypto.c
+++ b/drivers/crypto/qat/qat_crypto.c
@@ -346,6 +346,47 @@ static const struct rte_cryptodev_capabilities 
qat_pmd_capabilities[] = {
}, }
}, }
},
+   {   /* NULL (AUTH) */
+   .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
+   {.sym = {
+   .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
+   {.auth = {
+   .algo = RTE_CRYPTO_AUTH_NULL,
+   .block_size = 1,
+   .key_size = {
+   .min = 0,
+   .max = 0,
+   .increment = 0
+   },
+   .digest_size = {
+   .min = 0,
+   .max = 0,
+   .increment = 0
+   },
+   .aad_size = { 0 }
+   }, },
+   }, },
+   },
+   {   /* NULL (CIPHER) */
+   .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
+   {.sym = {
+   .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,
+   {.cipher = {
+   .algo = RTE_CRYPTO_CIPHER_NULL,
+   .block_size = 1,
+   .key_size = {
+   .min = 0,
+   .max = 0,
+   .increment = 8
+   },
+   .iv_size = {
+   .min = 0,
+   .max = 0,
+   .increment = 0
+   }
+   }, },
+   }, }
+   },
RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
 };

@@ -469,6 +510,8 @@ qat_crypto_sym_configure_session_cipher(struct 
rte_cryptodev *dev,
session->qat_mode = ICP_QAT_HW_CIPHER_ECB_MODE;
break;
case RTE_CRYPTO_CIPHER_NULL:
+   session->qat_mode = ICP_QAT_HW_CIPHER_ECB_MODE;
+   break;
case RTE_CRYPTO_CIPHER_3DES_ECB:
case RTE_CRYPTO_CIPHER_3DES_CBC:
case RTE_CRYPTO_CIPHER_AES_ECB:
@@ -600,6 +643,8 @@ qat_crypto_sym_configure_session_auth(struct rte_cryptodev 
*dev,
session->qat_hash_alg = ICP_QAT_HW_AUTH_ALGO_MD5;
break;
case RTE_CRYPTO_AUTH_NULL:
+   session->qat_hash_alg = ICP_QAT_HW_AUTH_ALGO_NULL;
+   break;

[dpdk-dev] [PATCH v3 0/2] add NULL crypto support in Intel QAT driver

[Deepak Kumar Jain]

This patchset adds support of NULL crypto in Intel(R) QuickAssist Technology 
driver.

This patchset depends on following patchset:
"crypto/qat: add aes-sha384-hmac capability to Intel QAT driver"
(http://dpdk.org/dev/patchwork/patch/15778/)


Deepak Kumar JAIN (2):
  crypto/qat: add NULL capability to Intel QAT driver
  app/test: add test cases for NULL for Intel QAT driver

Changes in v3:
* Added information in capability structure.

Changes in v2:
* Added new feature information in release_16_11.rst file.


 app/test/test_cryptodev.c| 10 ++
 doc/guides/cryptodevs/qat.rst|  3 +-
 doc/guides/rel_notes/release_16_11.rst   |  1 +
 drivers/crypto/qat/qat_adf/qat_algs_build_desc.c |  2 ++
 drivers/crypto/qat/qat_crypto.c  | 45 
 5 files changed, 60 insertions(+), 1 deletion(-)

-- 
2.5.5

[dpdk-dev] [PATCH] doc: add limitations for i40e PMD

[Xing, Beilei]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jingjing Wu
> Sent: Tuesday, September 6, 2016 10:17 AM
> To: Mcnamara, John 
> Cc: dev at dpdk.org; Wu, Jingjing ; Zhang, Helin
> 
> Subject: [dpdk-dev] [PATCH] doc: add limitations for i40e PMD
> 
> This patch adds "Limitations or Known issues" section for i40e PMD, including
> two items:
> 1. MPLS packet classification on X710/XL710 2. 16 Byte Descriptor cannot be
> used on DPDK VF
> 
> Signed-off-by: Jingjing Wu 
> ---
>  doc/guides/nics/i40e.rst | 33 +
>  1 file changed, 33 insertions(+)
> 
> diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst index
> 4d12b10..6df0f7a 100644
> --- a/doc/guides/nics/i40e.rst
> +++ b/doc/guides/nics/i40e.rst
> @@ -411,3 +411,36 @@ configuration passed on the EAL command line.
> 
>  The floating VEB functionality requires a NIC firmware version of 5.0  or
> greater.
> +
> +
> +Limitations or Known issues
> +---
> +
> +MPLS packet classification on X710/XL710
> +
> +
> +Before NIC firmware version of 5.0, MPLS packet cannot be recognized by
> NIC.
> +The L2 Payload flow type in flow director can be used to classify MPLS
> +packet by the command in testpmd like:
> +
> +   testpmd> flow_director_filter 0 mode IP add flow l2_payload ether \
> +0x8847 flexbytes () fwd pf queue  fd_id 
> +
> +In the NIC firmware whose version is 5.0 or greater, very limited MPLS
> +support is added: Native MPLS skip is implemented, that is, packet type
> +can be recognized like MPLS header is skipped, while no new packet type
> +and no more meta data is extracted from MPLS header. With this change,
> +L2 Payload flow type in flow director cannot be used to classify MPLS packet
> as previous.
> +Meanwhile, Ethertype filter can be used to classify MPLS packet by the
> +command in testpmd like:
> +
> +   testpmd> ethertype_filter 0 add mac_ignr 00:00:00:00:00:00 ethertype \
> +0x8847 fwd queue 
> +
> +16 Byte Descriptor cannot be used on DPDK VF
> +
> +
> +If Linux i40e kerel driver is used as host driver, while DPDK i40e PMD

one typo:  kerel -> kernel

> +is used as VF driver, DPDK cannot choose 16 byte descriptor receive
> +descriptor. That is to say, user should keep
> +"CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n" in config file.
> --
> 2.4.11

[dpdk-dev] [RFC PATCH v2 5/5] app/test_pmd: add tests for new API's

[Iremonger, Bernard]

Hi Yuanhan,

 Subject: Re: [dpdk-dev] [RFC PATCH v2 5/5] app/test_pmd: add tests for
> new API's
> 
> On Mon, Sep 12, 2016 at 03:57:19PM +, Iremonger, Bernard wrote:
> > > /root/dpdk/x86_64-native-linuxapp-
> > > clang/include/cmdline_parse_num.h:107:3: note: expanded from macro
> > > 'TOKEN_NUM_INITIALIZER'
> > > numtype,/* type */  \
> > > ^~~
> > > /root/dpdk/app/test-pmd/cmdline.c:11156:8: error: expression which
> > > evaluates to zero treated as a null pointer constant of type 'const
> > > char *' [- Werror,-Wnon-literal-null-conversion]
> > >  on, UINT8);
> > >  ^
> > > /root/dpdk/x86_64-native-linuxapp-
> > > clang/include/cmdline_parse_num.h:107:3: note: expanded from macro
> > > 'TOKEN_NUM_INITIALIZER'
> > > numtype,/* type */  \
> > > ^~~
> > > 7 errors generated.
> > > make[5]: *** [cmdline.o] Error 1
> > > make[5]: *** Waiting for unfinished jobs
> > > make[4]: *** [test-pmd] Error 2
> > > make[4]: *** Waiting for unfinished jobs
> > > make[3]: *** [app] Error 2
> > > make[2]: *** [all] Error 2
> > > make[1]: *** [pre_install] Error 2
> > > make: *** [install] Error 2
> > > error: build failed
> >
> > I am not seeing the above errors when I build with the following
> commands:
> >
> > make config T=x86_64-native-linuxapp-clang make install
> > T=x86_64-native-linuxapp-clang -j
> >
> > Are you using a different clang config file?
> 
> Not really (well, I disabled KNI and UIO stuff). FYI, I'm using the default 
> clang
> compiler from ubuntu 16.04-x86_64.
> 
>   --yliu

The clang I am using is version 3.4-1, what is your clang version?

Regards,

Bernard.

[dpdk-dev] [PATCH 1/2] examples/tep_term: fix offload on VXLAN failure

[Tan, Jianfeng]

Hi Thomas,

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Monday, September 12, 2016 5:36 PM
> To: Tan, Jianfeng; Yuanhan Liu
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/2] examples/tep_term: fix offload on
> VXLAN failure
> 
> 2016-09-12 08:42, Tan, Jianfeng:
> > From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
> > > FYI, my testrobot caught some errors when this patch is applied.
> >
> > It's because this patch set has dependency on a previous patch set, which
> seems a difficult scenario to handle. There's no standard to state the
> dependency, right?
> 
> No there is no standard to state the dependency.
> We need one. Actually, there are 3 kinds of dependencies:
>   - a well know dependency when sending a patch
>   - implicit dependency on the HEAD
>   (can fail if a conflicting patch is pushed)
>   - dependency on a specific tree (next-*)
> 
> I suggest using:
>   Depends-on: pw | 
> Examples:
>   Depends-on: pw 33000
>   Depends-on: master 3643b0f
>   Depends-on: next-net f33e00
> 
> It won't work well when a patch depends on a pending patch series
> because the cover letter has no patchwork identifier.
> It will be solved with the next version of patchwork (in few months).
> In the meantime, we can point to the first patch of the series.
> 
> Comments/ideas?

I think it's a great idea which can make the work of auto tools much more 
easier and less false positive errors. Besides, it will improve the experience 
of code review.

Thanks,
Jianfeng