* Re: [PATCH v4 1/6] ethdev: add Tx preparation
From: Kulasek, TomaszX @ 2016-10-13 10:47 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev@dpdk.org, Ananyev, Konstantin
In-Reply-To: <1506813.gKiMgNqmq7@xps13>
Hi Thomas,
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Thursday, October 13, 2016 09:09
> To: Kulasek, TomaszX <tomaszx.kulasek@intel.com>
> Cc: dev@dpdk.org; Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v4 1/6] ethdev: add Tx preparation
>
> Hi Tomasz,
>
> Any news?
> Sorry to speed up, we are very very late for RC1.
>
> 2016-10-10 16:08, Thomas Monjalon:
> > Hi,
> >
> > Now that the feature seems to meet a consensus, I've looked at it more
> > closely before integrating. Sorry if it appears like a late review.
> >
> > 2016-09-30 11:00, Tomasz Kulasek:
> > > Added API for `rte_eth_tx_prep`
> >
> > I would love to read the usability and performance considerations here.
> > No need for something as long as the cover letter. Just few lines
> > about why it is needed and why it is a good choice for performance.
> >
> > > uint16_t rte_eth_tx_prep(uint8_t port_id, uint16_t queue_id,
> > > struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
> > >
> > > Added fields to the `struct rte_eth_desc_lim`:
> > >
> > > uint16_t nb_seg_max;
> > > /**< Max number of segments per whole packet. */
> > >
> > > uint16_t nb_mtu_seg_max;
> > > /**< Max number of segments per one MTU */
> > [...]
> > > +#else
> > > +
> > > +static inline uint16_t
> > > +rte_eth_tx_prep(uint8_t port_id __rte_unused, uint16_t queue_id
> __rte_unused,
> > > + struct rte_mbuf **tx_pkts __rte_unused, uint16_t nb_pkts)
> >
> > Doxygen is failing here.
> > Have you tried to move __rte_unused before the identifier?
> >
> > [...]
> > > +#define PKT_TX_OFFLOAD_MASK ( \
> > > + PKT_TX_IP_CKSUM | \
> > > + PKT_TX_L4_MASK | \
> > > + PKT_TX_OUTER_IP_CKSUM | \
> > > + PKT_TX_TCP_SEG | \
> > > + PKT_TX_QINQ_PKT | \
> > > + PKT_TX_VLAN_PKT)
> >
> > We should really stop adding some public constants without the proper
> > RTE prefix.
> > And by the way, should not we move such flags into rte_net?
>
> Do not worry with this comment. It was just a thought which could be
> addressed in a separate patch by someone else.
I've used this name convention to be consistent with other offload flag names, and this is the only reason. The place of these flags was chosen for easier management (flags and mask in one place).
I will leave it as is.
>
> > [...]
> > > -SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include := rte_ip.h rte_tcp.h
> > > rte_udp.h rte_sctp.h rte_icmp.h rte_arp.h
> > > +SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include := rte_ip.h rte_tcp.h
> > > +rte_udp.h rte_sctp.h rte_icmp.h rte_arp.h rte_pkt.h
> >
> > You can use the += operator on a new line for free :)
> >
> > No more comments, the rest seems OK. Thanks
>
Some additional work was needed due to the new tx tunnel type flags and changes in csum engine.
I will send v5 today.
Tomasz
^ permalink raw reply
* Re: [PATCH] eal: avoid unnecessary conflicts over rte_config file
From: Ananyev, Konstantin @ 2016-10-13 10:53 UTC (permalink / raw)
To: John Ousterhout, thomas.monjalon@6wind.com; +Cc: dev@dpdk.org
In-Reply-To: <20161012212917.10760-1-ouster@cs.stanford.edu>
Hi John,
> Before this patch, DPDK used the file ~/.rte_config as a lock to detect
> potential interference between multiple DPDK applications running on the
> same machine. However, if a single user ran DPDK applications concurrently
> on several different machines, and if the user's home directory was shared
> between the machines via NFS, DPDK would incorrectly detect conflicts
> for all but the first application and abort them. This patch fixes the
> problem by incorporating the machine name into the config file name (e.g.,
> ~/.rte_hostname_config).
>
> Signed-off-by: John Ousterhout <ouster@cs.stanford.edu>
> ---
> doc/guides/prog_guide/multi_proc_support.rst | 11 +++++++----
> lib/librte_eal/common/eal_common_proc.c | 8 ++------
> lib/librte_eal/common/eal_filesystem.h | 15 +++++++++++++--
> 3 files changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst
> index badd102..a54fa1c 100644
> --- a/doc/guides/prog_guide/multi_proc_support.rst
> +++ b/doc/guides/prog_guide/multi_proc_support.rst
> @@ -129,10 +129,13 @@ Support for this usage scenario is provided using the ``--file-prefix`` paramete
>
> By default, the EAL creates hugepage files on each hugetlbfs filesystem using the rtemap_X filename,
> where X is in the range 0 to the maximum number of hugepages -1.
> -Similarly, it creates shared configuration files, memory mapped in each process, using the /var/run/.rte_config filename,
> -when run as root (or $HOME/.rte_config when run as a non-root user;
> -if filesystem and device permissions are set up to allow this).
> -The rte part of the filenames of each of the above is configurable using the file-prefix parameter.
> +Similarly, it creates shared configuration files, memory mapped in each process.
> +When run as root, the name of the configuration file will be
> +/var/run/.rte_*host*_config, where *host* is the name of the machine.
> +When run as a non-root user, the the name of the configuration file will be
> +$HOME/.rte_*host*_config (if filesystem and device permissions are set up to allow this).
> +If the ``--file-prefix`` parameter has been specified, its value will be used
> +in place of "rte" in the file names.
I am not sure that we need to handle all such cases inside EAL.
User can easily overcome that problem by just adding something like:
--file-prefix=`uname -n`
to his command-line.
Konstantin
>
> In addition to specifying the file-prefix parameter,
> any DPDK applications that are to be run side-by-side must explicitly limit their memory use.
> diff --git a/lib/librte_eal/common/eal_common_proc.c b/lib/librte_eal/common/eal_common_proc.c
> index 12e0fca..517aa0c 100644
> --- a/lib/librte_eal/common/eal_common_proc.c
> +++ b/lib/librte_eal/common/eal_common_proc.c
> @@ -45,12 +45,8 @@ rte_eal_primary_proc_alive(const char *config_file_path)
>
> if (config_file_path)
> config_fd = open(config_file_path, O_RDONLY);
> - else {
> - char default_path[PATH_MAX+1];
> - snprintf(default_path, PATH_MAX, RUNTIME_CONFIG_FMT,
> - default_config_dir, "rte");
> - config_fd = open(default_path, O_RDONLY);
> - }
> + else
> + config_fd = open(eal_runtime_config_path(), O_RDONLY);
> if (config_fd < 0)
> return 0;
>
> diff --git a/lib/librte_eal/common/eal_filesystem.h b/lib/librte_eal/common/eal_filesystem.h
> index fdb4a70..4929aa3 100644
> --- a/lib/librte_eal/common/eal_filesystem.h
> +++ b/lib/librte_eal/common/eal_filesystem.h
> @@ -41,7 +41,7 @@
> #define EAL_FILESYSTEM_H
>
> /** Path of rte config file. */
> -#define RUNTIME_CONFIG_FMT "%s/.%s_config"
> +#define RUNTIME_CONFIG_FMT "%s/.%s_%s_config"
>
> #include <stdint.h>
> #include <limits.h>
> @@ -59,11 +59,22 @@ eal_runtime_config_path(void)
> static char buffer[PATH_MAX]; /* static so auto-zeroed */
> const char *directory = default_config_dir;
> const char *home_dir = getenv("HOME");
> + static char nameBuffer[1000];
> + int result;
>
> if (getuid() != 0 && home_dir != NULL)
> directory = home_dir;
> +
> + /*
> + * Include the name of the host in the config file path. Otherwise,
> + * if DPDK applications run on different hosts but share a home
> + * directory (e.g. via NFS), they will choose the same config
> + * file and conflict unnecessarily.
> + */
> + result = gethostname(nameBuffer, sizeof(nameBuffer)-1);
> snprintf(buffer, sizeof(buffer) - 1, RUNTIME_CONFIG_FMT, directory,
> - internal_config.hugefile_prefix);
> + internal_config.hugefile_prefix,
> + (result == 0) ? nameBuffer : "unknown-host");
> return buffer;
> }
>
> --
> 2.8.3
^ permalink raw reply
* Re: [PATCH v2 2/3] app/testpmd: fix wrong flow director mask
From: Ferruh Yigit @ 2016-10-13 11:00 UTC (permalink / raw)
To: Wenzhuo Lu, dev; +Cc: Pablo de Lara
In-Reply-To: <1476253462-13000-3-git-send-email-wenzhuo.lu@intel.com>
Hi Wenzhuo,
On 10/12/2016 7:24 AM, Wenzhuo Lu wrote:
> In mac-vlan mode, MAC address mask is not supported by HW.
> The MAC address mask should not be set in mac-vlan mode.
> Remove this parameter from the CLI. Remove MAC address
> from mask print too.
>
> Fixes: 53b2bb9b7ea7 ("app/testpmd: new flow director commands")
> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> ---
I think it is good to require an ack from testpmd maintainer for this
patch. cc'ed Pablo.
Thanks,
ferruh
^ permalink raw reply
* Re: [PATCH] net/i40e: Fix a typo in a comment (Fortville instead of IXGBE).
From: Ferruh Yigit @ 2016-10-13 11:09 UTC (permalink / raw)
To: Wu, Jingjing, Rosen, Rami, dev@dpdk.org
In-Reply-To: <9BB6961774997848B5B42BEC655768F80E272435@SHSMSX103.ccr.corp.intel.com>
On 9/25/2016 11:03 AM, Wu, Jingjing wrote:
>
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Rami Rosen
>> Sent: Monday, August 1, 2016 12:52 PM
>> To: dev@dpdk.org
>> Cc: Rosen, Rami <rami.rosen@intel.com>
>> Subject: [dpdk-dev] [PATCH] net/i40e: Fix a typo in a comment (Fortville instead of IXGBE).
>>
>> This patch fixes a typo in a comment in i40e_ethdev.c: use Fortville instead of
>> IXGBE.
>>
>> Signed-off-by: Rami Rosen <rami.rosen@intel.com>
>
> Thanks!
>
> Acked-by: Jingjing Wu <jingjing.wu@intel.com>
>
This patch is no more valid since following commit removes the comment
completely:
c830cb295411 ("drivers: use PCI registration macro")
dropping the patch.
Thanks,
ferruh
^ permalink raw reply
* Re: [PATCH] pdump: fix dir permissions value in mkdir call
From: Tan, Jianfeng @ 2016-10-13 11:24 UTC (permalink / raw)
To: Pattan, Reshma, dev@dpdk.org; +Cc: Pattan, Reshma
In-Reply-To: <1476110148-31624-1-git-send-email-reshma.pattan@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Reshma Pattan
> Sent: Monday, October 10, 2016 10:36 PM
> To: dev@dpdk.org
> Cc: Pattan, Reshma
> Subject: [dpdk-dev] [PATCH] pdump: fix dir permissions value in mkdir call
>
> From: Reshma Pattan <reshma.pattan@intel.com>
>
> Inside the function pdump_get_socket_path(), pdump socket
> directories are created using mkdir() call with permissions 700,
> which was assigning wrong permissions to the directories
> i.e. "d-w-r-xr-T" instead of drwx---. The reason is mkdir() call
> doesn't consider 700 as an octal value until unless 0 is explicitly
> added before the value. Because of this, socket creation failure is
> observed when DPDK application was ran in non root user mode.
> DPDK application running in root user mode never reported the issue.
>
> So 0 is prefixed to the value to create directories with
> the correct permissions.
>
> Fixes: e4ffa2d3 ("pdump: fix error handlings")
> Fixes: bdd8dcc6 ("pdump: fix default socket path")
>
> Reported-by: Jianfeng Tan <jianfeng.tan@intel.com>
> Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
Tested-by: Jianfeng Tan <jianfeng.tan@intel.com>
Thank you Reshma.
^ permalink raw reply
* Re: [PATCH] mempool: fix search of maximum contiguous pages
From: Dai, Wei @ 2016-10-13 11:52 UTC (permalink / raw)
To: Ananyev, Konstantin, dev@dpdk.org, Gonzalez Monroy, Sergio,
Tan, Jianfeng
In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0C11A5@irsmsx105.ger.corp.intel.com>
> > > diff --git a/lib/librte_mempool/rte_mempool.c
> > > b/lib/librte_mempool/rte_mempool.c
> > > index 71017e1..e3e254a 100644
> > > --- a/lib/librte_mempool/rte_mempool.c
> > > +++ b/lib/librte_mempool/rte_mempool.c
> > > @@ -426,9 +426,12 @@ rte_mempool_populate_phys_tab(struct
> > > rte_mempool *mp, char *vaddr,
> > >
> > > for (i = 0; i < pg_num && mp->populated_size < mp->size; i += n) {
> > >
> > > + phys_addr_t paddr_next;
> > > + paddr_next = paddr[i] + pg_sz;
> > > +
> > > /* populate with the largest group of contiguous pages */
> > > for (n = 1; (i + n) < pg_num &&
> > > - paddr[i] + pg_sz == paddr[i+n]; n++)
> > > + paddr_next == paddr[i+n]; n++, paddr_next += pg_sz)
> > > ;
> >
> > Good catch.
> > Why not just paddr[i + n - 1] != paddr[i + n]?
>
> Sorry, I meant 'paddr[i + n - 1] + pg_sz == paddr[i+n]' off course.
>
> > Then you don't need extra variable (paddr_next) here.
> > Konstantin
Thank you, Konstantin
'paddr[i + n - 1] + pg_sz = paddr[i + n]' also can fix it and have straight meaning.
But I assume that my revision with paddr_next += pg_sz may have a bit better performance.
By the way, paddr[i] + n * pg_sz = paddr[i + n] can also resolve it.
/Wei
> >
> > >
> > > ret = rte_mempool_populate_phys(mp, vaddr + i * pg_sz,
> > > --
> > > 2.7.4
^ permalink raw reply
* Re: [PATCH 1/5] i40e: extract non-x86 specific code from vector driver
From: Zhang, Qi Z @ 2016-10-13 11:58 UTC (permalink / raw)
To: Jianbo Liu
Cc: Zhang, Helin, Wu, Jingjing, jerin.jacob@caviumnetworks.com,
dev@dpdk.org
In-Reply-To: <CAP4Qi3_a2dNfZ=0kTfk-+4MQjJ-rffmp3hq_LRh3vVMXH=H6qw@mail.gmail.com>
Hi Jianbo
> -----Original Message-----
> From: Jianbo Liu [mailto:jianbo.liu@linaro.org]
> Sent: Thursday, October 13, 2016 11:00 AM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: Zhang, Helin <helin.zhang@intel.com>; Wu, Jingjing
> <jingjing.wu@intel.com>; jerin.jacob@caviumnetworks.com; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/5] i40e: extract non-x86 specific code from
> vector driver
>
> On 12 October 2016 at 10:55, Zhang, Qi Z <qi.z.zhang@intel.com> wrote:
> > Hi Jianbo
> >
> >> -----Original Message-----
> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jianbo Liu
> >> Sent: Wednesday, August 24, 2016 5:54 PM
> >> To: Zhang, Helin <helin.zhang@intel.com>; Wu, Jingjing
> >> <jingjing.wu@intel.com>; jerin.jacob@caviumnetworks.com;
> dev@dpdk.org
> >> Cc: Jianbo Liu <jianbo.liu@linaro.org>
> >> Subject: [dpdk-dev] [PATCH 1/5] i40e: extract non-x86 specific code
> >> from vector driver
> >>
> >> move scalar code which does not use x86 intrinsic functions to new
> >> file "i40e_rxtx_vec_common.h", while keeping x86 code in
> i40e_rxtx_vec.c.
> >> This allows the scalar code to to be shared among vector drivers for
> >> different platforms.
> >>
> >> Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
> >> ---
> ...
> >
> > Should we rename the function "_40e_rx_queue_release_mbufs_vec" to
> > "i40e_rx_queue_release_mbufs_vec_default", so functions be wrapped
> can follow a consistent rule?
>
> I think these two ways are different.
> For func/_func, _func implements what func needs to do, they are same.
> We needs _func inline, to be called in different ARCHs.
> But for func/func_default, func_default is the default behavior, but you can
> use or not-use it in func.
Got your point, I also saw ixgbe is implemented in the same way.
Thanks!
Qi
^ permalink raw reply
* [PATCH] app/test: add crypto continual tests
From: Arek Kusztal @ 2016-10-13 12:17 UTC (permalink / raw)
To: dev
Cc: fiona.trahe, pablo.de.lara.guarch, john.griffin, deepak.k.jain,
Arek Kusztal
This commit adds continual performace tests to Intel(R) QuickAssist
Technology tests suite. Performance tests are run continually with
some number of repeating loops.
Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
app/test/test_cryptodev_perf.c | 133 ++++++++++++++++++++++++++++++++++++-----
1 file changed, 119 insertions(+), 14 deletions(-)
diff --git a/app/test/test_cryptodev_perf.c b/app/test/test_cryptodev_perf.c
index 43a7166..dd741fa 100644
--- a/app/test/test_cryptodev_perf.c
+++ b/app/test/test_cryptodev_perf.c
@@ -3876,9 +3876,9 @@ perf_AES_GCM(uint8_t dev_id, uint16_t queue_id,
}
static int
-test_perf_AES_GCM(void)
+test_perf_AES_GCM(int continual_buf_len, int continual_size)
{
- uint16_t i, j;
+ uint16_t i, j, k, loops = 1;
uint16_t buf_lengths[] = { 64, 128, 256, 512, 1024, 1536, 2048 };
@@ -3886,6 +3886,9 @@ test_perf_AES_GCM(void)
&AES_GCM_128_12IV_0AAD
};
+ if (continual_buf_len)
+ loops = continual_size;
+
int TEST_CASES_GCM = RTE_DIM(gcm_tests);
const unsigned burst_size = 32;
@@ -3930,21 +3933,42 @@ test_perf_AES_GCM(void)
params_set[i].chain = CIPHER_HASH;
params_set[i].session_attrs = &session_attrs[i];
params_set[i].symmetric_op = &ops_set[i];
- params_set[i].total_operations = 1000000;
+ if (continual_buf_len)
+ params_set[i].total_operations = 0xFFFFFF;
+ else
+ params_set[i].total_operations = 1000000;
+
params_set[i].burst_size = burst_size;
}
+ if (continual_buf_len)
+ printf("\nCipher algo: %s Cipher hash: %s cipher key size: %ub"
+ " burst size: %u", "AES_GCM", "AES_GCM",
+ gcm_test->key.len << 3, burst_size);
+
for (i = 0; i < RTE_DIM(gcm_tests); i++) {
- printf("\nCipher algo: %s Cipher hash: %s cipher key size: %ub"
+ if (!continual_buf_len) {
+ printf("\nCipher algo: %s Cipher hash: %s cipher key size: %ub"
" burst size: %u", "AES_GCM", "AES_GCM",
- gcm_test->key.len << 3, burst_size
- );
- printf("\nBuffer Size(B)\tOPS(M)\tThroughput(Gbps)\t"
- " Retries\tEmptyPolls");
+ gcm_test->key.len << 3, burst_size);
+ printf("\nBuffer Size(B)\tOPS(M)\tThroughput(Gbps)\t"
+ " Retries\tEmptyPolls");
+ }
- for (j = 0; j < RTE_DIM(buf_lengths); ++j) {
+ uint16_t len = RTE_DIM(buf_lengths);
+ uint16_t p = 0;
+
+ if (continual_buf_len) {
+ for (k = 0; k < RTE_DIM(buf_lengths); k++)
+ if (buf_lengths[k] == continual_buf_len) {
+ len = k + 1;
+ p = k;
+ break;
+ }
+ }
+ for (j = p; j < len; ++j) {
params_set[i].symmetric_op->c_len = buf_lengths[j];
params_set[i].symmetric_op->p_len = buf_lengths[j];
@@ -3959,9 +3983,16 @@ test_perf_AES_GCM(void)
¶ms_set[i], 1))
return TEST_FAILED;
- if (perf_AES_GCM(testsuite_params.dev_id, 0,
- ¶ms_set[i], 0))
- return TEST_FAILED;
+ for (k = 0; k < loops; k++) {
+ if (continual_buf_len)
+ printf("\n\nBuffer Size(B)\tOPS(M)\tThroughput(Gbps)\t"
+ " Retries\tEmptyPolls");
+ if (perf_AES_GCM(testsuite_params.dev_id, 0,
+ ¶ms_set[i], 0))
+ return TEST_FAILED;
+ if (continual_buf_len)
+ printf("\n\nCompleted loop %i of %i ...", k+1, loops);
+ }
}
}
@@ -3969,6 +4000,70 @@ test_perf_AES_GCM(void)
return 0;
}
+static int test_cryptodev_perf_AES_GCM(void)
+{
+ return test_perf_AES_GCM(0, 0);
+}
+/*
+ * This function calls AES GCM performance tests providing
+ * size of packet as an argument. If size of packet is not
+ * in the buf_lengths array, all sizes will be used
+ */
+static int test_continual_perf_AES_GCM(void)
+{
+ return test_perf_AES_GCM(1024, 10);
+}
+
+static int
+test_perf_continual_performance_test(void)
+{
+ unsigned total_operations = 0xFFFFFF;
+ unsigned total_loops = 10;
+ unsigned burst_size = 32;
+ uint8_t i;
+
+ struct perf_test_params params_set = {
+ .total_operations = total_operations,
+ .burst_size = burst_size,
+ .buf_size = 1024,
+
+ .chain = CIPHER_HASH,
+
+ .cipher_algo = RTE_CRYPTO_CIPHER_AES_CBC,
+ .cipher_key_length = 16,
+ .auth_algo = RTE_CRYPTO_AUTH_SHA1_HMAC
+ };
+
+ for (i = 1; i <= total_loops; ++i) {
+ printf("\n%s. cipher algo: %s auth algo: %s cipher key size=%u."
+ " burst_size: %d ops\n",
+ chain_mode_name(params_set.chain),
+ cipher_algo_name(params_set.cipher_algo),
+ auth_algo_name(params_set.auth_algo),
+ params_set.cipher_key_length,
+ burst_size);
+ printf("\nBuffer Size(B)\tOPS(M)\tThroughput(Gbps)\t"
+ "Retries\tEmptyPolls\n");
+ test_perf_aes_sha(testsuite_params.dev_id, 0,
+ ¶ms_set);
+ printf("\nCompleted loop %i of %i ...", i, total_loops);
+ }
+ return 0;
+}
+
+static struct unit_test_suite cryptodev_qat_continual_testsuite = {
+ .suite_name = "Crypto Device Continual Performance Test",
+ .setup = testsuite_setup,
+ .teardown = testsuite_teardown,
+ .unit_test_cases = {
+ TEST_CASE_ST(ut_setup, ut_teardown,
+ test_perf_continual_performance_test),
+ TEST_CASE_ST(ut_setup, ut_teardown,
+ test_continual_perf_AES_GCM),
+ TEST_CASES_END() /**< NULL terminate unit test array */
+ }
+};
+
static struct unit_test_suite cryptodev_testsuite = {
.suite_name = "Crypto Device Unit Test Suite",
.setup = testsuite_setup,
@@ -3977,7 +4072,7 @@ static struct unit_test_suite cryptodev_testsuite = {
TEST_CASE_ST(ut_setup, ut_teardown,
test_perf_aes_cbc_encrypt_digest_vary_pkt_size),
TEST_CASE_ST(ut_setup, ut_teardown,
- test_perf_AES_GCM),
+ test_cryptodev_perf_AES_GCM),
TEST_CASE_ST(ut_setup, ut_teardown,
test_perf_aes_cbc_vary_burst_size),
TEST_CASES_END() /**< NULL terminate unit test array */
@@ -3990,7 +4085,7 @@ static struct unit_test_suite cryptodev_gcm_testsuite = {
.teardown = testsuite_teardown,
.unit_test_cases = {
TEST_CASE_ST(ut_setup, ut_teardown,
- test_perf_AES_GCM),
+ test_cryptodev_perf_AES_GCM),
TEST_CASES_END() /**< NULL terminate unit test array */
}
};
@@ -4080,6 +4175,14 @@ perftest_libcrypto_cryptodev(void /*argv __rte_unused, int argc __rte_unused*/)
return unit_test_suite_runner(&cryptodev_libcrypto_testsuite);
}
+static int
+perftest_qat_continual_cryptodev(void)
+{
+ gbl_cryptodev_perftest_devtype = RTE_CRYPTODEV_QAT_SYM_PMD;
+
+ return unit_test_suite_runner(&cryptodev_qat_continual_testsuite);
+}
+
REGISTER_TEST_COMMAND(cryptodev_aesni_mb_perftest, perftest_aesni_mb_cryptodev);
REGISTER_TEST_COMMAND(cryptodev_qat_perftest, perftest_qat_cryptodev);
REGISTER_TEST_COMMAND(cryptodev_sw_snow3g_perftest, perftest_sw_snow3g_cryptodev);
@@ -4087,3 +4190,5 @@ REGISTER_TEST_COMMAND(cryptodev_qat_snow3g_perftest, perftest_qat_snow3g_cryptod
REGISTER_TEST_COMMAND(cryptodev_aesni_gcm_perftest, perftest_aesni_gcm_cryptodev);
REGISTER_TEST_COMMAND(cryptodev_libcrypto_perftest,
perftest_libcrypto_cryptodev);
+REGISTER_TEST_COMMAND(cryptodev_qat_continual_perftest,
+ perftest_qat_continual_cryptodev);
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] mempool: fix search of maximum contiguous pages
From: Ananyev, Konstantin @ 2016-10-13 12:31 UTC (permalink / raw)
To: Dai, Wei, dev@dpdk.org, Gonzalez Monroy, Sergio, Tan, Jianfeng
In-Reply-To: <49759EB36A64CF4892C1AFEC9231E8D63A2D3E10@PGSMSX106.gar.corp.intel.com>
>
> > > > diff --git a/lib/librte_mempool/rte_mempool.c
> > > > b/lib/librte_mempool/rte_mempool.c
> > > > index 71017e1..e3e254a 100644
> > > > --- a/lib/librte_mempool/rte_mempool.c
> > > > +++ b/lib/librte_mempool/rte_mempool.c
> > > > @@ -426,9 +426,12 @@ rte_mempool_populate_phys_tab(struct
> > > > rte_mempool *mp, char *vaddr,
> > > >
> > > > for (i = 0; i < pg_num && mp->populated_size < mp->size; i += n) {
> > > >
> > > > + phys_addr_t paddr_next;
> > > > + paddr_next = paddr[i] + pg_sz;
> > > > +
> > > > /* populate with the largest group of contiguous pages */
> > > > for (n = 1; (i + n) < pg_num &&
> > > > - paddr[i] + pg_sz == paddr[i+n]; n++)
> > > > + paddr_next == paddr[i+n]; n++, paddr_next += pg_sz)
> > > > ;
> > >
> > > Good catch.
> > > Why not just paddr[i + n - 1] != paddr[i + n]?
> >
> > Sorry, I meant 'paddr[i + n - 1] + pg_sz == paddr[i+n]' off course.
> >
> > > Then you don't need extra variable (paddr_next) here.
> > > Konstantin
>
> Thank you, Konstantin
> 'paddr[i + n - 1] + pg_sz = paddr[i + n]' also can fix it and have straight meaning.
> But I assume that my revision with paddr_next += pg_sz may have a bit better performance.
I don't think there would be any real difference, again it is not performance critical code-path.
> By the way, paddr[i] + n * pg_sz = paddr[i + n] can also resolve it.
Yes, that's one seems even better for me - make things more clear.
Konstantin
>
> /Wei
>
> > >
> > > >
> > > > ret = rte_mempool_populate_phys(mp, vaddr + i * pg_sz,
> > > > --
> > > > 2.7.4
^ permalink raw reply
* Re: [PATCH v3 1/3] lib/librte_port: enable file descriptor port support
From: Thomas Monjalon @ 2016-10-13 12:38 UTC (permalink / raw)
To: Jasvinder Singh; +Cc: dev, cristian.dumitrescu
In-Reply-To: <1476350269-225965-1-git-send-email-jasvinder.singh@intel.com>
2016-10-13 10:17, Jasvinder Singh:
> This patch adds File Descriptor(FD) port type (e.g. TAP port) to the
> packet framework library that allows interface with the kernel network
> stack. The FD port APIs are defined that allow port creation, writing
> and reading packet from the kernel interface.
>
> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Series applied, thanks
^ permalink raw reply
* Re: [PATCH] test: fix hash multiwriter test
From: Thomas Monjalon @ 2016-10-13 13:00 UTC (permalink / raw)
To: Pablo de Lara; +Cc: dev, bruce.richardson
In-Reply-To: <1475793290-185602-1-git-send-email-pablo.de.lara.guarch@intel.com>
2016-10-06 23:34, Pablo de Lara:
> Hash multiwriter test consists of two subtests.
> If the any of the subtests fails, the overall test should fail,
> but the overall test only passed if the second subtest passed,
> because the return of the first subtest was being overwritten.
>
> Fixes: be856325cba3 ("hash: add scalable multi-writer insertion with Intel TSX")
>
> Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Applied, thanks
^ permalink raw reply
* [PATCH v2] examples/l3fwd: em: use hw accelerated crc hash function for arm64
From: Hemant Agrawal @ 2016-10-13 18:47 UTC (permalink / raw)
To: dev; +Cc: jerin.jacob, Hemant Agrawal
In-Reply-To: <1471964080-29958-1-git-send-email-hemant.agrawal@nxp.com>
if machine level CRC extension are available, offload the
hash to machine provide functions e.g. armv8-a CRC extensions
support it
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
Reviewed-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
---
examples/l3fwd/l3fwd_em.c | 24 ++++++++++++++----------
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index 89a68e6..d92d0aa 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -57,13 +57,17 @@
#include "l3fwd.h"
-#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
+#if defined(RTE_MACHINE_CPUFLAG_SSE4_2) && defined(RTE_MACHINE_CPUFLAG_CRC32)
+#define EM_HASH_CRC 1
+#endif
+
+#ifdef EM_HASH_CRC
#include <rte_hash_crc.h>
#define DEFAULT_HASH_FUNC rte_hash_crc
#else
#include <rte_jhash.h>
#define DEFAULT_HASH_FUNC rte_jhash
-#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#endif
#define IPV6_ADDR_LEN 16
@@ -168,17 +172,17 @@ ipv4_hash_crc(const void *data, __rte_unused uint32_t data_len,
t = k->proto;
p = (const uint32_t *)&k->port_src;
-#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
+#ifdef EM_HASH_CRC
init_val = rte_hash_crc_4byte(t, init_val);
init_val = rte_hash_crc_4byte(k->ip_src, init_val);
init_val = rte_hash_crc_4byte(k->ip_dst, init_val);
init_val = rte_hash_crc_4byte(*p, init_val);
-#else /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#else
init_val = rte_jhash_1word(t, init_val);
init_val = rte_jhash_1word(k->ip_src, init_val);
init_val = rte_jhash_1word(k->ip_dst, init_val);
init_val = rte_jhash_1word(*p, init_val);
-#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#endif
return init_val;
}
@@ -190,16 +194,16 @@ ipv6_hash_crc(const void *data, __rte_unused uint32_t data_len,
const union ipv6_5tuple_host *k;
uint32_t t;
const uint32_t *p;
-#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
+#ifdef EM_HASH_CRC
const uint32_t *ip_src0, *ip_src1, *ip_src2, *ip_src3;
const uint32_t *ip_dst0, *ip_dst1, *ip_dst2, *ip_dst3;
-#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#endif
k = data;
t = k->proto;
p = (const uint32_t *)&k->port_src;
-#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
+#ifdef EM_HASH_CRC
ip_src0 = (const uint32_t *) k->ip_src;
ip_src1 = (const uint32_t *)(k->ip_src+4);
ip_src2 = (const uint32_t *)(k->ip_src+8);
@@ -218,14 +222,14 @@ ipv6_hash_crc(const void *data, __rte_unused uint32_t data_len,
init_val = rte_hash_crc_4byte(*ip_dst2, init_val);
init_val = rte_hash_crc_4byte(*ip_dst3, init_val);
init_val = rte_hash_crc_4byte(*p, init_val);
-#else /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#else
init_val = rte_jhash_1word(t, init_val);
init_val = rte_jhash(k->ip_src,
sizeof(uint8_t) * IPV6_ADDR_LEN, init_val);
init_val = rte_jhash(k->ip_dst,
sizeof(uint8_t) * IPV6_ADDR_LEN, init_val);
init_val = rte_jhash_1word(*p, init_val);
-#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#endif
return init_val;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v3 2/2] mempool: pktmbuf pool default fallback for mempool ops error
From: Hemant Agrawal @ 2016-10-13 13:15 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev, jerin.jacob, david.hunt
In-Reply-To: <b7576317-e96b-5859-234f-c385a3051c2b@nxp.com>
Hi Olivier,
Any updates w.r.t this patch set?
Regards
Hemant
On 9/22/2016 6:42 PM, Hemant Agrawal wrote:
> Hi Olivier
>
> On 9/19/2016 7:27 PM, Olivier Matz wrote:
>> Hi Hemant,
>>
>> On 09/16/2016 06:46 PM, Hemant Agrawal wrote:
>>> In the rte_pktmbuf_pool_create, if the default external mempool is
>>> not available, the implementation can default to "ring_mp_mc", which
>>> is an software implementation.
>>>
>>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>>> ---
>>> Changes in V3:
>>> * adding warning message to say that falling back to default sw pool
>>> ---
>>> lib/librte_mbuf/rte_mbuf.c | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
>>> index 4846b89..8ab0eb1 100644
>>> --- a/lib/librte_mbuf/rte_mbuf.c
>>> +++ b/lib/librte_mbuf/rte_mbuf.c
>>> @@ -176,6 +176,14 @@ rte_pktmbuf_pool_create(const char *name,
>>> unsigned n,
>>>
>>> rte_errno = rte_mempool_set_ops_byname(mp,
>>> RTE_MBUF_DEFAULT_MEMPOOL_OPS, NULL);
>>> +
>>> + /* on error, try falling back to the software based default pool */
>>> + if (rte_errno == -EOPNOTSUPP) {
>>> + RTE_LOG(WARNING, MBUF, "Default HW Mempool not supported. "
>>> + "falling back to sw mempool \"ring_mp_mc\"");
>>> + rte_errno = rte_mempool_set_ops_byname(mp, "ring_mp_mc", NULL);
>>> + }
>>> +
>>> if (rte_errno != 0) {
>>> RTE_LOG(ERR, MBUF, "error setting mempool handler\n");
>>> return NULL;
>>>
>>
>> Without adding a new method ".supported()", the first call to
>> rte_mempool_populate() could return the same error ENOTSUP. In this
>> case, it is still possible to fallback.
>>
> It will be bit late.
>
> On failure, than we have to set the default ops and do a goto before
> rte_pktmbuf_pool_init(mp, &mbp_priv);
>
>
>> I've just submitted an RFC, which I think is quite linked:
>> http://dpdk.org/ml/archives/dev/2016-September/046974.html
>> Assuming a new parameter "mempool_ops" is added to
>> rte_pktmbuf_pool_create(), would it make sense to fallback to
>> "ring_mp_mc"? What about just returning ENOTSUP? The application could
>> do the job and decide which sw fallback to use.
>
> We ran into this issue when trying to run the standard DPDK examples
> (l3fwd) in VM. Do you think, is it practical to add fallback handling in
> each of the DPDK examples?
>
> Typically when someone is writing a application on host, he need not
> worry non-availability of the hw offloaded mempool. He may also want to
> run the same binary in virtual machine. In VM, it is not guaranteed that
> hw offloaded mempools will be available.
>
> w.r.t your RFC, we can do this:
> if the user has specified a mempool_ops in rte_pktmbuf_pool_create(),
> don't fallback. It will be responsibility for application to decide on
> calling again rte_pktmbuf_pool_create() with different mempool_ops.
>
>>
>>
>> Regards,
>> Olivier
>>
>
>
>
^ permalink raw reply
* Re: [PATCH] net/enic: remove assert which causes compile error
From: Bruce Richardson @ 2016-10-13 13:22 UTC (permalink / raw)
To: John Daley; +Cc: dev
In-Reply-To: <20161012180935.8366-1-johndale@cisco.com>
On Wed, Oct 12, 2016 at 11:09:35AM -0700, John Daley wrote:
> Remove an RTE_ASSERT which will not compile if enabled and is not needed.
>
> Fixes: a1f7c7b3b5b2 ("net/enic: extend fdir support for 1300 series adapters")
>
> Signed-off-by: John Daley <johndale@cisco.com>
> ---
> Would have been nice if I caught this yesterday before you applied a1f7c7b3 :(
>
Since commit a1f7c7b3 has not been pulled into the dpdk.org mainline, I can still
merge this commit into the origin one that has the bug. Unless you object, I
shall do so now.
/Bruce
^ permalink raw reply
* Re: [PATCH v2] app/test: remove large lpm test head file
From: Thomas Monjalon @ 2016-10-13 13:28 UTC (permalink / raw)
To: Wei Dai; +Cc: dev, bruce.richardson
In-Reply-To: <1474997907-24982-1-git-send-email-wei.dai@intel.com>
2016-09-28 01:38, Wei Dai:
> remove the large file app/test/test_lpm_routes.h and add codes to
> auto-generate similar large route rule talbe which keeps same depth
> and IP class distribution as previous one in test_lpm_routes.h .
> With the rule table auto-generated at run time, the performance
> of looking up keep similar to that from pervious constant talbe.
>
> Signed-off-by: Wei Dai <wei.dai@intel.com>
Applied, thanks
There is a comment which may be difficult to understand for newcomers.
Indeed it refers to the old file app/test/test_lpm_routes.h.
However it is not really an issue as this file is a *huge* part of the
DPDK history ;)
^ permalink raw reply
* Re: [PATCH v2] examples/l3fwd: em: use hw accelerated crc hash function for arm64
From: Jerin Jacob @ 2016-10-13 13:36 UTC (permalink / raw)
To: Hemant Agrawal; +Cc: dev
In-Reply-To: <1476384425-11787-1-git-send-email-hemant.agrawal@nxp.com>
On Fri, Oct 14, 2016 at 12:17:05AM +0530, Hemant Agrawal wrote:
> if machine level CRC extension are available, offload the
> hash to machine provide functions e.g. armv8-a CRC extensions
> support it
>
> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
> Reviewed-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> ---
> examples/l3fwd/l3fwd_em.c | 24 ++++++++++++++----------
> 1 file changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
> index 89a68e6..d92d0aa 100644
> --- a/examples/l3fwd/l3fwd_em.c
> +++ b/examples/l3fwd/l3fwd_em.c
> @@ -57,13 +57,17 @@
>
> #include "l3fwd.h"
>
> -#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
> +#if defined(RTE_MACHINE_CPUFLAG_SSE4_2) && defined(RTE_MACHINE_CPUFLAG_CRC32)
The will evaluate as FALSE always.
Please change to logical OR operation here. ie #if defined(RTE_MACHINE_CPUFLAG_SSE4_2) ||
defined(RTE_MACHINE_CPUFLAG_CRC32)
> +#define EM_HASH_CRC 1
> +#endif
^ permalink raw reply
* Re: [PATCH] net/enic: remove assert which causes compile error
From: Bruce Richardson @ 2016-10-13 13:37 UTC (permalink / raw)
To: John Daley; +Cc: dev
In-Reply-To: <20161013132215.GA138296@bricha3-MOBL3>
On Thu, Oct 13, 2016 at 02:22:16PM +0100, Bruce Richardson wrote:
> On Wed, Oct 12, 2016 at 11:09:35AM -0700, John Daley wrote:
> > Remove an RTE_ASSERT which will not compile if enabled and is not needed.
> >
> > Fixes: a1f7c7b3b5b2 ("net/enic: extend fdir support for 1300 series adapters")
> >
> > Signed-off-by: John Daley <johndale@cisco.com>
> > ---
> > Would have been nice if I caught this yesterday before you applied a1f7c7b3 :(
> >
> Since commit a1f7c7b3 has not been pulled into the dpdk.org mainline, I can still
> merge this commit into the origin one that has the bug. Unless you object, I
> shall do so now.
>
> /Bruce
Done. Fix merged into original commit
/Bruce
^ permalink raw reply
* [PATCH] testpmd: fix tso with csum engine
From: Olivier Matz @ 2016-10-13 13:40 UTC (permalink / raw)
To: dev, pablo.de.lara.guarch; +Cc: thomas.monjalon
The commit that disabled tso for small packets was broken during the
rebase. The problem is the IP checksum is not calculated in software if:
- TX IP checksum is disabled
- TSO is enabled
- the current packet is smaller than tso segment size
When checking if the PKT_TX_IP_CKSUM flag should be set (in case
of tso), use the local tso_segsz variable, which is set to 0 when the
packet is too small to require tso. Therefore the IP checksum will be
correctly calculated in software.
Moreover, we should not use tunnel segment size for non-tunnel tso, else
TSO will stay disabled for all packets.
Fixes: 97c21329d42b ("app/testpmd: do not use TSO for small packets")
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
---
app/test-pmd/csumonly.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index f9e65b6..27d0f08 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -336,7 +336,7 @@ process_inner_cksums(void *l3_hdr, const struct testpmd_offload_info *info,
if (!info->is_tunnel) {
max_pkt_len = info->l2_len + info->l3_len + info->l4_len +
info->tso_segsz;
- if (info->tunnel_tso_segsz != 0 && info->pkt_len > max_pkt_len)
+ if (info->tso_segsz != 0 && info->pkt_len > max_pkt_len)
tso_segsz = info->tso_segsz;
} else {
max_pkt_len = info->outer_l2_len + info->outer_l3_len +
@@ -351,9 +351,7 @@ process_inner_cksums(void *l3_hdr, const struct testpmd_offload_info *info,
ipv4_hdr->hdr_checksum = 0;
ol_flags |= PKT_TX_IPV4;
- if (info->l4_proto == IPPROTO_TCP &&
- ((info->is_tunnel && info->tunnel_tso_segsz != 0) ||
- (!info->is_tunnel && info->tso_segsz != 0))) {
+ if (info->l4_proto == IPPROTO_TCP && tso_segsz) {
ol_flags |= PKT_TX_IP_CKSUM;
} else {
if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_IP_CKSUM)
--
2.8.1
^ permalink raw reply related
* Re: [PATCH] app/test: reduce lpm6 test case size
From: Thomas Monjalon @ 2016-10-13 13:41 UTC (permalink / raw)
To: Wei Dai; +Cc: dev, bruce.richardson
In-Reply-To: <1475172693-23704-1-git-send-email-wei.dai@intel.com>
2016-09-30 02:11, Wei Dai:
> copy app/test/test_lpm6_routes.h to app/test/test_lpm6_data.h .
> and then delete app/test/test_lpm6_routes.h and clear the
> large_ips_table[ ] to make LPM6 test case size much smaller than
> before. Also add codes in app/test/test_lpm6_data.h to generate test
> data in large_ips_table[ ] at run time.
>
> Signed-off-by: Wei Dai <wei.dai@intel.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH] net/ring: fix ring eth dev creation via devargs
From: Bruce Richardson @ 2016-10-13 13:42 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev, Neil Horman
In-Reply-To: <20161013102156.GA131080@bricha3-MOBL3>
On Thu, Oct 13, 2016 at 11:21:57AM +0100, Bruce Richardson wrote:
> On Wed, Aug 31, 2016 at 05:51:11PM +0100, Ferruh Yigit wrote:
> > Using nodeaction devarg lets creating multiple ring eth devices:
> > "eth_ring0,nodeaction=R0:0:CREATE,nodeaction=R1:0:CREATE"
> >
> > Trying to create all devices with same name fails. Since first part of
> > the nodeaction devarg is name (in above sample R0,R1), this name field
> > can be used as eth dev name.
> >
> > Fixes: 61934c0956d4 ("ring: convert to use of PMD_REGISTER_DRIVER and fix linking")
> >
> > Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> > ---
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
>
Applied to dpdk-next-net/rel_16_11
/Bruce
^ permalink raw reply
* Re: [PATCH] net/ring: fix param string info
From: Bruce Richardson @ 2016-10-13 13:42 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev
In-Reply-To: <20161013102224.GB131080@bricha3-MOBL3>
On Thu, Oct 13, 2016 at 11:22:25AM +0100, Bruce Richardson wrote:
> On Wed, Aug 31, 2016 at 05:53:51PM +0100, Ferruh Yigit wrote:
> > Fixes: 65eca099f405 ("drivers: split parameters infos in multiple lines")
> >
> > Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> > ---
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Applied to dpdk-next-net/rel_16_11
/Bruce
^ permalink raw reply
* Re: [PATCH v9 0/2] add API's for VF management
From: Bruce Richardson @ 2016-10-13 13:47 UTC (permalink / raw)
To: Bernard Iremonger
Cc: dev, rahul.r.shah, wenzhuo.lu, az5157, pablo.de.lara.guarch
In-Reply-To: <1476294852-19356-1-git-send-email-bernard.iremonger@intel.com>
On Wed, Oct 12, 2016 at 06:54:10PM +0100, Bernard Iremonger wrote:
> This patchset contains new DPDK API's for use
> with the Virtual Function Daemon (VFD).
>
> The need to configure and manage VF's on a NIC has grown to the
> point where a DPDK based tool, VFD, has been developed to do this.
>
> This patch set adds API extensions to DPDK for VF configuration.
>
> Eight new API's have been added for the Intel 82559 NIC.
>
> Changes have been made to testpmd to facilitate testing of the new API's.
> The testpmd documentation has been updated to document the testpmd changes.
>
Patchset applied to dpdk-next-net/rel_16_11
/Bruce
^ permalink raw reply
* Re: [PATCH] app/test: add mempool walk
From: Thomas Monjalon @ 2016-10-13 13:51 UTC (permalink / raw)
To: dev; +Cc: Olivier Matz
In-Reply-To: <aaf424e4-4269-1561-59b5-f28774fcbf47@6wind.com>
2016-10-05 14:22, Olivier Matz:
> Hi Thomas,
>
> On 10/03/2016 10:58 PM, Thomas Monjalon wrote:
> > The mempool function rte_mempool_walk was not tested.
> > It will print the name of all mempools.
> >
> > Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
>
> Acked-by: Olivier Matz <olivier.matz@6wind.com>
Applied
^ permalink raw reply
* Re: [PATCH 2/2] app/testpmd: use consistent vdev names
From: Thomas Monjalon @ 2016-10-13 13:57 UTC (permalink / raw)
To: De Lara Guarch, Pablo; +Cc: dev
In-Reply-To: <E115CCD9D858EF4F90C690B0DCB4D8973CA056E3@IRSMSX108.ger.corp.intel.com>
2016-10-07 02:27, De Lara Guarch, Pablo:
>
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Sent: Thursday, October 06, 2016 3:34 AM
> > To: De Lara Guarch, Pablo
> > Cc: dev@dpdk.org
> > Subject: [PATCH 2/2] app/testpmd: use consistent vdev names
> >
> > The vdev eth_bond has been renamed to net_bond.
> > testpmd is creating a bonding device with the old prefix.
> > It is changed for consistency.
> >
> > The script test-null.sh was failing because using the old name
> > for the null vdev.
> >
> > Fixes also the bonding and testpmd doc.
> >
> > Fixes: 2f45703c17ac ("drivers: make driver names consistent")
> >
> > Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
>
> Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Series applied
^ permalink raw reply
* Re: [PATCH v2 03/12] virtio: reinitialize the device in configure callback
From: Olivier MATZ @ 2016-10-13 13:57 UTC (permalink / raw)
To: Yuanhan Liu
Cc: dev, konstantin.ananyev, sugesh.chandran, bruce.richardson,
jianfeng.tan, helin.zhang, adrien.mazarguil, stephen, dprovan,
xiao.w.wang
In-Reply-To: <20161013075415.GS16751@yliu-dev.sh.intel.com>
On 10/13/2016 09:54 AM, Yuanhan Liu wrote:
> On Wed, Oct 12, 2016 at 06:01:25PM +0200, Olivier MATZ wrote:
>> Hello Yuanhan,
>>
>> On 10/12/2016 04:41 PM, Yuanhan Liu wrote:
>>> On Mon, Oct 03, 2016 at 11:00:14AM +0200, Olivier Matz wrote:
>>>> @@ -1344,6 +1347,7 @@ virtio_dev_configure(struct rte_eth_dev *dev)
>>>> {
>>>> const struct rte_eth_rxmode *rxmode = &dev->data->dev_conf.rxmode;
>>>> struct virtio_hw *hw = dev->data->dev_private;
>>>> + uint64_t req_features;
>>>> int ret;
>>>>
>>>> PMD_INIT_LOG(DEBUG, "configure");
>>>> @@ -1353,6 +1357,14 @@ virtio_dev_configure(struct rte_eth_dev *dev)
>>>> return -EINVAL;
>>>> }
>>>>
>>>> + req_features = VIRTIO_PMD_GUEST_FEATURES;
>>>> + /* if request features changed, reinit the device */
>>>> + if (req_features != hw->req_guest_features) {
>>>> + ret = virtio_init_device(dev, req_features);
>>>> + if (ret < 0)
>>>> + return ret;
>>>> + }
>>>
>>> Why do you have to reset virtio here? This doesn't make too much sense
>>> to me.
>>>
>>> IIUC, you want to make sure those TSO related features being unset at
>>> init time, and enable it (by doing reset) when it's asked to be enabled
>>> (by rte_eth_dev_configure)?
>>>
>>> Why not always setting those features? We could do the actual offloads
>>> when:
>>>
>>> - those features have been negoiated
>>>
>>> - they are enabled through rte_eth_dev_configure
>>>
>>> With that, I think we could avoid the reset here?
>>
>> It would work for TX, since you decide to use or not the feature. But I
>> think this won't work for RX: if you negociate LRO at init, the host may
>> send you large packets, even if LRO is disabled in dev_configure.
>
> I see. Thanks.
>
> Besides, I think you should return error when LRO is not negoiated
> after the reset (say, when it's disabled through qemu command line)?
Good idea, I now return an error if offload cannot be negotiated.
Olivier
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox