[dpdk-dev] [PATCH v8 0/8] vhost-user multiple queues enabling

[Thomas Monjalon]

> > Changchun Ouyang (3):
> >   vhost: rxtx: use queue id instead of constant ring index
> >   virtio: fix deadloop due to reading virtio_net_config incorrectly
> >   vhost: add VHOST_USER_SET_VRING_ENABLE message
> >
> > Yuanhan Liu (5):
> >   vhost-user: add protocol features support
> >   vhost-user: add VHOST_USER_GET_QUEUE_NUM message
> >   vhost: vring queue setup for multiple queue support
> >   vhost-user: enable vhost-user multiple queue
> >   doc: update release note for vhost-user mq support
> 
> Acked-by: Huawei Xie 

Applied, thanks

[dpdk-dev] [PATCH v8 8/8] doc: update release note for vhost-user mq support

[Thomas Monjalon]

2015-10-22 20:35, Yuanhan Liu:
> +* **vhost: added vhost-user mulitple queue support.**
> +
> +  Added vhost-user multiple queue support.

Excepted the typo, it is the same sentence twice, so not needed.

General comment to every contributors: please avoid making a special commit
to just update the release notes.
There is no log message and it is understandable because it does not
deserve a commit.
It will be merged with the previous one here.

[dpdk-dev] [PATCH] default to using all cores if no -c, -l, or --lcores options given

[Thomas Monjalon]

2015-10-26 15:17, Thomas Monjalon:
> There was no comment for this new behaviour.
> It means everybody agree to default to all cores.
> 
> 2015-09-25 13:37, Rich Lane:
> > This is a useful default for simple applications where the assignment of 
> > lcores
> > to CPUs doesn't matter. It's also useful for more complex applications that
> > automatically assign tasks to cores based on the NUMA topology.
> > 
> > Signed-off-by: Rich Lane 

Applied, thanks

The documentation about the command line options must be updated and simplified.

[dpdk-dev] [PATCH] app/testpmd: add engine for UDP echo server support

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of De Lara Guarch,
> Pablo
> Sent: Monday, October 26, 2015 8:37 PM
> To: Thomas Monjalon
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] app/testpmd: add engine for UDP echo
> server support
> 
> Hi,
> 
> > -Original Message-
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Saturday, October 24, 2015 10:24 PM
> > To: De Lara Guarch, Pablo
> > Cc: dev at dpdk.org; Thadeu Lima de Souza Cascardo
> > Subject: Re: [dpdk-dev] [PATCH] app/testpmd: add engine for UDP echo
> > server support
> >
> > Pablo, opinion?
> > Is the UDP echo eligible in testpmd to ease some tests?
> >
> > 2015-09-04 14:17, Thadeu Lima de Souza Cascardo:
> > > Adapt the ICMP echo code to reply to UDP echo requests on port 7. The
> > testpmd
> > > forward engine udpecho is used for that.
> > >
> > > Signed-off-by: Thadeu Lima de Souza Cascardo 
> 
> Sorry I missed this patch. Patch looks fine, but in my opinion,
> it would be better to rename icmpecho to just echo,
> and integrate UDP and TCP, with ICMP, as I think there is no need
> to increase the number of forwarding modes for something so similar.
> 

Actually, I forgot to say that patch does not compile at least with gcc 5.1.
Variables icmp_h and udp_h in reply_to_echo_rqsts() have to be initialized.

> Pablo

[dpdk-dev] [PATCH] app/testpmd: add engine for UDP echo server support

[De Lara Guarch, Pablo]

Hi,

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Saturday, October 24, 2015 10:24 PM
> To: De Lara Guarch, Pablo
> Cc: dev at dpdk.org; Thadeu Lima de Souza Cascardo
> Subject: Re: [dpdk-dev] [PATCH] app/testpmd: add engine for UDP echo
> server support
> 
> Pablo, opinion?
> Is the UDP echo eligible in testpmd to ease some tests?
> 
> 2015-09-04 14:17, Thadeu Lima de Souza Cascardo:
> > Adapt the ICMP echo code to reply to UDP echo requests on port 7. The
> testpmd
> > forward engine udpecho is used for that.
> >
> > Signed-off-by: Thadeu Lima de Souza Cascardo 

Sorry I missed this patch. Patch looks fine, but in my opinion,
it would be better to rename icmpecho to just echo,
and integrate UDP and TCP, with ICMP, as I think there is no need
to increase the number of forwarding modes for something so similar.

Pablo

[dpdk-dev] [PATCH v1 0/3] lpm: increase number of next hops for lpm (ipv4)

[Vladimir Medvedkin]

Michal,

Looks strange, you have:
error: while searching for:

   lpm_list = RTE_TAILQ_CAST(rte_lpm_tailq.head, rte_lpm_list);
...
error: patch failed: lib/librte_lpm/rte_lpm.c:159
but if we look at
http://dpdk.org/browse/dpdk/tree/lib/librte_lpm/rte_lpm.c#n159
patch should apply fine.
Latest commit in my repo is 139debc42dc0a320dad40f5295b74d2e3ab8a7f9


2015-10-26 18:39 GMT+03:00 Michal Jastrzebski <
michalx.k.jastrzebski at intel.com>:

> esOn Mon, Oct 26, 2015 at 05:03:31PM +0300, Vladimir Medvedkin wrote:
> > Hi Michal,
> >
> > Forwarding class can help us to classify traffic based on dst prefix,
> it's
> > something like Juniper DCU. For example on Juniper MX I can make policy
> > that install prefix into the FIB with some class and use it on dataplane,
> > for example with ACL.
> > On Juniper MX I can make something like that:
> > #show policy-options
> > policy-statement community-to-class {
> > term customer {
> > from community originate-customer;
> > then destination-class customer;
> > }
> > }
> > community originate-customer members 12345:1;
> > # show routing-options
> > forwarding-table {
> > export community-to-class;
> > }
> > # show forwarding-options
> > forwarding-options {
> > family inet {
> > filter {
> > output test-filter;
> > }
> > }
> > }
> > # show firewall family inet filter test-filter
> > term 1 {
> > from {
> > protocol icmp;
> > destination-class customer;
> > }
> > then {
> > discard;
> > }
> > }
> > announce route 10.10.10.10/32 next-hop 10.10.10.2 community 12345:1
> > After than on dataplane we have
> > NPC1( vty)# show route ip lookup 10.10.10.10
> > Route Information (10.10.10.10):
> >  interface : xe-1/0/0.0 (328)
> >  Nexthop prefix : -
> >  Nexthop ID : 1048574
> >  MTU: 0
> >  Class ID   : 129 <- That is "forwarding class" in my implementation
> > This construction discards all ICMP traffic that goes to dst prefixes
> which
> > was originated with community 12345:1. With this mechanism we can
> make
> > on control plane different sophisticated policy to control traffic on
> > dataplane.
> > The same with as_num, we can have on dataplane AS number that has
> > originated that prefix, or another 4-byte number e.g. geo-id.
> > What issue do you mean? I think it is because of table/pipeline/test
> > frameworks that doesen't want to compile due to changing API/ABI. You can
> > turn it off for LPM testing, if my patch will be applied I will make
> > changes in above-mentioned frameworks.
> >
> > Regards,
> > Vladimir
>
> Hi Vladimir,
> I have an issue with applying Your patch not compilation.
> This is the error i get:
> Checking patch config/common_bsdapp...
> Checking patch config/common_linuxapp...
> Checking patch lib/librte_lpm/rte_lpm.c...
> error: while searching for:
>
>lpm_list = RTE_TAILQ_CAST(rte_lpm_tailq.head, rte_lpm_list);
>
>RTE_BUILD_BUG_ON(sizeof(struct rte_lpm_tbl24_entry) != 2);
>RTE_BUILD_BUG_ON(sizeof(struct rte_lpm_tbl8_entry) != 2);
>
>/* Check user arguments. */
>if ((name == NULL) || (socket_id < -1) || (max_rules == 0)){
>rte_errno = EINVAL;
>
> error: patch failed: lib/librte_lpm/rte_lpm.c:159
> error: lib/librte_lpm/rte_lpm.c: patch does not apply
> Checking patch lib/librte_lpm/rte_lpm.h...
> error: while searching for:
> #define RTE_LPM_RETURN_IF_TRUE(cond, retval)
> #endif
>
> /** @internal bitmask with valid and ext_entry/valid_group fields set */
> #define RTE_LPM_VALID_EXT_ENTRY_BITMASK 0x0300
>
> /** Bitmask used to indicate successful lookup */
> #define RTE_LPM_LOOKUP_SUCCESS  0x0100
>
> #if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
> /** @internal Tbl24 entry structure. */
> struct rte_lpm_tbl24_entry {
>/* Stores Next hop or group index (i.e. gindex)into tbl8. */
>union {
>uint8_t next_hop;
>uint8_t tbl8_gindex;
>};
>/* Using single uint8_t to store 3 values. */
>uint8_t valid :1; /**< Validation flag. */
>uint8_t ext_entry :1; /**< External entry. */
>uint8_t depth :6; /**< Rule depth. */
> };
>
> /** @internal Tbl8 entry structure. */
> struct rte_lpm_tbl8_entry {
>uint8_t next_hop; /**< next hop. */
>/* Using single uint8_t to store 3 values. */
>uint8_t valid   :1; /**< Validation flag. */
>uint8_t valid_group :1; /**< Group validation flag. */
>uint8_t depth   :6; /**< Rule depth. */
> };
> #else
> struct rte_lpm_tbl24_entry {
>uint8_t depth   :6;
>uint8_t ext_entry   :1;
>uint8_t valid   :1;
>union {
>uint8_t tbl8_gindex;
>uint8_t next_hop;
>};
> };
>
> struct rte_lpm_tbl8_entry {
>uint8_t depth   :6;
>uint8_t valid_group :1;
>uint8_t valid   :1;
>uint8_t next_hop;
> };
> 

[dpdk-dev] [PATCH] testpmd: modify the mac of csum forwarding

[De Lara Guarch, Pablo]

HI,

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Saturday, October 24, 2015 5:52 PM
> To: Qiu, Michael
> Cc: dev at dpdk.org; Liu, Jijiang; De Lara Guarch, Pablo
> Subject: Re: [dpdk-dev] [PATCH] testpmd: modify the mac of csum
> forwarding
> 
> 2015-10-13 06:29, Qiu, Michael:
> > Hi, Thomas
> >
> > Any comments on this patch? Is it suitable for DPDK?
> 
> Please check with the testpmd maintainer.
> Pablo?

The patch looks harmless for other NICs, and it does similar stuff as other 
forwarding modes,
so I think it is safe to integrate.

Thanks,
Pablo

[dpdk-dev] how to use multiple RX queues on the same port

[De Lara Guarch, Pablo]

Hi Francesco,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Montorsi,
> Francesco
> Sent: Monday, October 26, 2015 5:23 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] how to use multiple RX queues on the same port
> 
> Hi all,
> To avoid rx_nombuf packet drops, I'm trying to configure a DPDK port to use
> more than 1 RX queue... so I'm trying (on a 10Gbps card) to use 4 RX queues.
> The call to rte_eth_dev_configure() and the 4 calls to
> rte_eth_rx_queue_setup() succeed but then via the
> rte_eth_rx_queue_count() API I see that only the first RX queue is used. The
> remaining 3 seems unused... am I missing something?

How are you configuring the port? Are you using RSS? I guess that's what you 
are looking for,
so make sure that you are using the right mq_mode(ETH_MQ_RX_RSS).
Which NIC are you using and which traffic type? Because if you don't vary the 
traffic, you won't see any traffic in all queues.

Pablo

> 
> 
> Thanks!
> 
> Francesco Montorsi

[dpdk-dev] [PATCH v2] kni: allow per-net instances

[Dex Chen]

There is a global variable 'device_in_use' which is used to make sure
only one instance is using /dev/kni device. If you were using LXC, you
will find there is only one instance of KNI example could be run even
differnt namespaces were created.

In order to have /dev/kni used simultaneously in different namespaces,
making all of global variables as per network namespace variables.

With regard to single kernel thread mode, there will be one kernel
thread for each of network namespace.

v2:
> Remove kni_exit_net
> Revise the order of register/unregister of pernet_subsys
> Fix warnings of checkpatch
> Fix NULL nsproxy issue in kni_release()

Signed-off-by: Dex Chen 
---
 lib/librte_eal/linuxapp/kni/kni_misc.c | 136 +
 1 file changed, 87 insertions(+), 49 deletions(-)

diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c 
b/lib/librte_eal/linuxapp/kni/kni_misc.c
index 2e9fa89..635e18f 100644
--- a/lib/librte_eal/linuxapp/kni/kni_misc.c
+++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
@@ -28,6 +28,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 

 #include 
 #include "kni_dev.h"
@@ -90,18 +93,40 @@ static unsigned multiple_kthread_on = 0;

 #define KNI_DEV_IN_USE_BIT_NUM 0 /* Bit number for device in use */

-static volatile unsigned long device_in_use; /* device in use flag */
-static struct task_struct *kni_kthread;
+static int kni_net_id;

-/* kni list lock */
-static DECLARE_RWSEM(kni_list_lock);
+struct kni_net {
+   unsigned long device_in_use; /* device in use flag */
+   struct task_struct *kni_kthread;
+   struct rw_semaphore kni_list_lock;
+   struct list_head kni_list_head;
+};
+
+static __net_init int kni_init_net(struct net *net)
+{
+   struct kni_net *knet = net_generic(net, kni_net_id);

-/* kni list */
-static struct list_head kni_list_head = LIST_HEAD_INIT(kni_list_head);
+   /* Clear the bit of device in use */
+   clear_bit(KNI_DEV_IN_USE_BIT_NUM, >device_in_use);
+
+   init_rwsem(>kni_list_lock);
+   INIT_LIST_HEAD(>kni_list_head);
+
+   return 0;
+}
+
+static struct pernet_operations kni_net_ops = {
+   .init = kni_init_net,
+   .exit = NULL,
+   .id   = _net_id,
+   .size = sizeof(struct kni_net),
+};

 static int __init
 kni_init(void)
 {
+   int rc;
+
KNI_PRINT(" DPDK kni module loading \n");

if (kni_parse_kthread_mode() < 0) {
@@ -109,13 +134,15 @@ kni_init(void)
return -EINVAL;
}

-   if (misc_register(_misc) != 0) {
-   KNI_ERR("Misc registration failed\n");
+   rc = register_pernet_subsys(_net_ops);
+   if (rc)
return -EPERM;
-   }

-   /* Clear the bit of device in use */
-   clear_bit(KNI_DEV_IN_USE_BIT_NUM, _in_use);
+   rc = misc_register(_misc);
+   if (rc != 0) {
+   KNI_ERR("Misc registration failed\n");
+   goto out;
+   }

/* Configure the lo mode according to the input parameter */
kni_net_config_lo_mode(lo_mode);
@@ -123,12 +150,17 @@ kni_init(void)
KNI_PRINT(" DPDK kni module loaded  \n");

return 0;
+
+out:
+   unregister_pernet_subsys(_net_ops);
+   return rc;
 }

 static void __exit
 kni_exit(void)
 {
misc_deregister(_misc);
+   unregister_pernet_subsys(_net_ops);
KNI_PRINT("### DPDK kni module unloaded  ###\n");
 }

@@ -151,23 +183,27 @@ kni_parse_kthread_mode(void)
 static int
 kni_open(struct inode *inode, struct file *file)
 {
-   /* kni device can be opened by one user only, test and set bit */
-   if (test_and_set_bit(KNI_DEV_IN_USE_BIT_NUM, _in_use))
+   struct net *net = current->nsproxy->net_ns;
+   struct kni_net *knet = net_generic(net, kni_net_id);
+
+   /* kni device can be opened by one user only per netns */
+   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");
/* Create kernel thread for RX */
-   kni_kthread = kthread_run(kni_thread_single, NULL,
+   knet->kni_kthread = kthread_run(kni_thread_single, (void *)knet,
"kni_single");
-   if (IS_ERR(kni_kthread)) {
+   if (IS_ERR(knet->kni_kthread)) {
KNI_ERR("Unable to create kernel threaed\n");
-   return PTR_ERR(kni_kthread);
+   return PTR_ERR(knet->kni_kthread);
}
} else
KNI_PRINT("Multiple kernel thread mode enabled\n");

+   file->private_data = get_net(net);
KNI_PRINT("/dev/kni opened\n");

return 0;
@@ -176,17 +212,19 @@ kni_open(struct inode *inode, struct file *file)
 

[dpdk-dev] [PATCH 0/2] Provide reasonable default to -n

[Thomas Monjalon]

Panu,
Please use --subject-prefix 'PATCH v2' to ease patch management,
as explained here:
http://dpdk.org/dev#send

git send-email --subject-prefix 'PATCH vX+1' --annotate --cover-letter 
--in-reply-to 

It should appear on the cover letter and the patches.

Thanks

[dpdk-dev] [PATCH 0/2] Provide reasonable default to -n

[Thomas Monjalon]

> > The number of memory channels is a truly obscure thing as a mandatory
> > command line argument when its really just an optimization.
> > Provide a reasonable default in mempool as suggested by Bruce Richardson
> > and make the -n argument optional in EAL to make DPDK that little bit
> > easier to use for a first-timer.
> >
> > Panu Matilainen (2):
> >   mempool: use a better default for number of memory channels
> >   eal: make the -n argument optional
> 
> Acked-by: David Marchand 

Applied, thanks

[dpdk-dev] [PATCH 0/2] Provide reasonable default to -n

[Thomas Monjalon]

2015-10-15 13:12, Mcnamara, John:
> From: Panu Matilainen [mailto:pmatilai at redhat.com]
> > Sure. I was planning on going through the docs and updating them
> > (separately) if the change is otherwise accepted, I suspect there are more
> > than those two places needing changes.

Actually the docs about command line are redundant and outdated.
We should try to keep them only in the startup section of the GSG (Linux and 
BSD).

> I counted ~ 100 places in the docs where -n is used. I don't know if they all
> have to be removed. The 2 examples I gave were the only ones that I found,
> in a quick scan, that explicitly say -n is required. The rest are in the
> "mostly harmless" category but if you wanted to remove the majority of the
> references then that is probably okay.

I think we should remove most of them to keep the doc simple and maintainable.

These patches will be applied even if the doc is not updated
because a doc rework is needed.

[dpdk-dev] [PATCH v2 15/16] lpm/arm: implement rte_lpm_lookupx4 using rte_lpm_lookup_bulk on for-x86

[Jan Viktorin]

From: Vlastimil Kosar 

LPM function rte_lpm_lookupx4() uses i686/x86_64 SIMD intrinsics. Therefore,
the function is reimplemented using non-vector operations for non-x86
architectures. In the future, each architecture should have vectorized code.
This patch includes rudimentary emulation of intrinsic functions 
_mm_set_epi32(),
_mm_loadu_si128() and _mm_load_si128() for easy portability of existing
applications.

LPM builds now when on ARM.

FIXME: to be reworked

Signed-off-by: Vlastimil Kosar 
Signed-off-by: Jan Viktorin 
---
 config/defconfig_arm-armv7-a-linuxapp-gcc |  1 -
 lib/librte_lpm/rte_lpm.h  | 71 +++
 2 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/config/defconfig_arm-armv7-a-linuxapp-gcc 
b/config/defconfig_arm-armv7-a-linuxapp-gcc
index 5b582a8..33afb33 100644
--- a/config/defconfig_arm-armv7-a-linuxapp-gcc
+++ b/config/defconfig_arm-armv7-a-linuxapp-gcc
@@ -58,7 +58,6 @@ CONFIG_XMM_SIZE=16

 # fails to compile on ARM
 CONFIG_RTE_LIBRTE_ACL=n
-CONFIG_RTE_LIBRTE_LPM=n

 # cannot use those on ARM
 CONFIG_RTE_KNI_KMOD=n
diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
index c299ce2..4619992 100644
--- a/lib/librte_lpm/rte_lpm.h
+++ b/lib/librte_lpm/rte_lpm.h
@@ -47,7 +47,9 @@
 #include 
 #include 
 #include 
+#if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
 #include 
+#endif

 #ifdef __cplusplus
 extern "C" {
@@ -358,6 +360,7 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const 
uint32_t * ips,
return 0;
 }

+#if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
 /* Mask four results. */
 #define RTE_LPM_MASKX4_RES UINT64_C(0x00ff00ff00ff00ff)

@@ -472,6 +475,74 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, 
uint16_t hop[4],
hop[2] = (tbl[2] & RTE_LPM_LOOKUP_SUCCESS) ? (uint8_t)tbl[2] : defv;
hop[3] = (tbl[3] & RTE_LPM_LOOKUP_SUCCESS) ? (uint8_t)tbl[3] : defv;
 }
+#else
+// TODO: this code should be reworked.
+
+typedef struct {
+   union uint128 {
+   uint8_t uint8[16];
+   uint32_t uint32[4];
+   } val;
+} __m128i;
+
+static inline __m128i
+_mm_set_epi32(uint32_t v0, uint32_t v1, uint32_t v2, uint32_t v3)
+{
+   __m128i res;
+   res.val.uint32[0] = v0;
+   res.val.uint32[1] = v1;
+   res.val.uint32[2] = v2;
+   res.val.uint32[3] = v3;
+   return res;
+}
+
+static inline __m128i
+_mm_loadu_si128(__m128i * v)
+{
+   __m128i res;
+   res = *v;
+   return res;
+}
+
+static inline __m128i
+_mm_load_si128(__m128i * v)
+{
+   __m128i res;
+   res = *v;
+   return res;
+}
+
+/**
+ * Lookup four IP addresses in an LPM table.
+ *
+ * @param lpm
+ *   LPM object handle
+ * @param ip
+ *   Four IPs to be looked up in the LPM table
+ * @param hop
+ *   Next hop of the most specific rule found for IP (valid on lookup hit 
only).
+ *   This is an 4 elements array of two byte values.
+ *   If the lookup was succesfull for the given IP, then least significant byte
+ *   of the corresponding element is the  actual next hop and the most
+ *   significant byte is zero.
+ *   If the lookup for the given IP failed, then corresponding element would
+ *   contain default value, see description of then next parameter.
+ * @param defv
+ *   Default value to populate into corresponding element of hop[] array,
+ *   if lookup would fail.
+ */
+static inline void
+rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, uint16_t hop[4],
+   uint16_t defv)
+{
+   rte_lpm_lookup_bulk(lpm, ip.val.uint32, hop, 4);
+
+   hop[0] = (hop[0] & RTE_LPM_LOOKUP_SUCCESS) ? (uint8_t)hop[0] : defv;
+   hop[1] = (hop[1] & RTE_LPM_LOOKUP_SUCCESS) ? (uint8_t)hop[1] : defv;
+   hop[2] = (hop[2] & RTE_LPM_LOOKUP_SUCCESS) ? (uint8_t)hop[2] : defv;
+   hop[3] = (hop[3] & RTE_LPM_LOOKUP_SUCCESS) ? (uint8_t)hop[3] : defv;
+}
+#endif

 #ifdef __cplusplus
 }
-- 
2.6.1

[dpdk-dev] [PATCH v2 14/16] maintainers: claim responsibility for ARMv7

[Jan Viktorin]

Signed-off-by: Jan Viktorin 
---
 MAINTAINERS | 4 
 1 file changed, 4 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 080a8e8..a8933eb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -124,6 +124,10 @@ IBM POWER
 M: Chao Zhu 
 F: lib/librte_eal/common/include/arch/ppc_64/

+ARM v7
+M: Jan Viktorin 
+F: lib/librte_eal/common/include/arch/arm/
+
 Intel x86
 M: Bruce Richardson 
 M: Konstantin Ananyev 
-- 
2.6.1

[dpdk-dev] [PATCH v2 11/16] eal/arm: detect arm architecture in cpu flags

[Jan Viktorin]

Based on the patch by David Hunt and Armuta Zende:

  lib: added support for armv7 architecture

Signed-off-by: Jan Viktorin 
Signed-off-by: Amruta Zende 
Signed-off-by: David Hunt 
---
 lib/librte_eal/common/include/arch/arm/rte_cpuflags.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/lib/librte_eal/common/include/arch/arm/rte_cpuflags.h 
b/lib/librte_eal/common/include/arch/arm/rte_cpuflags.h
index 1eadb33..17e13fc 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_cpuflags.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_cpuflags.h
@@ -52,10 +52,15 @@ extern "C" {
 #define AT_HWCAP2 26
 #endif

+#ifndef AT_PLATFORM
+#define AT_PLATFORM 15
+#endif
+
 /* software based registers */
 enum cpu_register_t {
REG_HWCAP = 0,
REG_HWCAP2,
+   REG_PLATFORM,
 };

 /**
@@ -89,6 +94,8 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_SHA1,
RTE_CPUFLAG_SHA2,
RTE_CPUFLAG_CRC32,
+   RTE_CPUFLAG_AARCH32,
+   RTE_CPUFLAG_AARCH64,
/* The last item */
RTE_CPUFLAG_NUMFLAGS,/**< This should always be the last! */
 };
@@ -121,6 +128,8 @@ static const struct feature_entry cpu_feature_table[] = {
FEAT_DEF(SHA1,  0x0001, 0, REG_HWCAP2,  2)
FEAT_DEF(SHA2,  0x0001, 0, REG_HWCAP2,  3)
FEAT_DEF(CRC32, 0x0001, 0, REG_HWCAP2,  4)
+   FEAT_DEF(AARCH32,   0x0001, 0, REG_PLATFORM, 0)
+   FEAT_DEF(AARCH64,   0x0001, 0, REG_PLATFORM, 1)
 };

 /*
@@ -141,6 +150,12 @@ rte_cpu_get_features(__attribute__((unused)) uint32_t leaf,
out[REG_HWCAP] = auxv.a_un.a_val;
else if (auxv.a_type == AT_HWCAP2)
out[REG_HWCAP2] = auxv.a_un.a_val;
+   else if (auxv.a_type == AT_PLATFORM) {
+   if (!strcmp((const char *)auxv.a_un.a_val, "aarch32"))
+   out[REG_PLATFORM] = 0x0001;
+   else if (!strcmp((const char *)auxv.a_un.a_val, 
"aarch64"))
+   out[REG_PLATFORM] = 0x0002;
+   }
}
 }

-- 
2.6.1

[dpdk-dev] [PATCH v2 10/16] eal/arm: cpu flag checks for ARM

[Jan Viktorin]

From: Vlastimil Kosar 

This implementation is based on IBM POWER version of
rte_cpuflags. We use software emulation of HW capability
registers, because those are usually not directly accessible
from userspace on ARM.

Signed-off-by: Vlastimil Kosar 
Signed-off-by: Jan Viktorin 
---
v1 -> v2: check whether AT_HWCAP and AT_HWCAP2 exists
---
 app/test/test_cpuflags.c   |   5 +
 .../common/include/arch/arm/rte_cpuflags.h | 177 +
 mk/rte.cpuflags.mk |   6 +
 3 files changed, 188 insertions(+)
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_cpuflags.h

diff --git a/app/test/test_cpuflags.c b/app/test/test_cpuflags.c
index 5b92061..557458f 100644
--- a/app/test/test_cpuflags.c
+++ b/app/test/test_cpuflags.c
@@ -115,6 +115,11 @@ test_cpuflags(void)
CHECK_FOR_FLAG(RTE_CPUFLAG_ICACHE_SNOOP);
 #endif

+#if defined(RTE_ARCH_ARM)
+   printf("Check for NEON:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_NEON);
+#endif
+
 #if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
printf("Check for SSE:\t\t");
CHECK_FOR_FLAG(RTE_CPUFLAG_SSE);
diff --git a/lib/librte_eal/common/include/arch/arm/rte_cpuflags.h 
b/lib/librte_eal/common/include/arch/arm/rte_cpuflags.h
new file mode 100644
index 000..1eadb33
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/arm/rte_cpuflags.h
@@ -0,0 +1,177 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2015 RehiveTech. All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of RehiveTech nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_CPUFLAGS_ARM_H_
+#define _RTE_CPUFLAGS_ARM_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+#include 
+#include 
+#include 
+
+#include "generic/rte_cpuflags.h"
+
+#ifndef AT_HWCAP
+#define AT_HWCAP 16
+#endif
+
+#ifndef AT_HWCAP2
+#define AT_HWCAP2 26
+#endif
+
+/* software based registers */
+enum cpu_register_t {
+   REG_HWCAP = 0,
+   REG_HWCAP2,
+};
+
+/**
+ * Enumeration of all CPU features supported
+ */
+enum rte_cpu_flag_t {
+   RTE_CPUFLAG_SWP = 0,
+   RTE_CPUFLAG_HALF,
+   RTE_CPUFLAG_THUMB,
+   RTE_CPUFLAG_A26BIT,
+   RTE_CPUFLAG_FAST_MULT,
+   RTE_CPUFLAG_FPA,
+   RTE_CPUFLAG_VFP,
+   RTE_CPUFLAG_EDSP,
+   RTE_CPUFLAG_JAVA,
+   RTE_CPUFLAG_IWMMXT,
+   RTE_CPUFLAG_CRUNCH,
+   RTE_CPUFLAG_THUMBEE,
+   RTE_CPUFLAG_NEON,
+   RTE_CPUFLAG_VFPv3,
+   RTE_CPUFLAG_VFPv3D16,
+   RTE_CPUFLAG_TLS,
+   RTE_CPUFLAG_VFPv4,
+   RTE_CPUFLAG_IDIVA,
+   RTE_CPUFLAG_IDIVT,
+   RTE_CPUFLAG_VFPD32,
+   RTE_CPUFLAG_LPAE,
+   RTE_CPUFLAG_EVTSTRM,
+   RTE_CPUFLAG_AES,
+   RTE_CPUFLAG_PMULL,
+   RTE_CPUFLAG_SHA1,
+   RTE_CPUFLAG_SHA2,
+   RTE_CPUFLAG_CRC32,
+   /* The last item */
+   RTE_CPUFLAG_NUMFLAGS,/**< This should always be the last! */
+};
+
+static const struct feature_entry cpu_feature_table[] = {
+   FEAT_DEF(SWP,   0x0001, 0, REG_HWCAP,  0)
+   FEAT_DEF(HALF,  0x0001, 0, REG_HWCAP,  1)
+   FEAT_DEF(THUMB, 0x0001, 0, REG_HWCAP,  2)
+   FEAT_DEF(A26BIT,0x0001, 0, REG_HWCAP,  3)
+   FEAT_DEF(FAST_MULT, 0x0001, 0, REG_HWCAP,  4)
+   FEAT_DEF(FPA,   0x0001, 0, REG_HWCAP,  5)
+   FEAT_DEF(VFP,   0x0001, 0, REG_HWCAP,  6)
+   FEAT_DEF(EDSP,  0x0001, 0, REG_HWCAP,  7)
+   FEAT_DEF(JAVA,  0x0001, 0, 

[dpdk-dev] [PATCH v2 09/16] eal/arm: use vector memcpy only when NEON is enabled

[Jan Viktorin]

The GCC can be configured to avoid using NEON extensions.
For that purpose, we provide just the memcpy implementation
of the rte_memcpy.

Based on the patch by David Hunt and Armuta Zende:

  lib: added support for armv7 architecture

Signed-off-by: Jan Viktorin 
Signed-off-by: Amruta Zende 
Signed-off-by: David Hunt 
---
 .../common/include/arch/arm/rte_memcpy.h   | 59 +-
 1 file changed, 57 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/common/include/arch/arm/rte_memcpy.h 
b/lib/librte_eal/common/include/arch/arm/rte_memcpy.h
index ac885e9..75e8bda 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_memcpy.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_memcpy.h
@@ -35,8 +35,6 @@

 #include 
 #include 
-/* ARM NEON Intrinsics are used to copy data */
-#include 

 #ifdef __cplusplus
 extern "C" {
@@ -44,6 +42,11 @@ extern "C" {

 #include "generic/rte_memcpy.h"

+#ifdef __ARM_NEON_FP
+
+/* ARM NEON Intrinsics are used to copy data */
+#include 
+
 static inline void
 rte_mov16(uint8_t *dst, const uint8_t *src)
 {
@@ -263,6 +266,58 @@ rte_memcpy_func(void *dst, const void *src, size_t n)
return ret;
 }

+#else
+
+static inline void
+rte_mov16(uint8_t *dst, const uint8_t *src)
+{
+   memcpy(dst, src, 16);
+}
+
+static inline void
+rte_mov32(uint8_t *dst, const uint8_t *src)
+{
+   memcpy(dst, src, 32);
+}
+
+static inline void
+rte_mov48(uint8_t *dst, const uint8_t *src)
+{
+   memcpy(dst, src, 48);
+}
+
+static inline void
+rte_mov64(uint8_t *dst, const uint8_t *src)
+{
+   memcpy(dst, src, 64);
+}
+
+static inline void
+rte_mov128(uint8_t *dst, const uint8_t *src)
+{
+   memcpy(dst, src, 128);
+}
+
+static inline void
+rte_mov256(uint8_t *dst, const uint8_t *src)
+{
+   memcpy(dst, src, 256);
+}
+
+static inline void *
+rte_memcpy(void *dst, const void *src, size_t n)
+{
+   return memcpy(dst, src, n);
+}
+
+static inline void *
+rte_memcpy_func(void *dst, const void *src, size_t n)
+{
+   return memcpy(dst, src, n);
+}
+
+#endif /* __ARM_NEON_FP */
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.6.1

[dpdk-dev] [PATCH v2 08/16] eal/arm: vector memcpy for ARM

[Jan Viktorin]

From: Vlastimil Kosar 

The SSE based memory copy in DPDK only support x86. This patch
adds ARM NEON based memory copy functions for ARM architecture.

The implementation improves memory copy of short or well aligned
data buffers. The following measurements show improvements over
the libc memcpy on Cortex CPUs.

   by X % faster
Length (B)   a15a7 a9
   1 4.9  15.23.2
   756.9  48.2   40.3
   837.3  39.8   29.6
   969.3  38.7   33.9
  1560.8  35.3   23.7
  1650.6  35.9   35.0
  1757.7  35.7   31.1
  3116.0  23.39.0
  3265.9  13.5   21.4
  33 3.9  10.3   -3.7
  63 2.0  12.9   -2.0
  6466.5   0.0   16.5
  65 2.7   7.6  -35.6
 127 0.1   4.5  -18.9
 12866.2   1.5  -51.4
 129-0.8   3.2  -35.8
 255-3.1  -0.9  -69.1
 25667.9   1.27.2
 257-3.6  -1.9  -36.9
 32067.7   1.40.0
 38466.8   1.4  -14.2
 511   -44.9  -2.3  -41.9
 51267.3   1.4   -6.8
 513   -41.7  -3.0  -36.2
1023   -82.4  -2.8  -41.2
102468.3   1.4  -11.6
1025   -80.1  -3.3  -38.1
1518   -47.3  -5.0  -38.3
1522   -48.3  -6.0  -37.9
160065.4   1.3  -27.3
204859.5   1.5  -10.9
307252.3   1.5  -12.2
409645.3   1.4  -12.5
512040.6   1.5  -14.5
614435.4   1.4  -13.4
716832.9   1.4  -13.9
819228.2   1.4  -15.1

Signed-off-by: Vlastimil Kosar 
Signed-off-by: Jan Viktorin 
---
 .../common/include/arch/arm/rte_memcpy.h   | 270 +
 1 file changed, 270 insertions(+)
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_memcpy.h

diff --git a/lib/librte_eal/common/include/arch/arm/rte_memcpy.h 
b/lib/librte_eal/common/include/arch/arm/rte_memcpy.h
new file mode 100644
index 000..ac885e9
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/arm/rte_memcpy.h
@@ -0,0 +1,270 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2015 RehiveTech. All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of RehiveTech nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_MEMCPY_ARM_H_
+#define _RTE_MEMCPY_ARM_H_
+
+#include 
+#include 
+/* ARM NEON Intrinsics are used to copy data */
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include "generic/rte_memcpy.h"
+
+static inline void
+rte_mov16(uint8_t *dst, const uint8_t *src)
+{
+   vst1q_u8(dst, vld1q_u8(src));
+}
+
+static inline void
+rte_mov32(uint8_t *dst, const uint8_t *src)
+{
+   asm volatile ("vld1.8 {d0-d3}, [%[src]]\n\t"
+ "vst1.8 {d0-d3}, [%[dst]]\n\t"
+ : [src] "+r" (src), [dst] "+r" (dst)
+ : : "memory", "d0", "d1", "d2", "d3");
+}
+
+static inline void
+rte_mov48(uint8_t *dst, const uint8_t *src)
+{
+   asm volatile ("vld1.8 {d0-d3}, [%[src]]!\n\t"
+ "vld1.8 {d4-d5}, [%[src]]\n\t"
+ "vst1.8 {d0-d3}, [%[dst]]!\n\t"
+ "vst1.8 {d4-d5}, [%[dst]]\n\t"
+ : [src] "+r" (src), [dst] "+r" (dst)
+ : : "memory", "d0", "d1", "d2", "d3", "d4", "d5");
+}
+
+static inline void
+rte_mov64(uint8_t *dst, const uint8_t *src)
+{
+   asm volatile ("vld1.8 {d0-d3}, [%[src]]!\n\t"
+ "vld1.8 {d4-d7}, [%[src]]\n\t"
+ "vst1.8 {d0-d3}, [%[dst]]!\n\t"
+ 

[dpdk-dev] [PATCH v2 07/16] eal/arm: spinlock operations for ARM (without HTM)

[Jan Viktorin]

From: Vlastimil Kosar 

This patch adds spinlock operations for ARM architecture.
We do not support HTM in spinlocks on ARM.

Signed-off-by: Vlastimil Kosar 
Signed-off-by: Jan Viktorin 
---
 .../common/include/arch/arm/rte_spinlock.h | 114 +
 1 file changed, 114 insertions(+)
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_spinlock.h

diff --git a/lib/librte_eal/common/include/arch/arm/rte_spinlock.h 
b/lib/librte_eal/common/include/arch/arm/rte_spinlock.h
new file mode 100644
index 000..cd5ab8b
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/arm/rte_spinlock.h
@@ -0,0 +1,114 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2015 RehiveTech. All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of RehiveTech nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_SPINLOCK_ARM_H_
+#define _RTE_SPINLOCK_ARM_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+#include "generic/rte_spinlock.h"
+
+/* Intrinsics are used to implement the spinlock on ARM architecture */
+
+#ifndef RTE_FORCE_INTRINSICS
+
+static inline void
+rte_spinlock_lock(rte_spinlock_t *sl)
+{
+   while (__sync_lock_test_and_set(>locked, 1))
+   while (sl->locked)
+   rte_pause();
+}
+
+static inline void
+rte_spinlock_unlock(rte_spinlock_t *sl)
+{
+   __sync_lock_release(>locked);
+}
+
+static inline int
+rte_spinlock_trylock(rte_spinlock_t *sl)
+{
+   return (__sync_lock_test_and_set(>locked, 1) == 0);
+}
+
+#endif
+
+static inline int rte_tm_supported(void)
+{
+   return 0;
+}
+
+static inline void
+rte_spinlock_lock_tm(rte_spinlock_t *sl)
+{
+   rte_spinlock_lock(sl); /* fall-back */
+}
+
+static inline int
+rte_spinlock_trylock_tm(rte_spinlock_t *sl)
+{
+   return rte_spinlock_trylock(sl);
+}
+
+static inline void
+rte_spinlock_unlock_tm(rte_spinlock_t *sl)
+{
+   rte_spinlock_unlock(sl);
+}
+
+static inline void
+rte_spinlock_recursive_lock_tm(rte_spinlock_recursive_t *slr)
+{
+   rte_spinlock_recursive_lock(slr); /* fall-back */
+}
+
+static inline void
+rte_spinlock_recursive_unlock_tm(rte_spinlock_recursive_t *slr)
+{
+   rte_spinlock_recursive_unlock(slr);
+}
+
+static inline int
+rte_spinlock_recursive_trylock_tm(rte_spinlock_recursive_t *slr)
+{
+   return rte_spinlock_recursive_trylock(slr);
+}
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_SPINLOCK_ARM_H_ */
-- 
2.6.1

[dpdk-dev] [PATCH v2 05/16] eal/arm: implement rdtsc by PMU or clock_gettime

[Jan Viktorin]

Enable to choose a preferred way to read timer based on the
configuration entry CONFIG_RTE_ARM_EAL_RDTSC_USE_PMU.
It requires a kernel module that is not included to work.

Based on the patch by David Hunt and Armuta Zende:

  lib: added support for armv7 architecture

Signed-off-by: Jan Viktorin 
Signed-off-by: Amruta Zende 
Signed-off-by: David Hunt 
---
 .../common/include/arch/arm/rte_cycles.h   | 38 +-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/lib/librte_eal/common/include/arch/arm/rte_cycles.h 
b/lib/librte_eal/common/include/arch/arm/rte_cycles.h
index ff66ae2..5dcef25 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_cycles.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_cycles.h
@@ -54,8 +54,14 @@ extern "C" {
  * @return
  *   The time base for this lcore.
  */
+#ifndef CONFIG_RTE_ARM_EAL_RDTSC_USE_PMU
+
+/**
+ * This call is easily portable to any ARM architecture, however,
+ * it may be damn slow and inprecise for some tasks.
+ */
 static inline uint64_t
-rte_rdtsc(void)
+__rte_rdtsc_syscall(void)
 {
struct timespec val;
uint64_t v;
@@ -67,6 +73,36 @@ rte_rdtsc(void)
v += (uint64_t) val.tv_nsec;
return v;
 }
+#define rte_rdtsc __rte_rdtsc_syscall
+
+#else
+
+/**
+ * This function requires to configure the PMCCNTR and enable
+ * userspace access to it:
+ *
+ *  asm volatile("mcr p15, 0, %0, c9, c14, 0" : : "r"(1));
+ *  asm volatile("mcr p15, 0, %0, c9, c12, 0" : : "r"(29));
+ *  asm volatile("mcr p15, 0, %0, c9, c12, 1" : : "r"(0x800f));
+ *
+ * which is possible only from the priviledged mode (kernel space).
+ */
+static inline uint64_t
+__rte_rdtsc_pmccntr(void)
+{
+   unsigned tsc;
+   uint64_t final_tsc;
+
+   /* Read PMCCNTR */
+   asm volatile("mrc p15, 0, %0, c9, c13, 0" : "=r"(tsc));
+   /* 1 tick = 64 clocks */
+   final_tsc = ((uint64_t)tsc) << 6;
+
+   return (uint64_t)final_tsc;
+}
+#define rte_rdtsc __rte_rdtsc_pmccntr
+
+#endif /* RTE_ARM_EAL_RDTSC_USE_PMU */

 static inline uint64_t
 rte_rdtsc_precise(void)
-- 
2.6.1

[dpdk-dev] [PATCH v2 04/16] eal/arm: cpu cycle operations for ARM

[Jan Viktorin]

From: Vlastimil Kosar 

ARM architecture doesn't have a suitable source of CPU cycles. This
patch uses clock_gettime instead. The implementation should be improved
in the future.

Signed-off-by: Vlastimil Kosar 
Signed-off-by: Jan Viktorin 
---
 .../common/include/arch/arm/rte_cycles.h   | 85 ++
 1 file changed, 85 insertions(+)
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_cycles.h

diff --git a/lib/librte_eal/common/include/arch/arm/rte_cycles.h 
b/lib/librte_eal/common/include/arch/arm/rte_cycles.h
new file mode 100644
index 000..ff66ae2
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/arm/rte_cycles.h
@@ -0,0 +1,85 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2015 RehiveTech. All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of RehiveTech nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_CYCLES_ARM_H_
+#define _RTE_CYCLES_ARM_H_
+
+/* ARM v7 does not have suitable source of clock signals. The only clock 
counter
+   available in the core is 32 bit wide. Therefore it is unsuitable as the
+   counter overlaps every few seconds and probably is not accessible by
+   userspace programs. Therefore we use clock_gettime(CLOCK_MONOTONIC_RAW) to
+   simulate counter running at 1GHz.
+*/
+
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include "generic/rte_cycles.h"
+
+/**
+ * Read the time base register.
+ *
+ * @return
+ *   The time base for this lcore.
+ */
+static inline uint64_t
+rte_rdtsc(void)
+{
+   struct timespec val;
+   uint64_t v;
+
+   while (clock_gettime(CLOCK_MONOTONIC_RAW, ) != 0)
+   /* no body */;
+
+   v  = (uint64_t) val.tv_sec * 10LL;
+   v += (uint64_t) val.tv_nsec;
+   return v;
+}
+
+static inline uint64_t
+rte_rdtsc_precise(void)
+{
+   rte_mb();
+   return rte_rdtsc();
+}
+
+static inline uint64_t
+rte_get_tsc_cycles(void) { return rte_rdtsc(); }
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_CYCLES_ARM_H_ */
-- 
2.6.1

[dpdk-dev] [PATCH v2 03/16] eal/arm: byte order operations for ARM

[Jan Viktorin]

From: Vlastimil Kosar 

This patch adds architecture specific byte order operations
for ARM. The architecture supports both big and little endian.

Signed-off-by: Vlastimil Kosar 
Signed-off-by: Jan Viktorin 
---
 .../common/include/arch/arm/rte_byteorder.h| 148 +
 1 file changed, 148 insertions(+)
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_byteorder.h

diff --git a/lib/librte_eal/common/include/arch/arm/rte_byteorder.h 
b/lib/librte_eal/common/include/arch/arm/rte_byteorder.h
new file mode 100644
index 000..04e7b87
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/arm/rte_byteorder.h
@@ -0,0 +1,148 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2015 RehiveTech. All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of RehiveTech nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_BYTEORDER_ARM_H_
+#define _RTE_BYTEORDER_ARM_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include "generic/rte_byteorder.h"
+
+/*
+ * An architecture-optimized byte swap for a 16-bit value.
+ *
+ * Do not use this function directly. The preferred function is rte_bswap16().
+ */
+static inline uint16_t rte_arch_bswap16(uint16_t _x)
+{
+   register uint16_t x = _x;
+   asm volatile ("rev16 %[x1],%[x2]"
+ : [x1] "=r" (x)
+ : [x2] "r" (x)
+ );
+   return x;
+}
+
+/*
+ * An architecture-optimized byte swap for a 32-bit value.
+ *
+ * Do not use this function directly. The preferred function is rte_bswap32().
+ */
+static inline uint32_t rte_arch_bswap32(uint32_t _x)
+{
+   register uint32_t x = _x;
+   asm volatile ("rev %[x1],%[x2]"
+ : [x1] "=r" (x)
+ : [x2] "r" (x)
+ );
+   return x;
+}
+
+/*
+ * An architecture-optimized byte swap for a 64-bit value.
+ *
+  * Do not use this function directly. The preferred function is rte_bswap64().
+ */
+/* 64-bit mode */
+static inline uint64_t rte_arch_bswap64(uint64_t _x)
+{
+   return  __builtin_bswap64(_x);
+}
+
+#ifndef RTE_FORCE_INTRINSICS
+#define rte_bswap16(x) ((uint16_t)(__builtin_constant_p(x) ?   \
+  rte_constant_bswap16(x) :\
+  rte_arch_bswap16(x)))
+
+#define rte_bswap32(x) ((uint32_t)(__builtin_constant_p(x) ?   \
+  rte_constant_bswap32(x) :\
+  rte_arch_bswap32(x)))
+
+#define rte_bswap64(x) ((uint64_t)(__builtin_constant_p(x) ?   \
+  rte_constant_bswap64(x) :\
+  rte_arch_bswap64(x)))
+#else
+/*
+ * __builtin_bswap16 is only available gcc 4.8 and upwards
+ */
+#if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 8)
+#define rte_bswap16(x) ((uint16_t)(__builtin_constant_p(x) ?   \
+  rte_constant_bswap16(x) :\
+  rte_arch_bswap16(x)))
+#endif
+#endif
+
+/* ARM architecture is bi-endian (both big and little). */
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+
+#define rte_cpu_to_le_16(x) (x)
+#define rte_cpu_to_le_32(x) (x)
+#define rte_cpu_to_le_64(x) (x)
+
+#define rte_cpu_to_be_16(x) rte_bswap16(x)
+#define rte_cpu_to_be_32(x) rte_bswap32(x)
+#define rte_cpu_to_be_64(x) rte_bswap64(x)
+
+#define rte_le_to_cpu_16(x) (x)
+#define 

[dpdk-dev] [PATCH v2 02/16] eal/arm: atomic operations for ARM

[Jan Viktorin]

From: Vlastimil Kosar 

This patch adds architecture specific atomic operation file
for ARM architecture. It utilizes compiler intrinsics only.

Signed-off-by: Vlastimil Kosar 
Signed-off-by: Jan Viktorin 
---
v1 -> v2:
* improve rte_wmb()
* use __atomic_* or __sync_*? (may affect the required GCC version)

Signed-off-by: Jan Viktorin 
---
 .../common/include/arch/arm/rte_atomic.h   | 256 +
 1 file changed, 256 insertions(+)
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_atomic.h

diff --git a/lib/librte_eal/common/include/arch/arm/rte_atomic.h 
b/lib/librte_eal/common/include/arch/arm/rte_atomic.h
new file mode 100644
index 000..1815766
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/arm/rte_atomic.h
@@ -0,0 +1,256 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2015 RehiveTech. All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of RehiveTech nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_ATOMIC_ARM_H_
+#define _RTE_ATOMIC_ARM_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include "generic/rte_atomic.h"
+
+/**
+ * General memory barrier.
+ *
+ * Guarantees that the LOAD and STORE operations generated before the
+ * barrier occur before the LOAD and STORE operations generated after.
+ */
+#definerte_mb()  __sync_synchronize()
+
+/**
+ * Write memory barrier.
+ *
+ * Guarantees that the STORE operations generated before the barrier
+ * occur before the STORE operations generated after.
+ */
+#definerte_wmb() do { asm volatile ("dmb st" : : : "memory"); } 
while(0)
+
+/**
+ * Read memory barrier.
+ *
+ * Guarantees that the LOAD operations generated before the barrier
+ * occur before the LOAD operations generated after.
+ */
+#definerte_rmb() __sync_synchronize()
+
+/*- 16 bit atomic operations 
-*/
+
+#ifndef RTE_FORCE_INTRINSICS
+static inline int
+rte_atomic16_cmpset(volatile uint16_t *dst, uint16_t exp, uint16_t src)
+{
+   return __atomic_compare_exchange(dst, , , 0, __ATOMIC_ACQUIRE,
+   __ATOMIC_ACQUIRE) ? 1 : 0;
+}
+
+static inline int rte_atomic16_test_and_set(rte_atomic16_t *v)
+{
+   return rte_atomic16_cmpset((volatile uint16_t *)>cnt, 0, 1);
+}
+
+static inline void
+rte_atomic16_inc(rte_atomic16_t *v)
+{
+   __atomic_add_fetch(>cnt, 1, __ATOMIC_ACQUIRE);
+}
+
+static inline void
+rte_atomic16_dec(rte_atomic16_t *v)
+{
+   __atomic_sub_fetch(>cnt, 1, __ATOMIC_ACQUIRE);
+}
+
+static inline int rte_atomic16_inc_and_test(rte_atomic16_t *v)
+{
+   return (__atomic_add_fetch(>cnt, 1, __ATOMIC_ACQUIRE) == 0);
+}
+
+static inline int rte_atomic16_dec_and_test(rte_atomic16_t *v)
+{
+   return (__atomic_sub_fetch(>cnt, 1, __ATOMIC_ACQUIRE) == 0);
+}
+
+/*- 32 bit atomic operations 
-*/
+
+static inline int
+rte_atomic32_cmpset(volatile uint32_t *dst, uint32_t exp, uint32_t src)
+{
+   return __atomic_compare_exchange(dst, , , 0, __ATOMIC_ACQUIRE,
+   __ATOMIC_ACQUIRE) ? 1 : 0;
+}
+
+static inline int rte_atomic32_test_and_set(rte_atomic32_t *v)
+{
+   return rte_atomic32_cmpset((volatile uint32_t *)>cnt, 0, 1);
+}
+
+static inline void
+rte_atomic32_inc(rte_atomic32_t *v)
+{
+   __atomic_add_fetch(>cnt, 1, __ATOMIC_ACQUIRE);
+}
+
+static inline void
+rte_atomic32_dec(rte_atomic32_t *v)
+{
+   __atomic_sub_fetch(>cnt, 1, __ATOMIC_ACQUIRE);
+}
+
+static 

[dpdk-dev] [PATCH v2 01/16] mk: Introduce ARMv7 architecture

[Jan Viktorin]

From: Vlastimil Kosar 

Make DPDK run on ARMv7-A architecture. This patch assumes
ARM Cortex-A9. However, it is known to be working on Cortex-A7
and Cortex-A15.

Signed-off-by: Vlastimil Kosar 
Signed-off-by: Jan Viktorin 
---
v1 -> v2:
* the -mtune parameter of GCC is configurable now
* the -mfpu=neon can be turned off

Signed-off-by: Jan Viktorin 
---
 config/defconfig_arm-armv7-a-linuxapp-gcc | 78 +++
 mk/arch/arm/rte.vars.mk   | 39 
 mk/machine/armv7-a/rte.vars.mk| 67 ++
 3 files changed, 184 insertions(+)
 create mode 100644 config/defconfig_arm-armv7-a-linuxapp-gcc
 create mode 100644 mk/arch/arm/rte.vars.mk
 create mode 100644 mk/machine/armv7-a/rte.vars.mk

diff --git a/config/defconfig_arm-armv7-a-linuxapp-gcc 
b/config/defconfig_arm-armv7-a-linuxapp-gcc
new file mode 100644
index 000..5b582a8
--- /dev/null
+++ b/config/defconfig_arm-armv7-a-linuxapp-gcc
@@ -0,0 +1,78 @@
+#   BSD LICENSE
+#
+#   Copyright (C) 2015 RehiveTech. All right reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of RehiveTech nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+#include "common_linuxapp"
+
+CONFIG_RTE_MACHINE="armv7-a"
+
+CONFIG_RTE_ARCH="arm"
+CONFIG_RTE_ARCH_ARM=y
+CONFIG_RTE_ARCH_ARMv7=y
+CONFIG_RTE_ARCH_ARM_TUNE="cortex-a9"
+CONFIG_RTE_ARCH_ARM_NEON=y
+
+CONFIG_RTE_TOOLCHAIN="gcc"
+CONFIG_RTE_TOOLCHAIN_GCC=y
+
+# ARM doesn't have support for vmware TSC map
+CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=n
+
+# avoids using i686/x86_64 SIMD instructions, nothing for ARM
+CONFIG_RTE_BITMAP_OPTIMIZATIONS=0
+
+# KNI is not supported on 32-bit
+CONFIG_RTE_LIBRTE_KNI=n
+
+# PCI is usually not used on ARM
+CONFIG_RTE_EAL_IGB_UIO=n
+
+# missing rte_vect.h for ARM
+CONFIG_XMM_SIZE=16
+
+# fails to compile on ARM
+CONFIG_RTE_LIBRTE_ACL=n
+CONFIG_RTE_LIBRTE_LPM=n
+
+# cannot use those on ARM
+CONFIG_RTE_KNI_KMOD=n
+CONFIG_RTE_LIBRTE_EM_PMD=n
+CONFIG_RTE_LIBRTE_IGB_PMD=n
+CONFIG_RTE_LIBRTE_CXGBE_PMD=n
+CONFIG_RTE_LIBRTE_E1000_PMD=n
+CONFIG_RTE_LIBRTE_ENIC_PMD=n
+CONFIG_RTE_LIBRTE_FM10K_PMD=n
+CONFIG_RTE_LIBRTE_I40E_PMD=n
+CONFIG_RTE_LIBRTE_IXGBE_PMD=n
+CONFIG_RTE_LIBRTE_MLX4_PMD=n
+CONFIG_RTE_LIBRTE_MPIPE_PMD=n
+CONFIG_RTE_LIBRTE_VIRTIO_PMD=n
+CONFIG_RTE_LIBRTE_VMXNET3_PMD=n
+CONFIG_RTE_LIBRTE_PMD_XENVIRT=n
+CONFIG_RTE_LIBRTE_PMD_BNX2X=n
diff --git a/mk/arch/arm/rte.vars.mk b/mk/arch/arm/rte.vars.mk
new file mode 100644
index 000..df0c043
--- /dev/null
+++ b/mk/arch/arm/rte.vars.mk
@@ -0,0 +1,39 @@
+#   BSD LICENSE
+#
+#   Copyright (C) 2015 RehiveTech. All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of RehiveTech nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   

[dpdk-dev] [PATCH v2 00/16] Support ARMv7 architecture

[Jan Viktorin]

Hello DPDK community, Thomas, Dave,

here I propose the second version of the ARM support patch series. I've included
some ideas from Dave's patch. There are no big changes to the original series.

Important:

* The timer issue has now 2 solutions, the user may configure to use PMU counter
  or the clock_gettime API. The PMU counter may however break perf or other 
tools
  using the PMU Linux API. This is the reason why I did not make it the default.
  Also, I didn't include the Linux Kernel module that enables the PMU for 
userspace.
  There is a note in the rte_cycles.h about it. You should know what you are 
doing
  if you use that, so you may also write that simple driver or get from the 
Dave's
  patch. Later, we can integrate it, after we have some real PMD driver (and 
some
  supporting Linux Kernel module infra...).

* There is the NEON implementation of memcpy. It is faster then the native one
  (you can see stats in the patch), however, we must be sure, the target CPU 
contains
  the NEON co-processor. Also, for longer data lengths and ARM SoCs, the NEON 
memcpy
  implementation can be much slower then the native one. So this is again 
configurable.

* The cpuflags now contains the best from my and Dave's patchs.

* ACL build is broken. I've included a patch (16) that just prevents to pass 
-msse4.1
  into gcc if it does not support it. But that does not solve the whole issue.

* LPM build is broken unless you apply the patch 15. However, this is not the 
right
  solution and I provided just to have a workaround. I don't expect to merge it.

* I've added myself to the MAINTAINERS. Dave, would I like to be there as well?

* The Cortex A7, A8, A9 cores are non-LPAE (non Large Physical Address 
Extension)
  and thus there is no upstream support for huge pages in the Linux Kernel. It 
sounds
  like useless for devices with max 4 GB of RAM (usually 0.5-2 GB). However, our
  measurements have shown that it improve performance. A patch is somewhere 
deep in
  the kernel.org mailing lists.

* Only the GCC toolchain is considered at the moment.

Other details are included in each individual commit.

---

You can pull the changes from

  https://github.com/RehiveTech/dpdk.git arm-support-v2

since commit d08d304508a8a8caf255baf622ab65db1fec952c:

  eal/linux: make alarm not affected by system time jump (2015-10-21 17:01:24 
+0200)

up to 57396c958571b651b4d14f90683b3d1b2d42a70e:

  acl: check for SSE 4.1 support (2015-10-26 17:29:36 +0100)

---

Regards
Jan Viktorin

Jan Viktorin (7):
  eal/arm: implement rdtsc by PMU or clock_gettime
  eal/arm: use vector memcpy only when NEON is enabled
  eal/arm: detect arm architecture in cpu flags
  eal/arm: rwlock support for ARM
  gcc/arm: avoid alignment errors to break build
  maintainers: claim responsibility for ARMv7
  acl: check for SSE 4.1 support

Vlastimil Kosar (9):
  mk: Introduce ARMv7 architecture
  eal/arm: atomic operations for ARM
  eal/arm: byte order operations for ARM
  eal/arm: cpu cycle operations for ARM
  eal/arm: prefetch operations for ARM
  eal/arm: spinlock operations for ARM (without HTM)
  eal/arm: vector memcpy for ARM
  eal/arm: cpu flag checks for ARM
  lpm/arm: implement rte_lpm_lookupx4 using rte_lpm_lookup_bulk on
for-x86

 MAINTAINERS|   4 +
 app/test/test_cpuflags.c   |   5 +
 config/defconfig_arm-armv7-a-linuxapp-gcc  |  75 +
 lib/librte_acl/Makefile|   4 +
 .../common/include/arch/arm/rte_atomic.h   | 256 
 .../common/include/arch/arm/rte_byteorder.h| 148 ++
 .../common/include/arch/arm/rte_cpuflags.h | 192 
 .../common/include/arch/arm/rte_cycles.h   | 121 
 .../common/include/arch/arm/rte_memcpy.h   | 325 +
 .../common/include/arch/arm/rte_prefetch.h |  61 
 .../common/include/arch/arm/rte_rwlock.h   |  40 +++
 .../common/include/arch/arm/rte_spinlock.h | 114 
 lib/librte_lpm/rte_lpm.h   |  71 +
 mk/arch/arm/rte.vars.mk|  39 +++
 mk/machine/armv7-a/rte.vars.mk |  60 
 mk/rte.cpuflags.mk |   6 +
 mk/toolchain/gcc/rte.vars.mk   |   6 +
 17 files changed, 1527 insertions(+)
 create mode 100644 config/defconfig_arm-armv7-a-linuxapp-gcc
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_atomic.h
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_byteorder.h
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_cpuflags.h
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_cycles.h
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_memcpy.h
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_prefetch.h
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_rwlock.h
 create mode 100644 

[dpdk-dev] [PATCH] doc: remove dejavu font from doc build

[Mcnamara, John]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Monday, October 26, 2015 2:25 PM
> To: Mcnamara, John
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] doc: remove dejavu font from doc build
> 
> 2015-10-20 12:32, John McNamara:
> > Remove requirement for occasionally hard to find/install
> > DejaVuSansMono font. It isn't gnerally required anyway.
> > The default mono font is sufficient.
> 
> Does it remove the need for texlive-collection-fontsextra?

Hi Thomas,

Possibly. I'll need to test to make sure. I'll let you know.

John.
-- 

[dpdk-dev] [PATCH] vchost: Notify application of ownership change

[Tetsuya Mukawa]

On 2015/10/26 15:30, Yuanhan Liu wrote:
> On Mon, Oct 26, 2015 at 02:54:07PM +0900, Tetsuya Mukawa wrote:
>> On 2015/10/25 2:16, Thomas Monjalon wrote:
>>> 2015-08-12 03:34, Xie, Huawei:
 On 8/8/2015 1:21 AM, Jan Kiszka wrote:
> On VHOST_*_RESET_OWNER, we reinitialize the device but without telling
> the application. That will cause crashes when it continues to invoke
> vhost services on the device. Fix it by calling the destruction hook if
> the device is still in use.
>>> [...]
> --- a/lib/librte_vhost/virtio-net.c
> +++ b/lib/librte_vhost/virtio-net.c
> @@ -402,6 +402,9 @@ reset_owner(struct vhost_device_ctx ctx)
>
>   ll_dev = get_config_ll_entry(ctx);
>
> + if ((ll_dev->dev.flags & VIRTIO_DEV_RUNNING))
> + notify_ops->destroy_device(_dev->dev);
 To me this patch makes sense here.
 Whether RESET_OWNER is really needed is another question. Whenever the
 vhost itself needs to process the vhost device, we need to notify the
 switch application to remove it from data plane.
>>> Huawei,
>>> some patches have been accepted for RESET_OWNER management.
>>> Is this patch obsolete?
> I think it's still appliable, at least so far.
>
>> Hi Yuanhan and Huawei,
>>
>> I also have the same question. Do we have a patch for this issue?
>>
>> Today, I've download Yuanhan's multiple queues patches and applied it on
>> latest dpdk tree.
>> Then, tried to apply my vhost PMD patch on it.
>>
>> When I check the patch, it seems I've faced this issue.
>> Here are steps to reproduce.
> Above patch should fix your issue, right? If so, we need it.

Yes, the patch will fix the issue.

>> 1. Start vhost-user backend application.
>>  (In my case, testpmd using vhost PMD is the application)
>> 2. Start a VM with vhost-user.
>>  You can see below message from the backend application.
>>   VHOST_CONFIG: read message VHOST_USER_SET_VRING_ENABLE
>>   VHOST_CONFIG: set queue enable: 1 to qp idx: 0
>>   (snip)
>>   VHOST_CONFIG: read message VHOST_USER_SET_VRING_KICK
>> 3. After booting Linux on guest, bind the virtio-net device to igb_uio.
>> Then below messages are shown.
>> VHOST_CONFIG: read message VHOST_USER_RESET_OWNER
>> VHOST_CONFIG: read message VHOST_USER_RESET_OWNER
>> VHOST_CONFIG: read message VHOST_USER_GET_VRING_BASE
>>
>> The point is we will have VHOST_USER_RESET_OWNER before
>> VHOST_USER_GET_VRING_BASE.
> Note that there is an ongoing work at QEMU community (from me) to
> handle RESET_OWNER correctly: it will be moved to somewhere else
> instead of before VHOST_USER_GET_VRING_BASE.
>
>   --yliu

Sounds great! Thanks for handling it.

Tetsuya

[dpdk-dev] [PATCH 09/11] lib: add armv8 rte_vect.h

[Jan Viktorin]

On Fri, 23 Oct 2015 15:17:11 +0100
David Hunt  wrote:

> +
> +typedef float32x4_t __m128;
> +
> +typedef int32x4_t __m128i;
> +
> +typedef __m128i xmm_t;
> +
> +#define XMM_SIZE(sizeof(xmm_t))
> +#define XMM_MASK(XMM_SIZE - 1)
> +
> +typedef union rte_xmm {
> + xmm_tx;
> + uint8_t  u8[XMM_SIZE / sizeof(uint8_t)];
> + uint16_t u16[XMM_SIZE / sizeof(uint16_t)];
> + uint32_t u32[XMM_SIZE / sizeof(uint32_t)];
> + uint64_t u64[XMM_SIZE / sizeof(uint64_t)];
> + double   pd[XMM_SIZE / sizeof(double)];
> +} rte_xmm_t __aligned(16);
> +
> +#define _mm_srli_epi32(a, imm) { (__m128i)vshrq_n_u32((uint32x4_t)a, imm) }
> +
> +#define _mm_srli_si128(a, imm) { (__m128i)vextq_s8((int8x16_t)a, \
> + vdupq_n_s8(0), (imm)) }
> +
> +static inline  __m128i
> +_mm_set_epi32(int i3, int i2, int i1, int i0);
> +static inline int
> +_mm_cvtsi128_si64(__m128i a);
> +
> +static inline  __m128i
> +_mm_set_epi32(int i3, int i2, int i1, int i0)
> +{
> + int32_t __aligned(16) data[4] = { i0, i1, i2, i3 };
> + return vld1q_s32(data);
> +}
> +
> +static inline int
> +_mm_cvtsi128_si64(__m128i a)
> +{
> + return vgetq_lane_s64(a, 0);
> +}
> +
> +static inline __m128i
> +_mm_and_si128(__m128i a, __m128i b)
> +{
> + return (__m128i)vandq_s32(a, b);
> +}
> +

What is the purpose of those wrappers? I mean, does it help to compile
some SSE-dependent libraries in DPDK for NEON?

Jan

-- 
   Jan Viktorin  E-mail: Viktorin at RehiveTech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic

[dpdk-dev] [PATCH 03/11] lib: add armv8 rte_cpuflags.h

[Jan Viktorin]

On Fri, 23 Oct 2015 15:17:05 +0100
David Hunt  wrote:

> +#include "generic/rte_cpuflags.h"
> +
> +/* Symbolic values for the entries in the auxiliary table */
> +#define AT_HWCAP  16
> +#define AT_HWCAP2 26
> +#define AT_PLATFORM 15
> +
> +/* software based registers */
> +enum cpu_register_t {
> + REG_HWCAP = 0,
> + AARCH_MODE,
> +};
> +
> +/**
> + * Enumeration of all CPU features supported
> + */
> +enum rte_cpu_flag_t {
> + RTE_CPUFLAG_FP = 0,
> + RTE_CPUFLAG_ASIMD,
> + RTE_CPUFLAG_EVTSTRM,
> + RTE_CPUFLAG_AARCH64,
> + RTE_CPUFLAG_AARCH32,

We detect ARCH32/64 on both ARMv7 and ARMv8. This is strange.

> + /* The last item */
> + RTE_CPUFLAG_NUMFLAGS,/**< This should always be the last! */
> +};
> +
> +static const struct feature_entry cpu_feature_table[] = {
> + FEAT_DEF(FP, 0x0001, 0, REG_HWCAP,  0)
> + FEAT_DEF(ASIMD, 0x0001, 0, REG_HWCAP,  1)
> + FEAT_DEF(EVTSTRM, 0x0001, 0, REG_HWCAP,  2)
> + FEAT_DEF(AARCH64, 0x0001, 0, AARCH_MODE, 3)
> + FEAT_DEF(AARCH32, 0x0001, 0, AARCH_MODE, 4)
> +};
> +

Is it possible to extend it in the same way as it is prepared for ARMv7
[1, 2]?

[1] 
https://github.com/RehiveTech/dpdk/commit/bd5f0480b60282cfcd0ef43ddf8896bef8a23bbb
[2] 
https://github.com/RehiveTech/dpdk/commit/e293c11770aefc1f58f0c0cca5efee02b21910ba

Perhaps, can we merge this with ARMv7 one (in a single file)? Do the
features overlap in a sane way?

Jan


-- 
   Jan Viktorin  E-mail: Viktorin at RehiveTech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic

[dpdk-dev] how to use multiple RX queues on the same port

[Montorsi, Francesco]

Hi all,
To avoid rx_nombuf packet drops, I'm trying to configure a DPDK port to use 
more than 1 RX queue... so I'm trying (on a 10Gbps card) to use 4 RX queues.
The call to rte_eth_dev_configure() and the 4 calls to rte_eth_rx_queue_setup() 
succeed but then via the rte_eth_rx_queue_count() API I see that only the first 
RX queue is used. The remaining 3 seems unused... am I missing something?


Thanks!

Francesco Montorsi

[dpdk-dev] [PATCH 10/11] mk: add makefile and config changes for armv8 architecture

[Jan Viktorin]

On Fri, 23 Oct 2015 15:17:12 +0100
David Hunt  wrote:

> +# in machine .mk)
> +#   - define CPU_CFLAGS variable (overridden by cmdline or previous
> +# define in machine .mk)
> +#   - define CPU_LDFLAGS variable (overridden by cmdline or previous
> +# define in machine .mk)
> +#   - define CPU_ASFLAGS variable (overridden by cmdline or previous
> +# define in machine .mk)
> +#   - may override any previously defined variable
> +#
> +# examples for CONFIG_RTE_ARCH: i686, x86_64, x86_64_32
> +#
> +
> +ARCH  ?= arm64
> +# common arch dir in eal headers
> +ARCH_DIR := arm64
> +CROSS ?=
> +
> +CPU_CFLAGS  ?= -flax-vector-conversions

What is the purpose of this flag?

from man gcc:

-flax-vector-conversions
  Allow implicit conversions between vectors with differing numbers of
  elements and/or incompatible element types. 
  This option should not be used for new code.
  ^^^

Jan

> +CPU_LDFLAGS ?=
> +CPU_ASFLAGS ?=
> +
> +export ARCH CROSS CPU_CFLAGS CPU_LDFLAGS CPU_ASFLAGS


-- 
   Jan Viktorin  E-mail: Viktorin at RehiveTech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic

[dpdk-dev] [PATCH 00/11] add armv8 architecture support

[Jan Viktorin]

Hello David,

thanks for this series. I'am sending few comments to the code as well.
Soon, I will have an ARMv8 board available so I will be able to test it.

Probably, we can just reinclude some headers from arm/ directory for
ARMv8 as they are not different.

Jan

On Fri, 23 Oct 2015 15:17:02 +0100
David Hunt  wrote:

> This patch provides support for the ARMv8 architecture. We hope that this will
> encourage the ARM community to contribute PMDs for their SoCs to DPDK.
> 
> For now, we've added Intel engineers to the MAINTAINERS file. We would like to
> encourage the ARM community to take over maintenance of this area in future,
> and to further improve it.
> 
> ACL and LPM libraries have been disabled in the config due to their reliance
> on SSE. 
> 
> This patch was tested on an Applied Micro X-Gene Mustang board (pcap only)
> 
> This patch was also tested with an Intel 82599 NIC on a Gigabyte MP30-AR0
> passing traffic between the two NIC ports using testpmd.
> 
> Notes on DPDK configuration:
> 
>   Did not use igb_uio or kni so the following optionse were disabled in 
>   config/common_linuxapp
> 
>   CONFIG_RTE_EAL_IGB_UIO=n
>   CONFIG_RTE_LIBRTE_KNI=n
>   CONFIG_RTE_KNI_KMOD=n
> 
>   make config T=arm64-native-linuxapp-gcc
>   make install T=arm64-native-linuxapp-gcc
>   
> Notes on arm64 kernel configuration:
> 
>   Using Ubuntu 14.04 LTS with a 4.3.0-rc6 kernel (with modified PCI drivers),
>   and uio_pci_generic.
>   ARM64 kernels do not seem to have functional resource mapping of PCI memory
>   (PCI_MMAP), so the pci driver needs to be patched to enable this. The
>   symptom of this is when /sys/bus/pci/devices/:0X:00.Y directory is
>   missing the resource0...N files for mmapping the device memory. Earlier
>   kernels (3.13.x) had these files present, but mmap'ping resulted in a
>   "Bus Error" when the NIC memory was accessed.
>   However, during limited testing with a modified 4.3.0-rc6 kernel, we were
>   able to mmap the NIC memory, and pass traffic between the two ports on a
>   82599 NIC connected via fibre cable. 
>   We have no plans to upstream a kernel patch for this and hope that
>   someone more familiar with the arm architecture can create a proper patch
>   and enable this functionality.
> 
> Benjamin Boren (11):
>   lib: add armv8 rte_atomic.h
>   lib: add armv8 rte_byteorder.h
>   lib: add armv8 rte_cpuflags.h
>   lib: add armv8 rte_cycles.h
>   lib: add armv8 rte_memcpy.h
>   lib: add armv8 rte_prefetch.h
>   lib: add armv8 rte_rwlock.h
>   lib: add armv8 rte_spinlock.h
>   lib: add armv8 rte_vect.h
>   mk: add makefile and config changes for armv8 architecture
>   app: add armv8 cpuflags check to test_cpuflags application
> 
>  MAINTAINERS|   6 +
>  app/test/test_cpuflags.c   |  17 ++
>  config/defconfig_arm64-native-linuxapp-gcc |  55 +
>  .../common/include/arch/arm64/rte_atomic.h | 269 
> +
>  .../common/include/arch/arm64/rte_byteorder.h  | 157 
>  .../common/include/arch/arm64/rte_cpuflags.h   | 137 +++
>  .../common/include/arch/arm64/rte_cycles.h |  77 ++
>  .../common/include/arch/arm64/rte_memcpy.h | 266 
>  .../common/include/arch/arm64/rte_prefetch.h   |  61 +
>  .../common/include/arch/arm64/rte_rwlock.h |  70 ++
>  .../common/include/arch/arm64/rte_spinlock.h   | 114 +
>  .../common/include/arch/arm64/rte_vect.h   | 102 
>  mk/arch/arm64/rte.vars.mk  |  58 +
>  mk/machine/armv8-a/rte.vars.mk |  57 +
>  mk/rte.cpuflags.mk |   9 +
>  15 files changed, 1455 insertions(+)
>  create mode 100644 config/defconfig_arm64-native-linuxapp-gcc
>  create mode 100644 lib/librte_eal/common/include/arch/arm64/rte_atomic.h
>  create mode 100644 lib/librte_eal/common/include/arch/arm64/rte_byteorder.h
>  create mode 100644 lib/librte_eal/common/include/arch/arm64/rte_cpuflags.h
>  create mode 100644 lib/librte_eal/common/include/arch/arm64/rte_cycles.h
>  create mode 100644 lib/librte_eal/common/include/arch/arm64/rte_memcpy.h
>  create mode 100644 lib/librte_eal/common/include/arch/arm64/rte_prefetch.h
>  create mode 100644 lib/librte_eal/common/include/arch/arm64/rte_rwlock.h
>  create mode 100644 lib/librte_eal/common/include/arch/arm64/rte_spinlock.h
>  create mode 100644 lib/librte_eal/common/include/arch/arm64/rte_vect.h
>  create mode 100644 mk/arch/arm64/rte.vars.mk
>  create mode 100644 mk/machine/armv8-a/rte.vars.mk
> 



-- 
   Jan Viktorin  E-mail: Viktorin at RehiveTech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic

[dpdk-dev] [PATCH v1 0/3] lpm: increase number of next hops for lpm (ipv4)

[Vladimir Medvedkin]

Hi Michal,

Forwarding class can help us to classify traffic based on dst prefix, it's
something like Juniper DCU. For example on Juniper MX I can make policy
that install prefix into the FIB with some class and use it on dataplane,
for example with ACL.
On Juniper MX I can make something like that:
#show policy-options
policy-statement community-to-class {
term customer {
from community originate-customer;
then destination-class customer;
}
}
community originate-customer members 12345:1;
# show routing-options
forwarding-table {
export community-to-class;
}
# show forwarding-options
forwarding-options {
family inet {
filter {
output test-filter;
}
}
}
# show firewall family inet filter test-filter
term 1 {
from {
protocol icmp;
destination-class customer;
}
then {
discard;
}
}
announce route 10.10.10.10/32 next-hop 10.10.10.2 community 12345:1
After than on dataplane we have
NPC1( vty)# show route ip lookup 10.10.10.10
Route Information (10.10.10.10):
 interface : xe-1/0/0.0 (328)
 Nexthop prefix : -
 Nexthop ID : 1048574
 MTU: 0
 Class ID   : 129 <- That is "forwarding class" in my implementation
This construction discards all ICMP traffic that goes to dst prefixes which
was originated with community 12345:1. With this mechanism we can make
on control plane different sophisticated policy to control traffic on
dataplane.
The same with as_num, we can have on dataplane AS number that has
originated that prefix, or another 4-byte number e.g. geo-id.
What issue do you mean? I think it is because of table/pipeline/test
frameworks that doesen't want to compile due to changing API/ABI. You can
turn it off for LPM testing, if my patch will be applied I will make
changes in above-mentioned frameworks.

Regards,
Vladimir

2015-10-26 14:57 GMT+03:00 Jastrzebski, MichalX K <
michalx.k.jastrzebski at intel.com>:

> > -Original Message-
> > From: Michal Jastrzebski [mailto:michalx.k.jastrzebski at intel.com]
> > Sent: Monday, October 26, 2015 12:55 PM
> > To: Vladimir Medvedkin
> > Subject: Re: [dpdk-dev] [PATCH v1 0/3] lpm: increase number of next hops
> > for lpm (ipv4)
> >
> > On Sun, Oct 25, 2015 at 08:52:04PM +0300, Vladimir Medvedkin wrote:
> > > Hi all,
> > >
> > > Here my implementation
> > >
> > > Signed-off-by: Vladimir Medvedkin 
> > > ---
> > >  config/common_bsdapp |   1 +
> > >  config/common_linuxapp   |   1 +
> > >  lib/librte_lpm/rte_lpm.c | 194
> > > +--
> > >  lib/librte_lpm/rte_lpm.h | 163 +++
> > >  4 files changed, 219 insertions(+), 140 deletions(-)
> > >
> > > diff --git a/config/common_bsdapp b/config/common_bsdapp
> > > index b37dcf4..408cc2c 100644
> > > --- a/config/common_bsdapp
> > > +++ b/config/common_bsdapp
> > > @@ -344,6 +344,7 @@ CONFIG_RTE_LIBRTE_JOBSTATS=y
> > >  #
> > >  CONFIG_RTE_LIBRTE_LPM=y
> > >  CONFIG_RTE_LIBRTE_LPM_DEBUG=n
> > > +CONFIG_RTE_LIBRTE_LPM_ASNUM=n
> > >
> > >  #
> > >  # Compile librte_acl
> > > diff --git a/config/common_linuxapp b/config/common_linuxapp
> > > index 0de43d5..1c60e63 100644
> > > --- a/config/common_linuxapp
> > > +++ b/config/common_linuxapp
> > > @@ -352,6 +352,7 @@ CONFIG_RTE_LIBRTE_JOBSTATS=y
> > >  #
> > >  CONFIG_RTE_LIBRTE_LPM=y
> > >  CONFIG_RTE_LIBRTE_LPM_DEBUG=n
> > > +CONFIG_RTE_LIBRTE_LPM_ASNUM=n
> > >
> > >  #
> > >  # Compile librte_acl
> > > diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
> > > index 163ba3c..363b400 100644
> > > --- a/lib/librte_lpm/rte_lpm.c
> > > +++ b/lib/librte_lpm/rte_lpm.c
> > > @@ -159,9 +159,11 @@ rte_lpm_create(const char *name, int socket_id,
> > int
> > > max_rules,
> > >
> > > lpm_list = RTE_TAILQ_CAST(rte_lpm_tailq.head, rte_lpm_list);
> > >
> > > -   RTE_BUILD_BUG_ON(sizeof(struct rte_lpm_tbl24_entry) != 2);
> > > -   RTE_BUILD_BUG_ON(sizeof(struct rte_lpm_tbl8_entry) != 2);
> > > -
> > > +#ifdef RTE_LIBRTE_LPM_ASNUM
> > > +   RTE_BUILD_BUG_ON(sizeof(struct rte_lpm_tbl_entry) != 8);
> > > +#else
> > > +   RTE_BUILD_BUG_ON(sizeof(struct rte_lpm_tbl_entry) != 4);
> > > +#endif
> > > /* Check user arguments. */
> > > if ((name == NULL) || (socket_id < -1) || (max_rules == 0)){
> > > rte_errno = EINVAL;
> > > @@ -261,7 +263,7 @@ rte_lpm_free(struct rte_lpm *lpm)
> > >   */
> > >  static inline int32_t
> > >  rule_add(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
> > > -   uint8_t next_hop)
> > > +   struct rte_lpm_res *res)
> > >  {
> > > uint32_t rule_gindex, rule_index, last_rule;
> > > int i;
> > > @@ -282,8 +284,11 @@ rule_add(struct rte_lpm *lpm, uint32_t
> > ip_masked,
> > > uint8_t depth,
> > >
> > > /* If rule already exists update its next_hop
> and
> > > return. */
> > > if (lpm->rules_tbl[rule_index].ip ==
> ip_masked) 

[dpdk-dev] Fwd: [PATCH] em: enable flash access, tested with Intel 82577LM

[Thomas Monjalon]

This patch does not comply with the DPDK rules.
But the needs deserved to be discussed with the e1000 maintainer.
Wenzhuo?

2015-10-07 13:27, Jiuling Bie:
> ---
>  drivers/net/e1000/base/e1000_osdep.h| 18 --
>  drivers/net/e1000/em_ethdev.c   |  1 +
>  lib/librte_eal/common/include/rte_pci_dev_ids.h |  1 +
>  3 files changed, 10 insertions(+), 10 deletions(-)

[dpdk-dev] [PATCH v1 0/3] lpm: increase number of next hops for lpm (ipv4)

[Michal Jastrzebski]

esOn Mon, Oct 26, 2015 at 05:03:31PM +0300, Vladimir Medvedkin wrote:
> Hi Michal,
> 
> Forwarding class can help us to classify traffic based on dst prefix, it's
> something like Juniper DCU. For example on Juniper MX I can make policy
> that install prefix into the FIB with some class and use it on dataplane,
> for example with ACL.
> On Juniper MX I can make something like that:
> #show policy-options
> policy-statement community-to-class {
> term customer {
> from community originate-customer;
> then destination-class customer;
> }
> }
> community originate-customer members 12345:1;
> # show routing-options
> forwarding-table {
> export community-to-class;
> }
> # show forwarding-options
> forwarding-options {
> family inet {
> filter {
> output test-filter;
> }
> }
> }
> # show firewall family inet filter test-filter
> term 1 {
> from {
> protocol icmp;
> destination-class customer;
> }
> then {
> discard;
> }
> }
> announce route 10.10.10.10/32 next-hop 10.10.10.2 community 12345:1
> After than on dataplane we have
> NPC1( vty)# show route ip lookup 10.10.10.10
> Route Information (10.10.10.10):
>  interface : xe-1/0/0.0 (328)
>  Nexthop prefix : -
>  Nexthop ID : 1048574
>  MTU: 0
>  Class ID   : 129 <- That is "forwarding class" in my implementation
> This construction discards all ICMP traffic that goes to dst prefixes which
> was originated with community 12345:1. With this mechanism we can make
> on control plane different sophisticated policy to control traffic on
> dataplane.
> The same with as_num, we can have on dataplane AS number that has
> originated that prefix, or another 4-byte number e.g. geo-id.
> What issue do you mean? I think it is because of table/pipeline/test
> frameworks that doesen't want to compile due to changing API/ABI. You can
> turn it off for LPM testing, if my patch will be applied I will make
> changes in above-mentioned frameworks.
> 
> Regards,
> Vladimir

Hi Vladimir,
I have an issue with applying Your patch not compilation.
This is the error i get:
Checking patch config/common_bsdapp...
Checking patch config/common_linuxapp...
Checking patch lib/librte_lpm/rte_lpm.c...
error: while searching for:

   lpm_list = RTE_TAILQ_CAST(rte_lpm_tailq.head, rte_lpm_list);

   RTE_BUILD_BUG_ON(sizeof(struct rte_lpm_tbl24_entry) != 2);
   RTE_BUILD_BUG_ON(sizeof(struct rte_lpm_tbl8_entry) != 2);

   /* Check user arguments. */
   if ((name == NULL) || (socket_id < -1) || (max_rules == 0)){
   rte_errno = EINVAL;

error: patch failed: lib/librte_lpm/rte_lpm.c:159
error: lib/librte_lpm/rte_lpm.c: patch does not apply
Checking patch lib/librte_lpm/rte_lpm.h...
error: while searching for:
#define RTE_LPM_RETURN_IF_TRUE(cond, retval)
#endif

/** @internal bitmask with valid and ext_entry/valid_group fields set */
#define RTE_LPM_VALID_EXT_ENTRY_BITMASK 0x0300

/** Bitmask used to indicate successful lookup */
#define RTE_LPM_LOOKUP_SUCCESS  0x0100

#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
/** @internal Tbl24 entry structure. */
struct rte_lpm_tbl24_entry {
   /* Stores Next hop or group index (i.e. gindex)into tbl8. */
   union {
   uint8_t next_hop;
   uint8_t tbl8_gindex;
   };
   /* Using single uint8_t to store 3 values. */
   uint8_t valid :1; /**< Validation flag. */
   uint8_t ext_entry :1; /**< External entry. */
   uint8_t depth :6; /**< Rule depth. */
};

/** @internal Tbl8 entry structure. */
struct rte_lpm_tbl8_entry {
   uint8_t next_hop; /**< next hop. */
   /* Using single uint8_t to store 3 values. */
   uint8_t valid   :1; /**< Validation flag. */
   uint8_t valid_group :1; /**< Group validation flag. */
   uint8_t depth   :6; /**< Rule depth. */
};
#else
struct rte_lpm_tbl24_entry {
   uint8_t depth   :6;
   uint8_t ext_entry   :1;
   uint8_t valid   :1;
   union {
   uint8_t tbl8_gindex;
   uint8_t next_hop;
   };
};

struct rte_lpm_tbl8_entry {
   uint8_t depth   :6;
   uint8_t valid_group :1;
   uint8_t valid   :1;
   uint8_t next_hop;
};
#endif

/** @internal Rule structure. */
struct rte_lpm_rule {
   uint32_t ip; /**< Rule IP address. */
   uint8_t  next_hop; /**< Rule next hop. */
};

/** @internal Contains metadata about the rules table. */

error: patch failed: lib/librte_lpm/rte_lpm.h:81
error: lib/librte_lpm/rte_lpm.h: patch does not apply



> 2015-10-26 14:57 GMT+03:00 Jastrzebski, MichalX K <
> michalx.k.jastrzebski at intel.com>:
> 
> > > -Original Message-
> > > From: Michal Jastrzebski [mailto:michalx.k.jastrzebski at intel.com]
> > > Sent: Monday, October 26, 2015 12:55 PM
> > > To: Vladimir Medvedkin
> > > Subject: Re: [dpdk-dev] [PATCH v1 0/3] lpm: increase number of next hops
> > > for lpm (ipv4)
> 

[dpdk-dev] [PATCH v2 1/3] rte: add keep alive functionality

[Remy Horton]

'noon,

On 23/10/2015 15:27, Wiles, Keith wrote:
>> +uint32_t __rte_cache_aligned state_flags[RTE_KEEPALIVE_MAXCORES];
> Normally I see the __rte_cache_aligned at the end of the line before
> the ?;? did you have a reason to have it here? If not then I would
> move it to the end to look the same as the others. I did a quick grop
> in the code and that is the normal location.
>
> My next question is why not align the whole, which would do the same
> thing. I did not check the compiler output, but I was thinking it
> would possible leave gaps in the structure for bytes we can not use
> normally, but maybe that is not a problem.

Each element of state_flags is assigned to a different LCore, so they 
have to be individually cache-aligned. The gaps it leaves behind are 
unavoidable.


> Next it appears the state_flags is only being set to 0-3, which means
> it does not need to be a uint43_t, but could be a uint8_t, correct?

Yes, but since it all needs to be cache aligned anyway, wouldn't 
actually gain anything.


>> +keepcfg = malloc(sizeof(struct rte_keepalive));
>> +if (keepcfg != NULL) {
>> +for (idx_core = 0; idx_core < RTE_KEEPALIVE_MAXCORES; 
>> idx_core++) {
>> +keepcfg->state_flags[idx_core] = 0;
>> +keepcfg->active_cores[idx_core] = 0;
>> +}
>
> Could you have done a calloc then you do not need the for loop to zero stuff?

Could do. It was written this way because the function originally took a 
structure rather than allocate one.


..Remy

[dpdk-dev] dpdk proposal installation process

[Arevalo, Mario Alfredo C]

> -Original Message-
> From: Richardson, Bruce
> Sent: Thursday, October 22, 2015 9:57 AM
> To: Panu Matilainen
> Cc: Olivier MATZ; Arevalo, Mario Alfredo C; dev at dpdk.org
> Subject: Re: [dpdk-dev] dpdk proposal installation process
> 
> On Thu, Oct 22, 2015 at 08:55:41AM +0300, Panu Matilainen wrote:
> > On 10/21/2015 10:15 PM, Olivier MATZ wrote:
> > >Hi Mario,
> > >
> > >On 10/20/2015 11:17 AM, Bruce Richardson wrote:
> > >>On Tue, Oct 20, 2015 at 12:21:00AM +, Arevalo, Mario Alfredo C
> wrote:
> > >>>Hi folks,
> > >>>
> > >>>   Good day, this is a proposal in order to improve the dpdk
> > >>>install process, I would like to know your point of view about the
> > >>>next points according to previous conversations :) in order to create a
> new patches version.
> > >>>
> > >>>1) I think the first thing that I have to be aware is
> > >>>"compatibility", the new changes won't affect the current dpdk
> behaviour.
> > >
> > >Yes. As I stated in a previous mail, I think nobody uses the current
> > >"make install" without specifying T= as the default value is to build
> > >and install for all targets.
> > >
> > >My suggestion is:
> > >
> > >- rename the previous "install" target. The name could probably
> > >   be "mbuild" (for multiple builds). Other ideas are welcome.
> > >
> > >- when "make install" is invoked with T= argument, call the mbuild
> > >   target to have the same behavior than before. This compat layer
> > >   could be removed in the future.
> > >
> > >- when "make install" is invoked without T=, it installs the fhs.
> >
> > Nice, this sounds like the best of both worlds.
> >
> > >
> > >>>2) Create new makefile rules, these rules is going to install dpdk
> > >>>files in default paths, however the linux distributions don't use
> > >>>the same paths for their files, the linux distribution and the
> > >>>architecture can be factor for different path as Panu commented in
> > >>>previous conversations, he is right, then all variables could be
> overridden, the variables names for the user can be included in
> documentation.
> > >>>Also an option could be a configuration file for paths, however I'm not
> sure.
> > >
> > >I think having variables is ok.
> > >
> > >>>3) The default paths for dpdk in order to follow a hierarchy,
> > >>>however the variable with those values can be overridden.
> > >>>
> > >>>-install-bin  --> /usr/bin.
> > >>>-install-headers  --> /usr/include/dpdk
> > >>>-install-lib   --> /usr/lib64
> > >
> > >I remember Panu suggested to have /usr/lib by default.
> > >I also think /usr/lib a better default value: some distributions use
> > >/usr/lib for 64 bits libs, but we never have 32 bits libs in
> > >/usr/lib64.
> >
> > Yes, just stick /usr/lib there and be done with it, lib64 is not a
> > good default for these very reasons.
> >
> > >>>-install-doc --> /usr/share/doc/dpdk
> > >>>-install-mod--> if RTE_EXEC_ENV=linuxapp then
> KERNEL_DIR=/lib/modules/$(uname -r)/extra/drivers/dpdk
> > >>> else KERNEL_DIR=/boot/modules).
> > >
> > >I'm not sure KERNEL_DIR is the proper name. Maybe KMOD_DIR?
> > >
> > >>>-install-sdk --> /usr/share/dpdk and call install-headers ).
> > >>>-install-fhs  --> call install-libraries, install-mod, 
> > >>>install-bin and install-
> doc (maybe install-headers)
> > >>>
> > >>>4) I'm going to take account all feedback about variables, paths etc for
> the new version :).
> > >>>
> > >>>Thank you so much for your help.
> > >>>
> > >>>
> > >>>Mario.
> > >>
> > >>Hi Mario,
> > >>
> > >>that seems like a lot of commands to add - are they all individually
> needed?
> > >>
> > >>In terms of where things go, should the "usr" part not a) be
> > >>configurable via a parameter, and b) default to "/usr/local" as
> > >>that's where user-installed software from outside the packaging system
> normally gets put.
> > >
> > >A PREFIX variable would do the job.
> > >About the default to /usr or /usr/local, I agree that /usr/local
> > >looks more usual, and I don't think it's a problem for packaging as
> > >soon as it can be overridden.
> >
> > Yeah, PREFIX support would be nice, and defaulting that to /usr/local
> > would be the right thing.
> >
> > - Panu -
> >
> > >
> > >
> > >Regards,
> > >Olivier
> > >
> >
> 
> Can I throw a completely different suggestion into the mix?
> 
> Can we make use of the fact that make config creates a directory called
> "build"
> by default. Then running "make" alone in that directory does the expected
> behaviour of a compile of the whole sdk. How about having "make install" in
> the build directory behave like a generic "make install" call for other
> packages?
> 
> I'm imagining the following sequence of steps to install:
> 
>   ./configure --machine=[default|native|other]
>   # configure is a simple script that just calls "make config 
> T=..."
>   cd build
>   make
>   make install
> 
> Thoughts?
> 
> /Bruce

Hi 

[dpdk-dev] [PATCH v2 1/5] szedata2: add new poll mode driver

[Thomas Monjalon]

2015-09-18 10:32, Matej Vido:
> Add virtual PMD which communicates with COMBO cards through sze2
> layer using libsze2 library.
> 
> Since link_speed is uint16_t, there can not be used number for 100G
> speed, therefore link_speed is set to ETH_LINK_SPEED_10G until the
> type of link_speed is solved.
> 
> v2:
> Code cleanup.
> Fix error handling by initialization of rx, tx dma channels.
> Add uninit function.

There are some warnings raised by checkpatch.pl. Please check.

When sending a new version, it would be appreciated to introduce Rx/Tx
in another patch.

Thanks

[dpdk-dev] [PATCH v2 4/5] doc: add documentation for szedata2 PMD

[Thomas Monjalon]

Hi Matej,

Thanks for providing a documentation.
I'm sorry to give a late feedback and I would like that other contributors
have reviewed it. There are a lot of PMD developers around. Please help.


2015-09-18 10:32, Matej Vido:
> +- **libsze2**
> +
> +  This library provides API for initialization of sze2 transfers, receiving 
> and
> +  transmitting data segments.

Please provide more information to help installing the dependencies.

> +SZEDATA2 PMD can be created by passing --vdev= option to EAL in the following
> +format:
> +
> +.. code-block:: console
> +
> +--vdev 
> 'DEVICE_NAME,dev_path=PATH_TO_SZEDATA2_DEVICE,rx_ifaces=RX_MASK,tx_ifaces=TX_MASK'

SZEDATA2 is not a vdev. Is it possible to probe it as a standard PCI device?

[dpdk-dev] [PATCH v2 4/5] doc: add documentation for szedata2 PMD

[Thomas Monjalon]

2015-09-18 10:32, Matej Vido:
> Signed-off-by: Matej Vido 
> Reviewed-by: Jan Viktorin 

Please John, could you review this new doc?
Thanks

[dpdk-dev] [PATCH v2 2/2] doc: User-space ethtool sample application

[Remy Horton]

Signed-off-by: Remy Horton 
---
 doc/guides/sample_app_ug/ethtool.rst | 265 +++
 doc/guides/sample_app_ug/index.rst   |   1 +
 2 files changed, 266 insertions(+)
 create mode 100644 doc/guides/sample_app_ug/ethtool.rst

diff --git a/doc/guides/sample_app_ug/ethtool.rst 
b/doc/guides/sample_app_ug/ethtool.rst
new file mode 100644
index 000..6d71908
--- /dev/null
+++ b/doc/guides/sample_app_ug/ethtool.rst
@@ -0,0 +1,265 @@
+
+..  BSD LICENSE
+Copyright(c) 2015 Intel Corporation. All rights reserved.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+EthTool Sample Application
+==
+
+The Ethtool sample application shows an implementation of an
+EthTool-like API and provides a console environment that allows
+its use to query and change Ethernet card parameters. The sample
+is based upon a simple L2 frame reflector.
+
+
+Compiling the Application
+-
+
+To compile the application:
+
+#.  Go to the sample application directory:
+
+.. code-block:: console
+
+export RTE_SDK=/path/to/rte_sdk cd ${RTE_SD}/examples/ethtool
+
+#.  Set the target (a default target is used if not specified). For example:
+
+.. code-block:: console
+
+export RTE_TARGET=x86_64-native-linuxapp-gcc
+
+See the *DPDK Getting Started Guide* for possible RTE_TARGET values.
+
+#.  Build the application:
+
+.. code-block:: console
+
+make
+
+Running the Application
+---
+
+The application requires an available core for each port, plus one.
+The only available options are the standard ones for the EAL:
+
+.. code-block:: console
+
+./build/ethtool [EAL options]
+
+Refer to the *DPDK Getting Started Guide* for general information on
+running applications and the Environment Abstraction Layer (EAL)
+options.
+
+Using the application
+-
+
+The application is console-driven using the cmdline DPDK interface:
+
+.. code-block:: console
+
+EthApp>
+
+From this interface the available commands and descriptions of what
+they do as as follows:
+
+drvinfo
+Print driver info
+eeprom
+Dump EEPROM to file
+link
+Print port link states
+macaddr
+Gets/sets MAC address
+mtu
+Set NIC MTU
+open
+Open port
+pause
+Get/set port pause state
+portstats
+Print port statistics
+regs
+Dump port register(s) to file
+ringparam
+Get/set ring parameters
+rxmode
+Toggle port Rx mode
+stop
+Stop port
+validate
+Check that given MAC address is valid unicast address
+vlan
+Add/remove VLAN id
+quit
+Exit program
+
+
+Explaination
+
+
+The following sections describe the most important parts of the code.
+
+
+Base program
+
+
+The top-level, after some port initialisation routines, runs the following:
+
+.. code-block:: c
+
+   for (idx_port = 0; idx_port < cnt_ports; idx_port++) {
+   ptr_port = _cfg.ports[idx_port];
+   rte_eal_remote_launch(slave_main, ptr_port, idx_port + 1);
+   }
+
+   ethapp_main();
+
+Each slave core, or a subset of these cores if there are more cores then
+NIC ports, runs the `slave core process`_ described below. The master core
+then runs the `EthTool App`_ itself.
+
+
+Slave core process
+~~
+
+Each slave core is assigned one of the available ports, and runs
+the following code that implements a 

[dpdk-dev] [PATCH v2 1/2] example: User-space ethtool sample application

[Remy Horton]

Further enhancements to the userspace ethtool implementation that was
submitted in 2.1 and packaged as a self-contained sample application.
Implements an rte_ethtool shim layer based on rte_ethdev API, along
with a command prompt driven demonstration application.

Signed-off-by: Remy Horton 
---
 examples/ethtool/Makefile  |  48 ++
 examples/ethtool/app/Makefile  |  54 +++
 examples/ethtool/app/ethapp.c  | 870 +
 examples/ethtool/app/ethapp.h  |  40 ++
 examples/ethtool/app/main.c| 281 
 examples/ethtool/lib/Makefile  |  57 +++
 examples/ethtool/lib/rte_ethtool.c | 421 ++
 examples/ethtool/lib/rte_ethtool.h | 410 +
 8 files changed, 2181 insertions(+)
 create mode 100644 examples/ethtool/Makefile
 create mode 100644 examples/ethtool/app/Makefile
 create mode 100644 examples/ethtool/app/ethapp.c
 create mode 100644 examples/ethtool/app/ethapp.h
 create mode 100644 examples/ethtool/app/main.c
 create mode 100644 examples/ethtool/lib/Makefile
 create mode 100644 examples/ethtool/lib/rte_ethtool.c
 create mode 100644 examples/ethtool/lib/rte_ethtool.h

diff --git a/examples/ethtool/Makefile b/examples/ethtool/Makefile
new file mode 100644
index 000..0505446
--- /dev/null
+++ b/examples/ethtool/Makefile
@@ -0,0 +1,48 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2015 Intel Corporation. All rights reserved.
+#   All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of Intel Corporation nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+ifeq ($(RTE_SDK),)
+$(error "Please define RTE_SDK environment variable")
+endif
+
+# Default target, can be overwritten by command line or environment
+RTE_TARGET ?= x86_64-native-linuxapp-gcc
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+ifneq ($(CONFIG_RTE_EXEC_ENV),"linuxapp")
+$(error This application can only operate in a linuxapp environment, \
+please change the definition of the RTE_TARGET environment variable)
+endif
+
+DIRS-y += lib app
+
+include $(RTE_SDK)/mk/rte.extsubdir.mk
diff --git a/examples/ethtool/app/Makefile b/examples/ethtool/app/Makefile
new file mode 100644
index 000..62c5828
--- /dev/null
+++ b/examples/ethtool/app/Makefile
@@ -0,0 +1,54 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+#   All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of Intel Corporation nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 

[dpdk-dev] [PATCH v2 0/2] User-space ethtool sample application

[Remy Horton]

Further enhancements to the userspace ethtool implementation that was
submitted in 2.1 and packaged as a self-contained sample application.
Implements an rte_ethtool shim layer based on rte_ethdev API, along
with a command prompt driven demonstration application.

This patchset depends on http://dpdk.org/dev/patchwork/patch/6563/

v2:
* Replaced l2fwd base with simpler application.
* Added ringparam functions.
* Added documentation.

Remy Horton (2):
  example: User-space ethtool sample application
  doc: User-space ethtool sample application

 doc/guides/sample_app_ug/ethtool.rst | 265 +++
 doc/guides/sample_app_ug/index.rst   |   1 +
 examples/ethtool/Makefile|  48 ++
 examples/ethtool/app/Makefile|  54 +++
 examples/ethtool/app/ethapp.c| 870 +++
 examples/ethtool/app/ethapp.h|  40 ++
 examples/ethtool/app/main.c  | 281 +++
 examples/ethtool/lib/Makefile|  57 +++
 examples/ethtool/lib/rte_ethtool.c   | 421 +
 examples/ethtool/lib/rte_ethtool.h   | 410 +
 10 files changed, 2447 insertions(+)
 create mode 100644 doc/guides/sample_app_ug/ethtool.rst
 create mode 100644 examples/ethtool/Makefile
 create mode 100644 examples/ethtool/app/Makefile
 create mode 100644 examples/ethtool/app/ethapp.c
 create mode 100644 examples/ethtool/app/ethapp.h
 create mode 100644 examples/ethtool/app/main.c
 create mode 100644 examples/ethtool/lib/Makefile
 create mode 100644 examples/ethtool/lib/rte_ethtool.c
 create mode 100644 examples/ethtool/lib/rte_ethtool.h

-- 
1.9.3

[dpdk-dev] [PATCH v2 3/5] szedata2: add handling of scattered packets in TX

[Thomas Monjalon]

Hi Matej,

2015-09-18 10:32, Matej Vido:
> - rte_memcpy(tmp_dst,
> - rte_pktmbuf_mtod(mbuf, const void *),
> - pkt_len);
> + if (likely(mbuf_segs == 1)) {
> + /*
> +  * non-scattered packet,
> +  * transmit from one mbuf
> +  */
> + rte_memcpy(tmp_dst,
> + rte_pktmbuf_mtod(mbuf, const void *),
> + pkt_len);

You could avoid this change by keeping "if (likely(mbuf_segs == 1))"
in the first patch.
By the way, it seems to be an abusive use of "likely".

[dpdk-dev] [PATCH v4] nfp: new poll mode driver for netronome nfp-6xxx card

[Thomas Monjalon]

2015-10-23 11:36, Alejandro.Lucero:
> From: "Alejandro.Lucero" 
> 
> This patch adds a new PMD for using PCI Virtual Functions with Netronome
> nfp6000 card.
> 
> Signed-off-by: Alejandro.Lucero 
> Signed-off-by: Rolf.Neugebauer 
> ---
>  drivers/net/nfp/Makefile   |   88 ++
>  drivers/net/nfp/nfp_net.c  | 2495 
> 
>  drivers/net/nfp/nfp_net_ctrl.h |  290 +
>  drivers/net/nfp/nfp_net_logs.h |   75 ++
>  drivers/net/nfp/nfp_net_pmd.h  |  434 +++

It seems this driver is not integrated in the build system.

Please avoid such huge patch and submit piece by piece.
Example:
- patch 1 for the basic init
- patch 2 for Rx/Tx
- patch 3 for RSS
- patch 4 for statistics

It will be easier to review.

It would be also appreciated to have a doc in doc/guides/nics
and an entry in the release notes.

Thanks

[dpdk-dev] [PATCH v1 3/7] e1000: add ethdev rxq enable and disable function

[Liang, Cunming]

On 9/25/2015 4:28 PM, Yong Liu wrote:
> From: Marvin Liu 
>
> Implement rxq interrupt related functions in eth_dev_ops structure.
>
> Signed-off-by: Marvin Liu 
>
> diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
> index e86c039..2b67b62 100644
> --- a/drivers/net/e1000/em_ethdev.c
> +++ b/drivers/net/e1000/em_ethdev.c
> @@ -108,6 +108,9 @@ static void em_vlan_hw_strip_disable(struct rte_eth_dev 
> *dev);
>   static void eth_em_vlan_filter_set(struct rte_eth_dev *dev,
>   uint16_t vlan_id, int on);
>   */
> +
> +static int eth_em_rx_queue_intr_enable(struct rte_eth_dev *dev, uint16_t 
> queue_id);
> +static int eth_em_rx_queue_intr_disable(struct rte_eth_dev *dev, uint16_t 
> queue_id);
>   static void em_lsc_intr_disable(struct e1000_hw *hw);
>   static void em_rxq_intr_enable(struct e1000_hw *hw);
>   static void em_rxq_intr_disable(struct e1000_hw *hw);
> @@ -163,6 +166,8 @@ static const struct eth_dev_ops eth_em_ops = {
>   .rx_descriptor_done   = eth_em_rx_descriptor_done,
>   .tx_queue_setup   = eth_em_tx_queue_setup,
>   .tx_queue_release = eth_em_tx_queue_release,
> + .rx_queue_intr_enable = eth_em_rx_queue_intr_enable,
> + .rx_queue_intr_disable = eth_em_rx_queue_intr_disable,
>   .dev_led_on   = eth_em_led_on,
>   .dev_led_off  = eth_em_led_off,
>   .flow_ctrl_get= eth_em_flow_ctrl_get,
> @@ -891,6 +896,27 @@ eth_em_stats_reset(struct rte_eth_dev *dev)
>   memset(hw_stats, 0, sizeof(*hw_stats));
>   }
>   
> +static int
> +eth_em_rx_queue_intr_enable(struct rte_eth_dev *dev, 
> __attribute__((__unused__))uint16_t queue_id)
Suggest to use __rte_unused instead of __attribute__((__unused__)).
> +{
> + struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> +
> + em_rxq_intr_enable(hw);
> + rte_intr_enable(&(dev->pci_dev->intr_handle));
> +
> + return 0;
> +}
> +
> +static int
> +eth_em_rx_queue_intr_disable(struct rte_eth_dev *dev, 
> __attribute__((__unused__))uint16_t queue_id)
The same.
> +{
> + struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> +
> + em_rxq_intr_disable(hw);
> +
> + return 0;
> +}
> +
>   static uint32_t
>   em_get_max_pktlen(const struct e1000_hw *hw)
>   {

[dpdk-dev] [PATCH] doc: fix rst issues in testpmd user guide

[Thomas Monjalon]

> > Fix a number of RST issues in the testpmd user guide and
> > refactored the structure to:
> > 
> > * Remove redundant roadmap section.
> > * Merge Overview section into Introduction.
> > * Move "set fwd" to the start of its section.
> > 
> > Signed-off-by: John McNamara 
> 
> Acked-by: Pablo de Lara 

Applied, thanks

[dpdk-dev] [PATCH v1 1/7] e1000: add rx interrupt support

[Liang, Cunming]

Hi Yong,

On 9/25/2015 4:28 PM, Yong Liu wrote:
> From: Marvin Liu 
>
> Enable rx interrupt support on e1000 PF non-IOV mode.
As I know, e1000 hasn't IOV mode. It's not necessary to mention PF 
non-IOV mode or not.
In addition, it's necessary to mention the patch series is to support 
uio/vfio or both? To allow physical/emulation or both?
>
> Signed-off-by: Marvin Liu 
>
> diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
> index 912f5dd..99beb9c 100644
> --- a/drivers/net/e1000/em_ethdev.c
> +++ b/drivers/net/e1000/em_ethdev.c
> @@ -81,6 +81,7 @@ static int eth_em_flow_ctrl_get(struct rte_eth_dev *dev,
>   static int eth_em_flow_ctrl_set(struct rte_eth_dev *dev,
>   struct rte_eth_fc_conf *fc_conf);
>   static int eth_em_interrupt_setup(struct rte_eth_dev *dev);
> +static int eth_em_rxq_interrupt_setup(struct rte_eth_dev *dev);
>   static int eth_em_interrupt_get_status(struct rte_eth_dev *dev);
>   static int eth_em_interrupt_action(struct rte_eth_dev *dev);
>   static void eth_em_interrupt_handler(struct rte_intr_handle *handle,
> @@ -107,6 +108,7 @@ static void em_vlan_hw_strip_disable(struct rte_eth_dev 
> *dev);
>   static void eth_em_vlan_filter_set(struct rte_eth_dev *dev,
>   uint16_t vlan_id, int on);
>   */
> +static void em_rxq_intr_enable(struct e1000_hw *hw);
>   static int eth_em_led_on(struct rte_eth_dev *dev);
>   static int eth_em_led_off(struct rte_eth_dev *dev);
>   
> @@ -608,6 +610,9 @@ eth_em_start(struct rte_eth_dev *dev)
>   return ret;
>   }
>   }
> + /* check if rxq interrupt is enabled */
> + if (dev->data->dev_conf.intr_conf.rxq != 0)
> + eth_em_rxq_interrupt_setup(dev);
>   
>   adapter->stopped = 0;
>   
> @@ -1276,6 +1281,39 @@ eth_em_interrupt_setup(struct rte_eth_dev *dev)
>   return (0);
>   }
>   
> +/* It clears the interrupt causes and enables the interrupt.
Comments start from next line of '/*' or '/**'?
> + * It will be called once only during nic initialized.
> + *
> + * @param dev
> + *  Pointer to struct rte_eth_dev.
> + *
> + * @return
> + *  - On success, zero.
> + *  - On failure, a negative value.
> + */
> +static int
> +eth_em_rxq_interrupt_setup(struct rte_eth_dev *dev)
> +{
> + struct e1000_hw *hw =
> + E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> +
> + E1000_READ_REG(hw, E1000_ICR);
> + em_rxq_intr_enable(hw);
> + return 0;
> +}
> +
> +/* It enable receive packet interrupt.
The same.
> + * @param hw
> + * Pointer to struct e1000_hw
> + *
> + * @return
> + */
> +static void
> +em_rxq_intr_enable(struct e1000_hw *hw)
> +{
> + E1000_WRITE_REG(hw, E1000_IMS, E1000_IMS_RXT0);
To make sure post-write be finished immediately, E1000_WRITE_FLUSH() 
shall add behind.
> +}
> +
>   /*
>* It reads ICR and gets interrupt causes, check it and set a bit flag
>* to update link status.

[dpdk-dev] [PATCH v2] doc: change sphinx theme to the read the docs theme

[Thomas Monjalon]

2015-10-21 10:39, John McNamara:
> Change the Sphinx default theme from "alabaster" to the ReadTheDocs
> theme. See for example:
> 
> http://dpdk.readthedocs.org/en/latest/
> 
> This looks better for technical documentation and in particular
> it has a 80 char wide verbatim block rendering.

Yes it is a clean theme.
It would be nice to add the DPDK logo somewhere.

> Also turn off option for distracting Html mouseover permalinks.
[...]
> +html_add_permalinks = ""

I think the permalinks are very useful to point a specific doc chapter
to someone else.

[dpdk-dev] [PATCH] doc: remove dejavu font from doc build

[Thomas Monjalon]

2015-10-20 12:32, John McNamara:
> Remove requirement for occasionally hard to find/install
> DejaVuSansMono font. It isn't gnerally required anyway.
> The default mono font is sufficient.

Does it remove the need for texlive-collection-fontsextra?

[dpdk-dev] [PATCH] doc: fix pdf build warning

[Thomas Monjalon]

> > Fix a pdf doc build warning where a link wasn't recognised:
> > 
> > doc/guides/contributing/documentation.rst::
> > WARNING: unusable reference target found: inkscape.org
> > 
> > Signed-off-by: John McNamara 
> 
> Acked-by: Harry van Haaren 

Applied, thanks

[dpdk-dev] [PATCH] default to using all cores if no -c, -l, or --lcores options given

[Thomas Monjalon]

There was no comment for this new behaviour.
It means everybody agree to default to all cores.

2015-09-25 13:37, Rich Lane:
> This is a useful default for simple applications where the assignment of 
> lcores
> to CPUs doesn't matter. It's also useful for more complex applications that
> automatically assign tasks to cores based on the NUMA topology.
> 
> Signed-off-by: Rich Lane 

[dpdk-dev] [PATCH] vchost: Notify application of ownership change

[Tetsuya Mukawa]

On 2015/10/25 2:16, Thomas Monjalon wrote:
> 2015-08-12 03:34, Xie, Huawei:
>> On 8/8/2015 1:21 AM, Jan Kiszka wrote:
>>> On VHOST_*_RESET_OWNER, we reinitialize the device but without telling
>>> the application. That will cause crashes when it continues to invoke
>>> vhost services on the device. Fix it by calling the destruction hook if
>>> the device is still in use.
> [...]
>>> --- a/lib/librte_vhost/virtio-net.c
>>> +++ b/lib/librte_vhost/virtio-net.c
>>> @@ -402,6 +402,9 @@ reset_owner(struct vhost_device_ctx ctx)
>>>
>>> ll_dev = get_config_ll_entry(ctx);
>>>
>>> +   if ((ll_dev->dev.flags & VIRTIO_DEV_RUNNING))
>>> +   notify_ops->destroy_device(_dev->dev);
>> To me this patch makes sense here.
>> Whether RESET_OWNER is really needed is another question. Whenever the
>> vhost itself needs to process the vhost device, we need to notify the
>> switch application to remove it from data plane.
> Huawei,
> some patches have been accepted for RESET_OWNER management.
> Is this patch obsolete?

Hi Yuanhan and Huawei,

I also have the same question. Do we have a patch for this issue?

Today, I've download Yuanhan's multiple queues patches and applied it on
latest dpdk tree.
Then, tried to apply my vhost PMD patch on it.

When I check the patch, it seems I've faced this issue.
Here are steps to reproduce.

1. Start vhost-user backend application.
 (In my case, testpmd using vhost PMD is the application)
2. Start a VM with vhost-user.
 You can see below message from the backend application.
  VHOST_CONFIG: read message VHOST_USER_SET_VRING_ENABLE
  VHOST_CONFIG: set queue enable: 1 to qp idx: 0
  (snip)
  VHOST_CONFIG: read message VHOST_USER_SET_VRING_KICK
3. After booting Linux on guest, bind the virtio-net device to igb_uio.
Then below messages are shown.
VHOST_CONFIG: read message VHOST_USER_RESET_OWNER
VHOST_CONFIG: read message VHOST_USER_RESET_OWNER
VHOST_CONFIG: read message VHOST_USER_GET_VRING_BASE

The point is we will have VHOST_USER_RESET_OWNER before
VHOST_USER_GET_VRING_BASE.
Currently, in RESET_OWNER function, all virtio-net data is initialized.
As a result, we also initialize virtio-net flags.
When we get GET_VRING_BASE, we cannot call destroy callback handler
because RUNNING flag has been initialized already.

 I guess when we get RESET_OWNER message, I don't need to do anything.
And all finalizations should be done in GET_VRING_BASE.
(Or some finalizations might be done when next SET_MEM_TABLE is called.)

Thanks,
Tetsuya

[dpdk-dev] [PATCH] vchost: Notify application of ownership change

[Yuanhan Liu]

On Mon, Oct 26, 2015 at 02:54:07PM +0900, Tetsuya Mukawa wrote:
> On 2015/10/25 2:16, Thomas Monjalon wrote:
> > 2015-08-12 03:34, Xie, Huawei:
> >> On 8/8/2015 1:21 AM, Jan Kiszka wrote:
> >>> On VHOST_*_RESET_OWNER, we reinitialize the device but without telling
> >>> the application. That will cause crashes when it continues to invoke
> >>> vhost services on the device. Fix it by calling the destruction hook if
> >>> the device is still in use.
> > [...]
> >>> --- a/lib/librte_vhost/virtio-net.c
> >>> +++ b/lib/librte_vhost/virtio-net.c
> >>> @@ -402,6 +402,9 @@ reset_owner(struct vhost_device_ctx ctx)
> >>>
> >>>   ll_dev = get_config_ll_entry(ctx);
> >>>
> >>> + if ((ll_dev->dev.flags & VIRTIO_DEV_RUNNING))
> >>> + notify_ops->destroy_device(_dev->dev);
> >> To me this patch makes sense here.
> >> Whether RESET_OWNER is really needed is another question. Whenever the
> >> vhost itself needs to process the vhost device, we need to notify the
> >> switch application to remove it from data plane.
> > Huawei,
> > some patches have been accepted for RESET_OWNER management.
> > Is this patch obsolete?

I think it's still appliable, at least so far.

> 
> Hi Yuanhan and Huawei,
> 
> I also have the same question. Do we have a patch for this issue?
> 
> Today, I've download Yuanhan's multiple queues patches and applied it on
> latest dpdk tree.
> Then, tried to apply my vhost PMD patch on it.
> 
> When I check the patch, it seems I've faced this issue.
> Here are steps to reproduce.

Above patch should fix your issue, right? If so, we need it.

> 
> 1. Start vhost-user backend application.
>  (In my case, testpmd using vhost PMD is the application)
> 2. Start a VM with vhost-user.
>  You can see below message from the backend application.
>   VHOST_CONFIG: read message VHOST_USER_SET_VRING_ENABLE
>   VHOST_CONFIG: set queue enable: 1 to qp idx: 0
>   (snip)
>   VHOST_CONFIG: read message VHOST_USER_SET_VRING_KICK
> 3. After booting Linux on guest, bind the virtio-net device to igb_uio.
> Then below messages are shown.
> VHOST_CONFIG: read message VHOST_USER_RESET_OWNER
> VHOST_CONFIG: read message VHOST_USER_RESET_OWNER
> VHOST_CONFIG: read message VHOST_USER_GET_VRING_BASE
> 
> The point is we will have VHOST_USER_RESET_OWNER before
> VHOST_USER_GET_VRING_BASE.

Note that there is an ongoing work at QEMU community (from me) to
handle RESET_OWNER correctly: it will be moved to somewhere else
instead of before VHOST_USER_GET_VRING_BASE.

--yliu

> Currently, in RESET_OWNER function, all virtio-net data is initialized.
> As a result, we also initialize virtio-net flags.
> When we get GET_VRING_BASE, we cannot call destroy callback handler
> because RUNNING flag has been initialized already.
> 
>  I guess when we get RESET_OWNER message, I don't need to do anything.
> And all finalizations should be done in GET_VRING_BASE.
> (Or some finalizations might be done when next SET_MEM_TABLE is called.)
> 
> Thanks,
> Tetsuya

[dpdk-dev] [PATCH v8 3/8] vhost: vring queue setup for multiple queue support

[Tetsuya Mukawa]

On 2015/10/22 21:35, Yuanhan Liu wrote:
> All queue pairs, including the default (the first) queue pair,
> are allocated dynamically, when a vring_call message is received
> first time for a specific queue pair.
>
> This is a refactor work for enabling vhost-user multiple queue;
> it should not break anything as it does no functional changes:
> we don't support mq set, so there is only one mq at max.
>
> This patch is based on Changchun's patch.
>
> Signed-off-by: Ouyang Changchun 
> Signed-off-by: Yuanhan Liu 
> Acked-by: Flavio Leitner 
>
> ---
>
> v8: - move virtuque field to the end of `virtio_net' struct.
>
> - Add a FIXME at set_vring_call() for doing vring queue pair
>   allocation.
> ---
>  lib/librte_vhost/rte_virtio_net.h |   3 +-
>  lib/librte_vhost/vhost_user/virtio-net-user.c |  46 
>  lib/librte_vhost/virtio-net.c | 156 
> --
>  3 files changed, 123 insertions(+), 82 deletions(-)
>
> diff --git a/lib/librte_vhost/rte_virtio_net.h 
> b/lib/librte_vhost/rte_virtio_net.h
> index e3a21e5..9a32a95 100644
> --- a/lib/librte_vhost/rte_virtio_net.h
> +++ b/lib/librte_vhost/rte_virtio_net.h
> @@ -96,7 +96,6 @@ struct vhost_virtqueue {
>   * Device structure contains all configuration information relating to the 
> device.
>   */
>  struct virtio_net {
> - struct vhost_virtqueue  *virtqueue[VIRTIO_QNUM];/**< Contains 
> all virtqueue information. */
>   struct virtio_memory*mem;   /**< QEMU memory and memory 
> region information. */
>   uint64_tfeatures;   /**< Negotiated feature set. */
>   uint64_tprotocol_features;  /**< Negotiated 
> protocol feature set. */
> @@ -104,7 +103,9 @@ struct virtio_net {
>   uint32_tflags;  /**< Device flags. Only used to 
> check if device is running on data core. */
>  #define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ)
>   charifname[IF_NAME_SZ]; /**< Name of the tap 
> device or socket path. */
> + uint32_tvirt_qp_nb; /**< number of queue pair we 
> have allocated */
>   void*priv;  /**< private context */
> + struct vhost_virtqueue  *virtqueue[VIRTIO_NET_CTRL_MQ_VQ_PAIRS_MAX];
> /**< Contains all virtqueue information. */
>  } __rte_cache_aligned;
>  
>  /**
> diff --git a/lib/librte_vhost/vhost_user/virtio-net-user.c 
> b/lib/librte_vhost/vhost_user/virtio-net-user.c
> index 6da729d..d62f3d7 100644
> --- a/lib/librte_vhost/vhost_user/virtio-net-user.c
> +++ b/lib/librte_vhost/vhost_user/virtio-net-user.c
> @@ -206,25 +206,33 @@ err_mmap:
>  }
>  
>  static int
> +vq_is_ready(struct vhost_virtqueue *vq)
> +{
> + return vq && vq->desc   &&
> +vq->kickfd != -1 &&
> +vq->callfd != -1;
> +}
> +
> +static int
>  virtio_is_ready(struct virtio_net *dev)
>  {
>   struct vhost_virtqueue *rvq, *tvq;
> + uint32_t i;
>  
> - /* mq support in future.*/
> - rvq = dev->virtqueue[VIRTIO_RXQ];
> - tvq = dev->virtqueue[VIRTIO_TXQ];
> - if (rvq && tvq && rvq->desc && tvq->desc &&
> - (rvq->kickfd != -1) &&
> - (rvq->callfd != -1) &&
> - (tvq->kickfd != -1) &&
> - (tvq->callfd != -1)) {
> - RTE_LOG(INFO, VHOST_CONFIG,
> - "virtio is now ready for processing.\n");
> - return 1;
> + for (i = 0; i < dev->virt_qp_nb; i++) {
> + rvq = dev->virtqueue[i * VIRTIO_QNUM + VIRTIO_RXQ];
> + tvq = dev->virtqueue[i * VIRTIO_QNUM + VIRTIO_TXQ];
> +
> + if (!vq_is_ready(rvq) || !vq_is_ready(tvq)) {
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "virtio is not ready for processing.\n");
> + return 0;
> + }
>   }
> +
>   RTE_LOG(INFO, VHOST_CONFIG,
> - "virtio isn't ready for processing.\n");
> - return 0;
> + "virtio is now ready for processing.\n");
> + return 1;
>  }
>  
>  void
> @@ -292,13 +300,13 @@ user_get_vring_base(struct vhost_device_ctx ctx,
>* sent and only sent in vhost_vring_stop.
>* TODO: cleanup the vring, it isn't usable since here.
>*/
> - if ((dev->virtqueue[VIRTIO_RXQ]->kickfd) >= 0) {
> - close(dev->virtqueue[VIRTIO_RXQ]->kickfd);
> - dev->virtqueue[VIRTIO_RXQ]->kickfd = -1;
> + if ((dev->virtqueue[state->index]->kickfd + VIRTIO_RXQ) >= 0) {
> + close(dev->virtqueue[state->index + VIRTIO_RXQ]->kickfd);
> + dev->virtqueue[state->index + VIRTIO_RXQ]->kickfd = -1;
>   }

Hi Yuanhan,

Please let me make sure whether below is correct.
if ((dev->virtqueue[state->index]->kickfd + VIRTIO_RXQ) >= 0) {

> - if ((dev->virtqueue[VIRTIO_TXQ]->kickfd) >= 0) {
> - close(dev->virtqueue[VIRTIO_TXQ]->kickfd);
> - 

[dpdk-dev] how to get driver name for a given port ID

[Montorsi, Francesco]

Hi all,

Is there an API to retrieve the driver name for a certain port ID before 
calling rte_eth_dev_configure()?

My use case is: I'm trying to call rte_eth_dev_configure() with nb_rx_q=4 and 
found that this works for ixgbe driver but it doesn't for "rte_em_pmd" (1Gbps 
device):

ERROR HwEmulDPDKPort::init() rte_eth_dev_configure: err=-22, port=0: Unknown 
error -22
EAL: PCI device :03:00.0 on NUMA socket 0
EAL:   remove driver: 8086:105e rte_em_pmd
EAL:   PCI memory unmapped at 0x7feb4000
EAL:   PCI memory unmapped at 0x7feb4002

So, for those devices I want to use nb_rx_q=1...

Thanks,

Francesco Montorsi

[dpdk-dev] [PATCH v2 0/5] virtio: Tx performance improvements

[Xie, Huawei]

On 10/19/2015 1:16 PM, Stephen Hemminger wrote:
> This is a tested version of the virtio Tx performance improvements
> that I posted earlier on the list, and described at the DPDK Userspace
> meeting in Dublin. Together they get a 25% performance improvement for
> both small packet and large multi-segment packet case when testing
> from DPDK guest application to Linux KVM host.
>
> Stephen Hemminger (5):
>   virtio: clean up space checks on xmit
>   virtio: don't use unlikely for normal tx stuff
>   virtio: use indirect ring elements
>   virtio: use any layout on transmit
>   virtio: optimize transmit enqueue
There is one open why merge-able header is used in tx path. Since old
implementation is also using the merge-able header in tx path if this
feature is negotiated, i choose to ack the patch and address this later
if not now.

Acked-by: Huawei Xie 

[dpdk-dev] [PATCH v8 3/8] vhost: vring queue setup for multiple queue support

[Yuanhan Liu]

On Mon, Oct 26, 2015 at 02:24:08PM +0900, Tetsuya Mukawa wrote:
> On 2015/10/22 21:35, Yuanhan Liu wrote:
...
> > @@ -292,13 +300,13 @@ user_get_vring_base(struct vhost_device_ctx ctx,
> >  * sent and only sent in vhost_vring_stop.
> >  * TODO: cleanup the vring, it isn't usable since here.
> >  */
> > -   if ((dev->virtqueue[VIRTIO_RXQ]->kickfd) >= 0) {
> > -   close(dev->virtqueue[VIRTIO_RXQ]->kickfd);
> > -   dev->virtqueue[VIRTIO_RXQ]->kickfd = -1;
> > +   if ((dev->virtqueue[state->index]->kickfd + VIRTIO_RXQ) >= 0) {
> > +   close(dev->virtqueue[state->index + VIRTIO_RXQ]->kickfd);
> > +   dev->virtqueue[state->index + VIRTIO_RXQ]->kickfd = -1;
> > }
> 
> Hi Yuanhan,
> 
> Please let me make sure whether below is correct.
> if ((dev->virtqueue[state->index]->kickfd + VIRTIO_RXQ) >= 0) {
> 
> > -   if ((dev->virtqueue[VIRTIO_TXQ]->kickfd) >= 0) {
> > -   close(dev->virtqueue[VIRTIO_TXQ]->kickfd);
> > -   dev->virtqueue[VIRTIO_TXQ]->kickfd = -1;
> > +   if ((dev->virtqueue[state->index]->kickfd + VIRTIO_TXQ) >= 0) {
> > +   close(dev->virtqueue[state->index + VIRTIO_TXQ]->kickfd);
> > +   dev->virtqueue[state->index + VIRTIO_TXQ]->kickfd = -1;
> 
> Also, same question here.

Oops, silly typos... Thanks for catching it out!

Here is an update patch (Thomas, please let me know if you prefer me
to send the whole patchset for you to apply):

-- >8 --
>From 2b7d8155b6c9f37bffcbb220e87f7634f329acee Mon Sep 17 00:00:00 2001
From: Yuanhan Liu 
Date: Fri, 18 Sep 2015 16:01:10 +0800
Subject: [PATCH] vhost: vring queue setup for multiple queue support

All queue pairs, including the default (the first) queue pair,
are allocated dynamically, when a vring_call message is received
first time for a specific queue pair.

This is a refactor work for enabling vhost-user multiple queue;
it should not break anything as it does no functional changes:
we don't support mq set, so there is only one mq at max.

This patch is based on Changchun's patch.

Signed-off-by: Ouyang Changchun 
Signed-off-by: Yuanhan Liu 
Acked-by: Flavio Leitner 

---

v9: - fix silly error "dev->virtqueue[state->index]->kickfd + VIRTIO_RXQ"

v8: - move virtuque field to the end of `virtio_net' struct.

- Add a FIXME at set_vring_call() for doing vring queue pair
  allocation.
---
 lib/librte_vhost/rte_virtio_net.h |   3 +-
 lib/librte_vhost/vhost_user/virtio-net-user.c |  46 
 lib/librte_vhost/virtio-net.c | 156 --
 3 files changed, 123 insertions(+), 82 deletions(-)

diff --git a/lib/librte_vhost/rte_virtio_net.h 
b/lib/librte_vhost/rte_virtio_net.h
index e3a21e5..9a32a95 100644
--- a/lib/librte_vhost/rte_virtio_net.h
+++ b/lib/librte_vhost/rte_virtio_net.h
@@ -96,7 +96,6 @@ struct vhost_virtqueue {
  * Device structure contains all configuration information relating to the 
device.
  */
 struct virtio_net {
-   struct vhost_virtqueue  *virtqueue[VIRTIO_QNUM];/**< Contains 
all virtqueue information. */
struct virtio_memory*mem;   /**< QEMU memory and memory 
region information. */
uint64_tfeatures;   /**< Negotiated feature set. */
uint64_tprotocol_features;  /**< Negotiated 
protocol feature set. */
@@ -104,7 +103,9 @@ struct virtio_net {
uint32_tflags;  /**< Device flags. Only used to 
check if device is running on data core. */
 #define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ)
charifname[IF_NAME_SZ]; /**< Name of the tap 
device or socket path. */
+   uint32_tvirt_qp_nb; /**< number of queue pair we 
have allocated */
void*priv;  /**< private context */
+   struct vhost_virtqueue  *virtqueue[VIRTIO_NET_CTRL_MQ_VQ_PAIRS_MAX];
/**< Contains all virtqueue information. */
 } __rte_cache_aligned;

 /**
diff --git a/lib/librte_vhost/vhost_user/virtio-net-user.c 
b/lib/librte_vhost/vhost_user/virtio-net-user.c
index 6da729d..7fc3805 100644
--- a/lib/librte_vhost/vhost_user/virtio-net-user.c
+++ b/lib/librte_vhost/vhost_user/virtio-net-user.c
@@ -206,25 +206,33 @@ err_mmap:
 }

 static int
+vq_is_ready(struct vhost_virtqueue *vq)
+{
+   return vq && vq->desc   &&
+  vq->kickfd != -1 &&
+  vq->callfd != -1;
+}
+
+static int
 virtio_is_ready(struct virtio_net *dev)
 {
struct vhost_virtqueue *rvq, *tvq;
+   uint32_t i;

-   /* mq support in future.*/
-   rvq = dev->virtqueue[VIRTIO_RXQ];
-   tvq = dev->virtqueue[VIRTIO_TXQ];
-   if (rvq && tvq && rvq->desc && tvq->desc &&
-   (rvq->kickfd != -1) &&
-   (rvq->callfd != -1) &&
-   (tvq->kickfd != -1) &&
-   (tvq->callfd != -1)) {
-   RTE_LOG(INFO, VHOST_CONFIG,
-   

[dpdk-dev] [PATCH v5 5/7] app/testpmd: modify and add fdir filter and mask CLIs for new modes

[Wenzhuo Lu]

The different fdir mode needs different parameters, so, the parameter *mode*
is introduced to the CLI flow_director_filter and flow_director_mask. This
parameter can pormpt the user to input the appropriate parameters for different
mode.
Please be aware, as we should set the fdir mode, the value of the parameter
pkt-filter-mode, when we start testpmd. We cannot set a different mode for
mask or filter.

The new CLIs are added for the mac vlan and tunnel modes, like this,
flow_director_mask X mode MAC-VLAN vlan  mac XX,
flow_director_mask X mode Tunnel vlan  mac XX tunnel-type X tunnel-id ,
flow_director_filter X mode MAC-VLAN add/del/update mac XX:XX:XX:XX:XX:XX
vlan  flexbytes (X,X) fwd/drop queue X fd_id X,
flow_director_filter X mode Tunnel add/del/update mac XX:XX:XX:XX:XX:XX
vlan  tunnel NVGRE/VxLAN tunnel-id  flexbytes (X,X) fwd/drop queue X
fd_id X.

Signed-off-by: Wenzhuo Lu 
---
 app/test-pmd/cmdline.c | 294 ++---
 1 file changed, 279 insertions(+), 15 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 0f8f48f..b3c36f3 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -7725,6 +7725,8 @@ cmdline_parse_inst_t cmd_ethertype_filter = {
 struct cmd_flow_director_result {
cmdline_fixed_string_t flow_director_filter;
uint8_t port_id;
+   cmdline_fixed_string_t mode;
+   cmdline_fixed_string_t mode_value;
cmdline_fixed_string_t ops;
cmdline_fixed_string_t flow;
cmdline_fixed_string_t flow_type;
@@ -7747,6 +7749,12 @@ struct cmd_flow_director_result {
uint16_t  queue_id;
cmdline_fixed_string_t fd_id;
uint32_t  fd_id_value;
+   cmdline_fixed_string_t mac;
+   struct ether_addr mac_addr;
+   cmdline_fixed_string_t tunnel;
+   cmdline_fixed_string_t tunnel_type;
+   cmdline_fixed_string_t tunnel_id;
+   uint32_t tunnel_id_value;
 };

 static inline int
@@ -7818,6 +7826,26 @@ str2flowtype(char *string)
return RTE_ETH_FLOW_UNKNOWN;
 }

+static uint8_t
+str2fdir_tunneltype(char *string)
+{
+   uint8_t i = 0;
+
+   static const struct {
+   char str[32];
+   uint8_t type;
+   } tunneltype_str[] = {
+   {"NVGRE", RTE_FDIR_TUNNEL_TYPE_NVGRE},
+   {"VxLAN", RTE_FDIR_TUNNEL_TYPE_VXLAN},
+   };
+
+   for (i = 0; i < RTE_DIM(tunneltype_str); i++) {
+   if (!strcmp(tunneltype_str[i].str, string))
+   return tunneltype_str[i].type;
+   }
+   return RTE_FDIR_TUNNEL_TYPE_UNKNOWN;
+}
+
 #define IPV4_ADDR_TO_UINT(ip_addr, ip) \
 do { \
if ((ip_addr).family == AF_INET) \
@@ -7858,6 +7886,25 @@ cmd_flow_director_filter_parsed(void *parsed_result,
}
memset(flexbytes, 0, sizeof(flexbytes));
memset(, 0, sizeof(struct rte_eth_fdir_filter));
+
+   if (fdir_conf.mode ==  RTE_FDIR_MODE_PERFECT_MAC_VLAN) {
+   if (strcmp(res->mode_value, "MAC-VLAN")) {
+   printf("Please set mode to MAC-VLAN.\n");
+   return;
+   }
+   } else if (fdir_conf.mode ==  RTE_FDIR_MODE_PERFECT_TUNNEL) {
+   if (strcmp(res->mode_value, "Tunnel")) {
+   printf("Please set mode to Tunnel.\n");
+   return;
+   }
+   } else {
+   if (strcmp(res->mode_value, "IP")) {
+   printf("Please set mode to IP.\n");
+   return;
+   }
+   entry.input.flow_type = str2flowtype(res->flow_type);
+   }
+
ret = parse_flexbytes(res->flexbytes_value,
flexbytes,
RTE_ETH_FDIR_MAX_FLEXLEN);
@@ -7866,7 +7913,6 @@ cmd_flow_director_filter_parsed(void *parsed_result,
return;
}

-   entry.input.flow_type = str2flowtype(res->flow_type);
switch (entry.input.flow_type) {
case RTE_ETH_FLOW_FRAG_IPV4:
case RTE_ETH_FLOW_NONFRAG_IPV4_OTHER:
@@ -7927,9 +7973,24 @@ cmd_flow_director_filter_parsed(void *parsed_result,
rte_cpu_to_be_16(res->ether_type);
break;
default:
-   printf("invalid parameter.\n");
-   return;
+   break;
+   }
+
+   if (fdir_conf.mode ==  RTE_FDIR_MODE_PERFECT_MAC_VLAN)
+   (void)rte_memcpy(_vlan_flow.mac_addr,
+>mac_addr,
+sizeof(struct ether_addr));
+
+   if (fdir_conf.mode ==  RTE_FDIR_MODE_PERFECT_TUNNEL) {
+   (void)rte_memcpy(_flow.mac_addr,
+>mac_addr,
+sizeof(struct ether_addr));
+   entry.input.flow.tunnel_flow.tunnel_type =
+   str2fdir_tunneltype(res->tunnel_type);
+   

[dpdk-dev] [PATCH v5 4/7] app/testpmd: modify the output of the CLI show port fdir

[Wenzhuo Lu]

There're fdir mask and supported flow type in the output of the CLI,
show port fdir. But not every parameter has meaning for all the fdir
modes, and the supported flow type is meaningless for mac vlan and
tunnel modes. So, we output different thing for different mode.

Signed-off-by: Wenzhuo Lu 
---
 app/test-pmd/config.c | 45 +++--
 1 file changed, 31 insertions(+), 14 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index cf2aa6e..1ec6a77 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1829,18 +1829,28 @@ set_qmap(portid_t port_id, uint8_t is_rx, uint16_t 
queue_id, uint8_t map_value)
 static inline void
 print_fdir_mask(struct rte_eth_fdir_masks *mask)
 {
-   printf("\nvlan_tci: 0x%04x, src_ipv4: 0x%08x, dst_ipv4: 0x%08x,"
- " src_port: 0x%04x, dst_port: 0x%04x",
-   mask->vlan_tci_mask, mask->ipv4_mask.src_ip,
-   mask->ipv4_mask.dst_ip,
-   mask->src_port_mask, mask->dst_port_mask);
-
-   printf("\nsrc_ipv6: 0x%08x,0x%08x,0x%08x,0x%08x,"
-" dst_ipv6: 0x%08x,0x%08x,0x%08x,0x%08x",
-   mask->ipv6_mask.src_ip[0], mask->ipv6_mask.src_ip[1],
-   mask->ipv6_mask.src_ip[2], mask->ipv6_mask.src_ip[3],
-   mask->ipv6_mask.dst_ip[0], mask->ipv6_mask.dst_ip[1],
-   mask->ipv6_mask.dst_ip[2], mask->ipv6_mask.dst_ip[3]);
+   printf("\nvlan_tci: 0x%04x, ", mask->vlan_tci_mask);
+
+   if (fdir_conf.mode == RTE_FDIR_MODE_PERFECT_MAC_VLAN)
+   printf("mac_addr: 0x%02x", mask->mac_addr_byte_mask);
+   else if (fdir_conf.mode == RTE_FDIR_MODE_PERFECT_TUNNEL)
+   printf("mac_addr: 0x%02x, tunnel_type: 0x%01x, tunnel_id: 
0x%08x",
+   mask->mac_addr_byte_mask, mask->tunnel_type_mask,
+   mask->tunnel_id_mask);
+   else {
+   printf("src_ipv4: 0x%08x, dst_ipv4: 0x%08x,"
+   " src_port: 0x%04x, dst_port: 0x%04x",
+   mask->ipv4_mask.src_ip, mask->ipv4_mask.dst_ip,
+   mask->src_port_mask, mask->dst_port_mask);
+
+   printf("\nsrc_ipv6: 0x%08x,0x%08x,0x%08x,0x%08x,"
+   " dst_ipv6: 0x%08x,0x%08x,0x%08x,0x%08x",
+   mask->ipv6_mask.src_ip[0], mask->ipv6_mask.src_ip[1],
+   mask->ipv6_mask.src_ip[2], mask->ipv6_mask.src_ip[3],
+   mask->ipv6_mask.dst_ip[0], mask->ipv6_mask.dst_ip[1],
+   mask->ipv6_mask.dst_ip[2], mask->ipv6_mask.dst_ip[3]);
+   }
+
printf("\n");
 }

@@ -1966,12 +1976,19 @@ fdir_get_infos(portid_t port_id)
printf("  MODE: ");
if (fdir_info.mode == RTE_FDIR_MODE_PERFECT)
printf("  PERFECT\n");
+   else if (fdir_info.mode == RTE_FDIR_MODE_PERFECT_MAC_VLAN)
+   printf("  PERFECT-MAC-VLAN\n");
+   else if (fdir_info.mode == RTE_FDIR_MODE_PERFECT_TUNNEL)
+   printf("  PERFECT-TUNNEL\n");
else if (fdir_info.mode == RTE_FDIR_MODE_SIGNATURE)
printf("  SIGNATURE\n");
else
printf("  DISABLE\n");
-   printf("  SUPPORTED FLOW TYPE: ");
-   print_fdir_flow_type(fdir_info.flow_types_mask[0]);
+   if (fdir_info.mode != RTE_FDIR_MODE_PERFECT_MAC_VLAN
+   && fdir_info.mode != RTE_FDIR_MODE_PERFECT_TUNNEL) {
+   printf("  SUPPORTED FLOW TYPE: ");
+   print_fdir_flow_type(fdir_info.flow_types_mask[0]);
+   }
printf("  FLEX PAYLOAD INFO:\n");
printf("  max_len:   %-10"PRIu32"  payload_limit: %-10"PRIu32"\n"
   "  payload_unit:  %-10"PRIu32"  payload_seg:   %-10"PRIu32"\n"
-- 
1.9.3

[dpdk-dev] [PATCH v5 3/7] app/testpmd: new fdir modes for testpmd parameter

[Wenzhuo Lu]

For testpmd CLI's parameter pkt-filter-mode, there're new values supported for
fdir new modes, perfect-mac-vlan, perfect-tunnel.

Signed-off-by: Wenzhuo Lu 
---
 app/test-pmd/parameters.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index f1daa6e..df16e8f 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -707,12 +707,17 @@ launch_args_parse(int argc, char** argv)
RTE_FDIR_MODE_SIGNATURE;
else if (!strcmp(optarg, "perfect"))
fdir_conf.mode = RTE_FDIR_MODE_PERFECT;
+   else if (!strcmp(optarg, "perfect-mac-vlan"))
+   fdir_conf.mode = 
RTE_FDIR_MODE_PERFECT_MAC_VLAN;
+   else if (!strcmp(optarg, "perfect-tunnel"))
+   fdir_conf.mode = 
RTE_FDIR_MODE_PERFECT_TUNNEL;
else if (!strcmp(optarg, "none"))
fdir_conf.mode = RTE_FDIR_MODE_NONE;
else
rte_exit(EXIT_FAILURE,
 "pkt-mode-invalid %s invalid - 
must be: "
-"none, signature or perfect\n",
+"none, signature, perfect, 
perfect-mac-vlan"
+" or perfect-tunnel\n",
 optarg);
}
if (!strcmp(lgopts[opt_idx].name,
-- 
1.9.3

[dpdk-dev] [PATCH v5 2/7] app/testpmd: initialize the new fields for fdir mask

[Wenzhuo Lu]

When a port is enabled, there're default values for the parameters of
fdir mask. For the new parameters, the default values also need to be
set.

Signed-off-by: Wenzhuo Lu 
---
 app/test-pmd/testpmd.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 386bf84..d34c81a 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -298,6 +298,9 @@ struct rte_fdir_conf fdir_conf = {
},
.src_port_mask = 0x,
.dst_port_mask = 0x,
+   .mac_addr_byte_mask = 0xFF,
+   .tunnel_type_mask = 1,
+   .tunnel_id_mask = 0x,
},
.drop_queue = 127,
 };
-- 
1.9.3

[dpdk-dev] [PATCH v5 1/7] lib/librte_ether: modify the structures for fdir new modes

[Wenzhuo Lu]

Define the new modes and modify the filter and mask structures for
the mac vlan and tunnel modes.

Signed-off-by: Wenzhuo Lu 
---
 lib/librte_ether/rte_eth_ctrl.h | 33 +
 1 file changed, 33 insertions(+)

diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 26b7b33..770c76c 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -377,6 +377,32 @@ struct rte_eth_sctpv6_flow {
 };

 /**
+ * A structure used to define the input for MAC VLAN flow
+ */
+struct rte_eth_mac_vlan_flow {
+   struct ether_addr mac_addr;  /**< Mac address to match. */
+};
+
+/**
+ * Tunnel type for flow director.
+ */
+enum rte_eth_fdir_tunnel_type {
+   RTE_FDIR_TUNNEL_TYPE_UNKNOWN = 0,
+   RTE_FDIR_TUNNEL_TYPE_NVGRE,
+   RTE_FDIR_TUNNEL_TYPE_VXLAN,
+};
+
+/**
+ * A structure used to define the input for tunnel flow, now it's VxLAN or
+ * NVGRE
+ */
+struct rte_eth_tunnel_flow {
+   enum rte_eth_fdir_tunnel_type tunnel_type; /**< Tunnel type to match. */
+   uint32_t tunnel_id;/**< Tunnel ID to match. 
TNI, VNI... */
+   struct ether_addr mac_addr;/**< Mac address to match. */
+};
+
+/**
  * An union contains the inputs for all types of flow
  */
 union rte_eth_fdir_flow {
@@ -389,6 +415,8 @@ union rte_eth_fdir_flow {
struct rte_eth_tcpv6_flow  tcp6_flow;
struct rte_eth_sctpv6_flow sctp6_flow;
struct rte_eth_ipv6_flow   ipv6_flow;
+   struct rte_eth_mac_vlan_flow mac_vlan_flow;
+   struct rte_eth_tunnel_flow   tunnel_flow;
 };

 /**
@@ -465,6 +493,9 @@ struct rte_eth_fdir_masks {
struct rte_eth_ipv6_flow   ipv6_mask;
uint16_t src_port_mask;
uint16_t dst_port_mask;
+   uint8_t mac_addr_byte_mask;  /** Per byte MAC address mask */
+   uint32_t tunnel_id_mask;  /** tunnel ID mask */
+   uint8_t tunnel_type_mask;
 };

 /**
@@ -522,6 +553,8 @@ enum rte_fdir_mode {
RTE_FDIR_MODE_NONE  = 0, /**< Disable FDIR support. */
RTE_FDIR_MODE_SIGNATURE, /**< Enable FDIR signature filter mode. */
RTE_FDIR_MODE_PERFECT,   /**< Enable FDIR perfect filter mode. */
+   RTE_FDIR_MODE_PERFECT_MAC_VLAN, /**< Enable FDIR filter mode - MAC 
VLAN. */
+   RTE_FDIR_MODE_PERFECT_TUNNEL,   /**< Enable FDIR filter mode - tunnel. 
*/
 };

 #define UINT32_BIT (CHAR_BIT * sizeof(uint32_t))
-- 
1.9.3

[dpdk-dev] [PATCH v5 0/7] Support new flow director modes on Intel x550 NIC

[Wenzhuo Lu]

This patch set adds 2 new flow director modes on Intel x550 NIC.
The 2 new fdir modes are mac vlan mode and tunnel mode.
The mac vlan mode can direct the flow based on the MAC address and VLAN
TCI.
The tunnel mode provides the support for VxLAN and NVGRE. x550 can recognize
VxLAN and NVGRE packets, and direct the packets based on the MAC address,
VLAN TCI, TNI/VNI.
Surely, the MAC address, VLAN TCI, TNI/VNI can be masked, so, the flow
can be directed based on the left conditions. For example, if we want to
direct the flow based on the MAC address, we can use mac vlan mode with
VLAN TCI masked.
Now, only x550 supports these 2 modes. We should not use the new mode on
other NICs. If so, the ports will not be initialized successfully.

V2:
Change the word 'cloud' to 'tunnel'.
Change 'tni_vni' to 'tunnel_id'.

V3:
Change the name mac_addr_mask to mac_addr_byte_mask, for some NICs may like
to support per bit mask in future.
Set default VxLAN port only when the NIC support VxLAN.
Make the condition more strict when check the fdir mode for avoiding the code
being broken with future expansion.
Make mac mask more flexible.
Add a new function for MAC VLAN and tunnel mask.

V4:
Have replaced the enum rte_fdir_mode to resolve a compile issue. But after all
this code change, there's no such issue. Move the enum back to its original
place.

V5:
Remove some blank spaces.
Adjust the value of RTE_FDIR_TUNNEL_TYPE_UNKNOWN to 0.

Wenzhuo Lu (7):
  lib/librte_ether: modify the structures for fdir new modes
  app/testpmd: initialize the new fields for fdir mask
  app/testpmd: new fdir modes for testpmd parameter
  app/testpmd: modify the output of the CLI show port fdir
  app/testpmd: modify and add fdir filter and mask CLIs for new modes
  ixgbe: implementation for fdir new modes' config
  doc: release notes update for flow director enhancement

 app/test-pmd/cmdline.c   | 294 +--
 app/test-pmd/config.c|  45 --
 app/test-pmd/parameters.c|   7 +-
 app/test-pmd/testpmd.c   |   3 +
 doc/guides/rel_notes/release_2_2.rst |   3 +
 drivers/net/ixgbe/ixgbe_ethdev.h |   3 +
 drivers/net/ixgbe/ixgbe_fdir.c   | 262 +++
 lib/librte_ether/rte_eth_ctrl.h  |  33 
 8 files changed, 590 insertions(+), 60 deletions(-)

-- 
1.9.3

[dpdk-dev] [PATCH v2 2/2] doc: release note update for Boulder Rapid Support

[Michael Qiu]

Update the release note for Intel's new NIC Boulder Rapid.

Signed-off-by: Michael Qiu 
---
 doc/guides/rel_notes/release_2_2.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/guides/rel_notes/release_2_2.rst 
b/doc/guides/rel_notes/release_2_2.rst
index ab1c25f..7b34786 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -9,6 +9,9 @@ New Features
   *  Added support for Jumbo Frames.
   *  Optimize forwarding performance for Chelsio T5 40GbE cards.

+* **Intel new NIC Boulder Rapid support.**
+
+  Boulder Rapid is a new NIC of Intel's fm10k family.

 Resolved Issues
 ---
-- 
1.9.3

[dpdk-dev] [PATCH v2 1/2] fm10k: add Intel Boulder Rapid NIC support

[Michael Qiu]

Boulder Rapid is Intel new NIC within fm10k family.
This patch make DPDK driver support this new NIC.

Signed-off-by: Michael Qiu 
Acked-by : Jing Chen 
Acked-by : Shaopeng He 
---
 drivers/net/fm10k/base/fm10k_osdep.h| 4 
 lib/librte_eal/common/include/rte_pci_dev_ids.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/net/fm10k/base/fm10k_osdep.h 
b/drivers/net/fm10k/base/fm10k_osdep.h
index 64f09dc..4ba96f1 100644
--- a/drivers/net/fm10k/base/fm10k_osdep.h
+++ b/drivers/net/fm10k/base/fm10k_osdep.h
@@ -44,6 +44,10 @@ POSSIBILITY OF SUCH DAMAGE.
 /* TODO: this does not look like it should be used... */
 #define ERROR_REPORT2(v1, v2, v3)   do { } while (0)

+#ifndef BOULDER_RAPIDS_HW
+#define BOULDER_RAPIDS_HW
+#endif
+
 #define STATIC  static
 #define DEBUGFUNC(F)DEBUGOUT(F "\n");
 #define DEBUGOUT(S, args...)PMD_DRV_LOG_RAW(DEBUG, S, ##args)
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h 
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index 265e66c..5a44cbe 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -516,8 +516,10 @@ RTE_PCI_DEV_ID_DECL_I40E(PCI_VENDOR_ID_INTEL, 
I40E_DEV_ID_10G_BASE_T4)
 /*** Physical FM10K devices from fm10k_type.h ***/

 #define FM10K_DEV_ID_PF   0x15A4
+#define FM10K_DEV_ID_SDI_FM10420_QDA2 0x15D0

 RTE_PCI_DEV_ID_DECL_FM10K(PCI_VENDOR_ID_INTEL, FM10K_DEV_ID_PF)
+RTE_PCI_DEV_ID_DECL_FM10K(PCI_VENDOR_ID_INTEL, FM10K_DEV_ID_SDI_FM10420_QDA2)

 /** Virtual IGB devices from e1000_hw.h **/

-- 
1.9.3

[dpdk-dev] [PATCH v2 0/2] Intel new NIC Boulder Rapid support

[Michael Qiu]

Boulder Rapid is a new 100G NIC of Intel fm10k family, this patch
set enable it in DPDK.

change log:
V2 --> v1
update the release notes

Michael Qiu (2):
  fm10k: add Intel Boulder Rapid NIC support
  doc: release note update for Boulder Rapid Support

 doc/guides/rel_notes/release_2_2.rst| 3 +++
 drivers/net/fm10k/base/fm10k_osdep.h| 4 
 lib/librte_eal/common/include/rte_pci_dev_ids.h | 2 ++
 3 files changed, 9 insertions(+)

-- 
1.9.3

[dpdk-dev] [PATCH v1 0/3] lpm: increase number of next hops for lpm (ipv4)

[Jastrzebski, MichalX K]

> -Original Message-
> From: Matthew Hall [mailto:mhall at mhcomputing.net]
> Sent: Saturday, October 24, 2015 8:10 AM
> To: Jastrzebski, MichalX K; Kobylinski, MichalX
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v1 0/3] lpm: increase number of next hops
> for lpm (ipv4)
> 
> On 10/23/15 9:20 AM, Matthew Hall wrote:
> > On Fri, Oct 23, 2015 at 03:51:48PM +0200, Michal Jastrzebski wrote:
> >> From: Michal Kobylinski  
> >>
> >> The current DPDK implementation for LPM for IPv4 and IPv6 limits the
> >> number of next hops to 256, as the next hop ID is an 8-bit long field.
> >> Proposed extension increase number of next hops for IPv4 to 2^24 and
> >> also allows 32-bits read/write operations.
> >>
> >> This patchset requires additional change to rte_table library to meet
> >> ABI compatibility requirements. A v2 will be sent next week.
> >
> > I also have a patchset for this.
> >
> > I will send it out as well so we could compare.
> >
> > Matthew.
> 
> Sorry about the delay; I only work on DPDK in personal time and not as
> part of a job. My patchset is attached to this email.
> 
> One possible advantage with my patchset, compared to others, is that the
> space problem is fixed in both IPV4 and in IPV6, to prevent asymmetry
> between these two standards, which is something I try to avoid as much
> as humanly possible.
> 
> This is because my application code is green-field, so I absolutely
> don't want to put any ugly hacks or incompatibilities in this code if I
> can possibly avoid it.
> 
> Otherwise, I am not necessarily as expert about rte_lpm as some of the
> full-time guys, but I think with four or five of us in the thread
> hammering out patches we will be able to create something amazing
> together and I am very very very very very happy about this.
> 
> Matthew.

Hi Matthew,
Thank You for a patch-set.
I can't apply patch 0001-... , could You check it please? 
I have the following error:

Checking patch lib/librte_lpm/rte_lpm.h...
error: while searching for:
#endif

/** @internal bitmask with valid and ext_entry/valid_group fields set */
#define RTE_LPM_VALID_EXT_ENTRY_BITMASK 0x0300

/** Bitmask used to indicate successful lookup */
#define RTE_LPM_LOOKUP_SUCCESS  0x0100

#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
/** @internal Tbl24 entry structure. */
struct rte_lpm_tbl24_entry {
/* Stores Next hop or group index (i.e. gindex)into tbl8. */
union {
uint8_t next_hop;
uint8_t tbl8_gindex;
};
/* Using single uint8_t to store 3 values. */
uint8_t valid :1; /**< Validation flag. */
uint8_t ext_entry :1; /**< External entry. */
uint8_t depth :6; /**< Rule depth. */
};

/** @internal Tbl8 entry structure. */
struct rte_lpm_tbl8_entry {
uint8_t next_hop; /**< next hop. */
/* Using single uint8_t to store 3 values. */
uint8_t valid   :1; /**< Validation flag. */
uint8_t valid_group :1; /**< Group validation flag. */
uint8_t depth   :6; /**< Rule depth. */
};
#else
struct rte_lpm_tbl24_entry {

error: patch failed: lib/librte_lpm/rte_lpm.h:82
error: lib/librte_lpm/rte_lpm.h: patch does not apply

Best regards,
Michal

[dpdk-dev] [PATCH v1 0/3] lpm: increase number of next hops for lpm (ipv4)

[Jastrzebski, MichalX K]

> -Original Message-
> From: Michal Jastrzebski [mailto:michalx.k.jastrzebski at intel.com]
> Sent: Monday, October 26, 2015 12:55 PM
> To: Vladimir Medvedkin
> Subject: Re: [dpdk-dev] [PATCH v1 0/3] lpm: increase number of next hops
> for lpm (ipv4)
> 
> On Sun, Oct 25, 2015 at 08:52:04PM +0300, Vladimir Medvedkin wrote:
> > Hi all,
> >
> > Here my implementation
> >
> > Signed-off-by: Vladimir Medvedkin 
> > ---
> >  config/common_bsdapp |   1 +
> >  config/common_linuxapp   |   1 +
> >  lib/librte_lpm/rte_lpm.c | 194
> > +--
> >  lib/librte_lpm/rte_lpm.h | 163 +++
> >  4 files changed, 219 insertions(+), 140 deletions(-)
> >
> > diff --git a/config/common_bsdapp b/config/common_bsdapp
> > index b37dcf4..408cc2c 100644
> > --- a/config/common_bsdapp
> > +++ b/config/common_bsdapp
> > @@ -344,6 +344,7 @@ CONFIG_RTE_LIBRTE_JOBSTATS=y
> >  #
> >  CONFIG_RTE_LIBRTE_LPM=y
> >  CONFIG_RTE_LIBRTE_LPM_DEBUG=n
> > +CONFIG_RTE_LIBRTE_LPM_ASNUM=n
> >
> >  #
> >  # Compile librte_acl
> > diff --git a/config/common_linuxapp b/config/common_linuxapp
> > index 0de43d5..1c60e63 100644
> > --- a/config/common_linuxapp
> > +++ b/config/common_linuxapp
> > @@ -352,6 +352,7 @@ CONFIG_RTE_LIBRTE_JOBSTATS=y
> >  #
> >  CONFIG_RTE_LIBRTE_LPM=y
> >  CONFIG_RTE_LIBRTE_LPM_DEBUG=n
> > +CONFIG_RTE_LIBRTE_LPM_ASNUM=n
> >
> >  #
> >  # Compile librte_acl
> > diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
> > index 163ba3c..363b400 100644
> > --- a/lib/librte_lpm/rte_lpm.c
> > +++ b/lib/librte_lpm/rte_lpm.c
> > @@ -159,9 +159,11 @@ rte_lpm_create(const char *name, int socket_id,
> int
> > max_rules,
> >
> > lpm_list = RTE_TAILQ_CAST(rte_lpm_tailq.head, rte_lpm_list);
> >
> > -   RTE_BUILD_BUG_ON(sizeof(struct rte_lpm_tbl24_entry) != 2);
> > -   RTE_BUILD_BUG_ON(sizeof(struct rte_lpm_tbl8_entry) != 2);
> > -
> > +#ifdef RTE_LIBRTE_LPM_ASNUM
> > +   RTE_BUILD_BUG_ON(sizeof(struct rte_lpm_tbl_entry) != 8);
> > +#else
> > +   RTE_BUILD_BUG_ON(sizeof(struct rte_lpm_tbl_entry) != 4);
> > +#endif
> > /* Check user arguments. */
> > if ((name == NULL) || (socket_id < -1) || (max_rules == 0)){
> > rte_errno = EINVAL;
> > @@ -261,7 +263,7 @@ rte_lpm_free(struct rte_lpm *lpm)
> >   */
> >  static inline int32_t
> >  rule_add(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t depth,
> > -   uint8_t next_hop)
> > +   struct rte_lpm_res *res)
> >  {
> > uint32_t rule_gindex, rule_index, last_rule;
> > int i;
> > @@ -282,8 +284,11 @@ rule_add(struct rte_lpm *lpm, uint32_t
> ip_masked,
> > uint8_t depth,
> >
> > /* If rule already exists update its next_hop and
> > return. */
> > if (lpm->rules_tbl[rule_index].ip == ip_masked) {
> > -   lpm->rules_tbl[rule_index].next_hop =
> > next_hop;
> > -
> > +   lpm->rules_tbl[rule_index].next_hop =
> > res->next_hop;
> > +   lpm->rules_tbl[rule_index].fwd_class =
> > res->fwd_class;
> > +#ifdef RTE_LIBRTE_LPM_ASNUM
> > +   lpm->rules_tbl[rule_index].as_num =
> > res->as_num;
> > +#endif
> > return rule_index;
> > }
> > }
> > @@ -320,7 +325,11 @@ rule_add(struct rte_lpm *lpm, uint32_t
> ip_masked,
> > uint8_t depth,
> >
> > /* Add the new rule. */
> > lpm->rules_tbl[rule_index].ip = ip_masked;
> > -   lpm->rules_tbl[rule_index].next_hop = next_hop;
> > +   lpm->rules_tbl[rule_index].next_hop = res->next_hop;
> > +   lpm->rules_tbl[rule_index].fwd_class = res->fwd_class;
> > +#ifdef RTE_LIBRTE_LPM_ASNUM
> > +   lpm->rules_tbl[rule_index].as_num = res->as_num;
> > +#endif
> >
> > /* Increment the used rules counter for this rule group. */
> > lpm->rule_info[depth - 1].used_rules++;
> > @@ -382,10 +391,10 @@ rule_find(struct rte_lpm *lpm, uint32_t
> ip_masked,
> > uint8_t depth)
> >   * Find, clean and allocate a tbl8.
> >   */
> >  static inline int32_t
> > -tbl8_alloc(struct rte_lpm_tbl8_entry *tbl8)
> > +tbl8_alloc(struct rte_lpm_tbl_entry *tbl8)
> >  {
> > uint32_t tbl8_gindex; /* tbl8 group index. */
> > -   struct rte_lpm_tbl8_entry *tbl8_entry;
> > +   struct rte_lpm_tbl_entry *tbl8_entry;
> >
> > /* Scan through tbl8 to find a free (i.e. INVALID) tbl8 group. */
> > for (tbl8_gindex = 0; tbl8_gindex < RTE_LPM_TBL8_NUM_GROUPS;
> > @@ -393,12 +402,12 @@ tbl8_alloc(struct rte_lpm_tbl8_entry *tbl8)
> > tbl8_entry = [tbl8_gindex *
> >RTE_LPM_TBL8_GROUP_NUM_ENTRIES];
> > /* If a free tbl8 group is found clean it and set as VALID.
> > */
> > -   if (!tbl8_entry->valid_group) {
> > +   if (!tbl8_entry->ext_valid) {
> >   

[dpdk-dev] [PATCH v2 6/7] l3fwd-power: fix a memory leak for non-ip packet

[Shaopeng He]

Previous l3fwd-power only processes IP and IPv6 packet, other
packet's mbuf is not released, and causes a memory leak.
This patch fixes this issue.

Signed-off-by: Shaopeng He 
---
 examples/l3fwd-power/main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
index 8bb88ce..ecdff73 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -714,7 +714,8 @@ l3fwd_simple_forward(struct rte_mbuf *m, uint8_t portid,
/* We don't currently handle IPv6 packets in LPM mode. */
rte_pktmbuf_free(m);
 #endif
-   }
+   } else
+   rte_pktmbuf_free(m);

 }

-- 
1.9.3

[dpdk-dev] [PATCH v2 5/7] fm10k: make sure default VID available in dev_init

[Shaopeng He]

When PF establishes a connection with Switch Manager, it receives
a logic port range from SM, and registers certain logic ports from
that range, then a default VID will be send back from SM. This whole
transaction needs to be finished in dev_init, otherwise, in dev_start
the interrupt setting will be changed according to RX queue number,
and probably will cause this transaction failed.

Signed-off-by: Shaopeng He 
---
 drivers/net/fm10k/fm10k_ethdev.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index ce4d916..4823816 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -2355,6 +2355,21 @@ eth_fm10k_dev_init(struct rte_eth_dev *dev)

fm10k_mbx_unlock(hw);

+   /* Make sure default VID is ready before going forward. */
+   if (hw->mac.type == fm10k_mac_pf) {
+   for (i = 0; i < MAX_QUERY_SWITCH_STATE_TIMES; i++) {
+   if (hw->mac.default_vid)
+   break;
+   /* Delay some time to acquire async port VLAN info. */
+   rte_delay_us(WAIT_SWITCH_MSG_US);
+   }
+
+   if (!hw->mac.default_vid) {
+   PMD_INIT_LOG(ERR, "default VID is not ready");
+   return -1;
+   }
+   }
+
/* Add default mac address */
fm10k_MAC_filter_set(dev, hw->mac.addr, true);

-- 
1.9.3

[dpdk-dev] [PATCH v2 4/7] fm10k: add rx queue interrupt en/dis functions

[Shaopeng He]

Interrupt mode framework has enable/disable functions for individual
rx queue, this patch implements these two functions.

Signed-off-by: Shaopeng He 
---
 drivers/net/fm10k/fm10k_ethdev.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 45571f2..ce4d916 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -1821,6 +1821,37 @@ fm10k_dev_disable_intr_vf(struct rte_eth_dev *dev)
 }

 static int
+fm10k_dev_rx_queue_intr_enable(struct rte_eth_dev *dev, uint16_t queue_id)
+{
+   struct fm10k_hw *hw = FM10K_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   /* Enable ITR */
+   if (hw->mac.type == fm10k_mac_pf)
+   FM10K_WRITE_REG(hw, FM10K_ITR(Q2V(dev, queue_id)),
+   FM10K_ITR_AUTOMASK | FM10K_ITR_MASK_CLEAR);
+   else
+   FM10K_WRITE_REG(hw, FM10K_VFITR(Q2V(dev, queue_id)),
+   FM10K_ITR_AUTOMASK | FM10K_ITR_MASK_CLEAR);
+   rte_intr_enable(>pci_dev->intr_handle);
+   return 0;
+}
+
+static int
+fm10k_dev_rx_queue_intr_disable(struct rte_eth_dev *dev, uint16_t queue_id)
+{
+   struct fm10k_hw *hw = FM10K_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   /* Disable ITR */
+   if (hw->mac.type == fm10k_mac_pf)
+   FM10K_WRITE_REG(hw, FM10K_ITR(Q2V(dev, queue_id)),
+   FM10K_ITR_MASK_SET);
+   else
+   FM10K_WRITE_REG(hw, FM10K_VFITR(Q2V(dev, queue_id)),
+   FM10K_ITR_MASK_SET);
+   return 0;
+}
+
+static int
 fm10k_dev_rxq_interrupt_setup(struct rte_eth_dev *dev)
 {
struct fm10k_hw *hw = FM10K_DEV_PRIVATE_TO_HW(dev->data->dev_private);
@@ -2151,6 +2182,8 @@ static const struct eth_dev_ops fm10k_eth_dev_ops = {
.tx_queue_setup = fm10k_tx_queue_setup,
.tx_queue_release   = fm10k_tx_queue_release,
.rx_descriptor_done = fm10k_dev_rx_descriptor_done,
+   .rx_queue_intr_enable   = fm10k_dev_rx_queue_intr_enable,
+   .rx_queue_intr_disable  = fm10k_dev_rx_queue_intr_disable,
.reta_update= fm10k_reta_update,
.reta_query = fm10k_reta_query,
.rss_hash_update= fm10k_rss_hash_update,
-- 
1.9.3

[dpdk-dev] [PATCH v2 3/7] fm10k: remove rx queue interrupts when dev stops

[Shaopeng He]

Previous dev_stop function stops the rx/tx queues. This patch adds logic
to disable rx queue interrupt, clean the datapath event and queue/vec map.

Signed-off-by: Shaopeng He 
---
 drivers/net/fm10k/fm10k_ethdev.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 68ae1ba..45571f2 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -825,6 +825,8 @@ fm10k_dev_start(struct rte_eth_dev *dev)
 static void
 fm10k_dev_stop(struct rte_eth_dev *dev)
 {
+   struct fm10k_hw *hw = FM10K_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   struct rte_intr_handle *intr_handle = >pci_dev->intr_handle;
int i;

PMD_INIT_FUNC_TRACE();
@@ -836,6 +838,26 @@ fm10k_dev_stop(struct rte_eth_dev *dev)
if (dev->data->rx_queues)
for (i = 0; i < dev->data->nb_rx_queues; i++)
fm10k_dev_rx_queue_stop(dev, i);
+
+   /* Disable datapath event */
+   if (rte_intr_dp_is_en(intr_handle)) {
+   for (i = 0; i < dev->data->nb_rx_queues; i++) {
+   FM10K_WRITE_REG(hw, FM10K_RXINT(i),
+   3 << FM10K_RXINT_TIMER_SHIFT);
+   if (hw->mac.type == fm10k_mac_pf)
+   FM10K_WRITE_REG(hw, FM10K_ITR(Q2V(dev, i)),
+   FM10K_ITR_MASK_SET);
+   else
+   FM10K_WRITE_REG(hw, FM10K_VFITR(Q2V(dev, i)),
+   FM10K_ITR_MASK_SET);
+   }
+   }
+   /* Clean datapath event and queue/vec mapping */
+   rte_intr_efd_disable(intr_handle);
+   if (intr_handle->intr_vec != NULL) {
+   rte_free(intr_handle->intr_vec);
+   intr_handle->intr_vec = NULL;
+   }
 }

 static void
-- 
1.9.3

[dpdk-dev] [PATCH v2 1/7] fm10k: implement rx_descriptor_done function

[Shaopeng He]

rx_descriptor_done is used by interrupt mode example application
(l3fwd-power) to check rxd DD bit to decide the RX trend,
then l3fwd-power will adjust the cpu frequency according to
the result.

Signed-off-by: Shaopeng He 
---
 drivers/net/fm10k/fm10k.h|  3 +++
 drivers/net/fm10k/fm10k_ethdev.c |  1 +
 drivers/net/fm10k/fm10k_rxtx.c   | 25 +
 3 files changed, 29 insertions(+)

diff --git a/drivers/net/fm10k/fm10k.h b/drivers/net/fm10k/fm10k.h
index c089882..4fc5e8e 100644
--- a/drivers/net/fm10k/fm10k.h
+++ b/drivers/net/fm10k/fm10k.h
@@ -311,6 +311,9 @@ uint16_t fm10k_recv_pkts(void *rx_queue, struct rte_mbuf 
**rx_pkts,
 uint16_t fm10k_recv_scattered_pkts(void *rx_queue,
struct rte_mbuf **rx_pkts, uint16_t nb_pkts);

+int
+fm10k_dev_rx_descriptor_done(void *rx_queue, uint16_t offset);
+
 uint16_t fm10k_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
uint16_t nb_pkts);
 #endif
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index a69c990..a82cd59 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -2049,6 +2049,7 @@ static const struct eth_dev_ops fm10k_eth_dev_ops = {
.rx_queue_release   = fm10k_rx_queue_release,
.tx_queue_setup = fm10k_tx_queue_setup,
.tx_queue_release   = fm10k_tx_queue_release,
+   .rx_descriptor_done = fm10k_dev_rx_descriptor_done,
.reta_update= fm10k_reta_update,
.reta_query = fm10k_reta_query,
.rss_hash_update= fm10k_rss_hash_update,
diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
index d3f7b89..5c56fc2 100644
--- a/drivers/net/fm10k/fm10k_rxtx.c
+++ b/drivers/net/fm10k/fm10k_rxtx.c
@@ -354,6 +354,31 @@ fm10k_recv_scattered_pkts(void *rx_queue, struct rte_mbuf 
**rx_pkts,
return nb_rcv;
 }

+int
+fm10k_dev_rx_descriptor_done(void *rx_queue, uint16_t offset)
+{
+   volatile union fm10k_rx_desc *rxdp;
+   struct fm10k_rx_queue *rxq = rx_queue;
+   uint16_t desc;
+   int ret;
+
+   if (unlikely(offset >= rxq->nb_desc)) {
+   PMD_DRV_LOG(ERR, "Invalid RX queue id %u", offset);
+   return 0;
+   }
+
+   desc = rxq->next_dd + offset;
+   if (desc >= rxq->nb_desc)
+   desc -= rxq->nb_desc;
+
+   rxdp = >hw_ring[desc];
+
+   ret = !!(rxdp->w.status &
+   rte_cpu_to_le_16(FM10K_RXD_STATUS_DD));
+
+   return ret;
+}
+
 static inline void tx_free_descriptors(struct fm10k_tx_queue *q)
 {
uint16_t next_rs, count = 0;
-- 
1.9.3

[dpdk-dev] [PATCH v2 0/7] interrupt mode for fm10k

[Shaopeng He]

This patch series adds interrupt mode support for fm10k,
contains four major parts:

1. implement rx_descriptor_done function in fm10k
2. make sure default VID available in dev_init in fm10k
3. fix a memory leak for non-ip packet in l3fwd-power
4. add rx interrupt support in fm10k PF and VF

The patch set is developed based on one previous patch set
"[PATCH v1 00/11] interrupt mode for i40e"
http://www.dpdk.org/ml/archives/dev/2015-September/023903.html

Shaopeng He (7):
  fm10k: implement rx_descriptor_done function
  fm10k: setup rx queue interrupts for PF and VF
  fm10k: remove rx queue interrupts when dev stops
  fm10k: add rx queue interrupt en/dis functions
  fm10k: make sure default VID available in dev_init
  l3fwd-power: fix a memory leak for non-ip packet
  doc: release note update for fm10k intr mode

 doc/guides/rel_notes/release_2_2.rst |   2 +
 drivers/net/fm10k/fm10k.h|   3 +
 drivers/net/fm10k/fm10k_ethdev.c | 164 +--
 drivers/net/fm10k/fm10k_rxtx.c   |  25 ++
 examples/l3fwd-power/main.c  |   3 +-
 5 files changed, 189 insertions(+), 8 deletions(-)

-- 
1.9.3

[dpdk-dev] [PATCH v1 0/3] lpm: increase number of next hops for lpm (ipv4)

[Matthew Hall]

> I can't apply patch 0001-... , could You check it please? 

I generated it from a rebase of my own copy of DPDK against DPDK upstream 
master.

So I'm not sure why it would not apply against latest DPDK master.

But I will try it and see what could be the reason.

Matthew.

[dpdk-dev] [PATCH v8 0/8] vhost-user multiple queues enabling

[Yuanhan Liu]

On Mon, Oct 26, 2015 at 01:36:10AM +, Xie, Huawei wrote:
> On 10/22/2015 8:35 PM, Yuanhan Liu wrote:
> > This patch set enables vhost-user multiple queue feature.
> >
> >
> > ---
> > Changchun Ouyang (3):
> >   vhost: rxtx: use queue id instead of constant ring index
> >   virtio: fix deadloop due to reading virtio_net_config incorrectly
> >   vhost: add VHOST_USER_SET_VRING_ENABLE message
> >
> > Yuanhan Liu (5):
> >   vhost-user: add protocol features support
> >   vhost-user: add VHOST_USER_GET_QUEUE_NUM message
> >   vhost: vring queue setup for multiple queue support
> >   vhost-user: enable vhost-user multiple queue
> >   doc: update release note for vhost-user mq support
> >
> >  doc/guides/rel_notes/release_2_2.rst  |   4 +
> >  drivers/net/virtio/virtio_ethdev.c|  16 ++-
> >  lib/librte_vhost/rte_virtio_net.h |  13 +-
> >  lib/librte_vhost/vhost_rxtx.c |  53 +---
> >  lib/librte_vhost/vhost_user/vhost-net-user.c  |  25 +++-
> >  lib/librte_vhost/vhost_user/vhost-net-user.h  |   4 +
> >  lib/librte_vhost/vhost_user/virtio-net-user.c |  86 ++---
> >  lib/librte_vhost/vhost_user/virtio-net-user.h |  10 ++
> >  lib/librte_vhost/virtio-net.c | 168 
> > --
> >  9 files changed, 275 insertions(+), 104 deletions(-)
> >
> 
> Btw, Changchun's patch: "virtio: fix deadloop due to reading
> virtio_net_config incorrectly" isn't included, so probably, you could
> remove this from this cover-letter.

What do you mean by "isn't included"?

[PATCH v8 5/8] virtio: fix deadloop due to reading virtio_net_config 
incorrectly

> Acked-by: Huawei Xie 

Thanks.

--yliu

[dpdk-dev] [PATCH v2] net:bonding: fix free_queues function when no queues exist

[Yaacov Hazan]

From: Raslsn Darawsheh 

In case of creating bond device without add any slaves and
quit from testpmd, application crashed since rx/tx queues
are NULL.

add checking of this paramters before trying to free.

Signed-off-by: Raslsn Darawsheh 
Signed-off-by: Yaacov Hazan 
---
in previous patch there was mismatch in the solution.
this patch is the correct fix for the described bug

 drivers/net/bonding/rte_eth_bond_pmd.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c 
b/drivers/net/bonding/rte_eth_bond_pmd.c
index 5cc6372..383fdcf 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -1517,17 +1517,21 @@ bond_ethdev_free_queues(struct rte_eth_dev *dev)
 {
uint8_t i;

-   for (i = 0; i < dev->data->nb_rx_queues; i++) {
-   rte_free(dev->data->rx_queues[i]);
-   dev->data->rx_queues[i] = NULL;
+   if (dev->data->rx_queues != NULL) {
+   for (i = 0; i < dev->data->nb_rx_queues; i++) {
+   rte_free(dev->data->rx_queues[i]);
+   dev->data->rx_queues[i] = NULL;
+   }
+   dev->data->nb_rx_queues = 0;
}
-   dev->data->nb_rx_queues = 0;

-   for (i = 0; i < dev->data->nb_tx_queues; i++) {
-   rte_free(dev->data->tx_queues[i]);
-   dev->data->tx_queues[i] = NULL;
+   if (dev->data->tx_queues != NULL) {
+   for (i = 0; i < dev->data->nb_tx_queues; i++) {
+   rte_free(dev->data->tx_queues[i]);
+   dev->data->tx_queues[i] = NULL;
+   }
+   dev->data->nb_tx_queues = 0;
}
-   dev->data->nb_tx_queues = 0;
 }

 void
-- 
1.9.1

[dpdk-dev] [PATCH v5 5/7] virtio: virtio vec rx

[Wang, Zhihong]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Huawei Xie
> Sent: Sunday, October 25, 2015 11:35 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v5 5/7] virtio: virtio vec rx
> 
> With fixed avail ring, we don't need to get desc idx from avail ring.
> virtio driver only has to deal with desc ring.
> This patch uses vector instruction to accelerate processing desc ring.
> 
> Signed-off-by: Huawei Xie 

Acked-by: Wang, Zhihong 

[dpdk-dev] [PATCH 7/8] i40e: get_dcb_info ops implement

[Wu, Jingjing]

> -Original Message-
> From: Liu, Jijiang
> Sent: Thursday, October 22, 2015 3:10 PM
> To: Wu, Jingjing; dev at dpdk.org
> Cc: Zhang, Helin; Tao, Zhe; Pei, Yulong
> Subject: RE: [PATCH 7/8] i40e: get_dcb_info ops implement
> 
> 
> 
> > -Original Message-
> > From: Wu, Jingjing
> > Sent: Thursday, September 24, 2015 2:03 PM
> > To: dev at dpdk.org
> > Cc: Wu, Jingjing; Liu, Jijiang; Zhang, Helin; Tao, Zhe; Pei, Yulong
> > Subject: [PATCH 7/8] i40e: get_dcb_info ops implement
> >
> > This patch implements the get_dcb_info ops in i40e driver.
> >
> > Signed-off-by: Jingjing Wu 
> > ---
> >  drivers/net/i40e/i40e_ethdev.c | 42
> > ++
> >  1 file changed, 42 insertions(+)
> >
> 
> If there are some  command lines in testpmd to get DCB information, that is
> great.

Yes. Will think about it in V2 patch.

Thanks.
Jingjing 

[dpdk-dev] [PATCH v2 0/6] Xen DOM0 runtime support

[Liu, Jijiang]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen
> Hemminger
> Sent: Friday, October 23, 2015 2:35 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 0/6] Xen DOM0 runtime support
> 
> It should be possible to build a single application or library that will work 
> both
> in Xen and non-Xen environment. Any special case handling should be done
> at runtime.
> 
> Rebased to current DPDK source.
> 
> Stephen Hemminger (6):
>   xen: allow determining DOM0 at runtime
>   ethdev: add common function for reserving DMA regions
>   e1000: use rte_eth_dma_zone_reserve
>   ixgbe: use rte_eth_dma_zone_reserve
>   i40e: use rte_eth_dma_zone_reserve
>   fm10k: use rte_eth_dma_zone_reserve
> 
>  drivers/net/e1000/em_rxtx.c  | 38 ++-
>  drivers/net/e1000/igb_rxtx.c | 41 ++--
>  drivers/net/fm10k/fm10k_ethdev.c | 47 ++
>  drivers/net/i40e/i40e_ethdev.c   |  9 ---
>  drivers/net/i40e/i40e_fdir.c |  5 +-
>  drivers/net/i40e/i40e_rxtx.c | 94 
> ++--
>  drivers/net/ixgbe/ixgbe_rxtx.c   | 47 ++
>  lib/librte_eal/common/include/rte_memory.h   | 30 -
>  lib/librte_eal/linuxapp/eal/eal_memory.c |  7 +++
>  lib/librte_eal/linuxapp/eal/eal_xen_memory.c |  2 +-
>  lib/librte_ether/rte_ethdev.c| 24 +++
>  lib/librte_ether/rte_ethdev.h| 23 +++
>  lib/librte_mempool/rte_mempool.c | 48 +-
>  lib/librte_mempool/rte_mempool.h |  3 +-
>  14 files changed, 160 insertions(+), 258 deletions(-)
> 
> --
> 2.1.4

Acked-by: Jijiang Liu 

Thanks
Jijiang Liu

[dpdk-dev] [PATCH 0/8] add vhost TSO capability

[Tan, Jianfeng]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu
> Sent: Thursday, September 17, 2015 1:11 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 0/8] add vhost TSO capability
> 
> The patch set add the negotiation between us-vhost and virtio-net for vhost
> TSO feature, and enqueue/dequeue vhost TSO offload and change vhost
> sample and csum application to test these.
> 
> *** BLURB HERE ***
> 
> Jijiang Liu (8):
>   add host TSO support in virtio_ethdev.h file
>   add virtual addr for virtio net header in struct virtqueue.
>   record the virtual addr for virtio net header
>   enqueue TSO offload in virtio-net
>   extend VHOST_SUPPORTED_FEATURES list for TSO support
>   add TSO offload dequeue
>   TSO support in vhost sample
>   fix an issue in csum file.
> 
>  app/test-pmd/csumonly.c|6 ++
>  drivers/net/virtio/virtio_ethdev.c |3 +++
>  drivers/net/virtio/virtio_ethdev.h |4 +++-
>  drivers/net/virtio/virtio_rxtx.c   |   28 
>  drivers/net/virtio/virtqueue.h |1 +
>  examples/vhost/main.c  |   20 ++--
>  lib/librte_vhost/vhost_rxtx.c  |   29 -
>  lib/librte_vhost/virtio-net.c  |5 -
>  8 files changed, 91 insertions(+), 5 deletions(-)
> 
> --
> 1.7.7.6

Acked-by: Jianfeng Tan 

Thanks,
Jianfeng

[dpdk-dev] [PATCH 1/8] driver/virtio:add virtual addr for virtio net header

[Tan, Jianfeng]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu
> Sent: Wednesday, October 21, 2015 12:47 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 1/8] driver/virtio:add virtual addr for virtio net
> header
> 
> The virtual addr for virtio net header need to be recorded.
> 
> Signed-off-by: Jijiang Liu 
> ---
>  drivers/net/virtio/virtqueue.h |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/net/virtio/virtqueue.h b/drivers/net/virtio/virtqueue.h
> index 7789411..530f840 100644
> --- a/drivers/net/virtio/virtqueue.h
> +++ b/drivers/net/virtio/virtqueue.h
> @@ -189,6 +189,7 @@ struct virtqueue {
>   uint16_t vq_used_cons_idx;
>   uint16_t vq_avail_idx;
>   phys_addr_t virtio_net_hdr_mem; /**< hdr for each xmit packet */
> + uint64_t virtio_net_hdr_addr; /**< virtual addr for virtio net header
> +*/
> 
>   /* Statistics */
>   uint64_tpackets;
> --
> 1.7.7.6

Acked-by: Jianfeng Tan 

Thanks,
Jianfeng

[dpdk-dev] [PATCH 0/8] add vhost TX offload support

[Liu, Jijiang]

We have tested the following case on Intel 10G NIC using the patch set.

Test case Flow:
 Iperf app running on legacy virtio guest>DPDK vhost-> two physical 
ports loopback on a NIC > legacy vhost->iperf app running on a legacy 
virtio guest.

After enabling the vhost TSO and checksum offload,  there is about 60% 
throughput performance improvement.

And we will continue to test the performance after the patch set is applied.

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu
> Sent: Wednesday, October 21, 2015 12:47 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 0/8] add vhost TX offload support
> 
> In fact, this patch set is v2 of [1], but I consider that the vhost checksum
> offload capability is also supported in this version, and send a new patch set
> out.
> 
> The patch set add the negotiation between us-vhost and virtio-net for vhost
> TX offload(checksum and TSO), and add the TX offload support in the libs and
> change vhost sample and csum application to test these changes.
> 
> 
> [1]http://dpdk.org/ml/archives/dev/2015-September/023686.html
> 
> 
> Jijiang Liu (8):
>   add virtual address of virtio net header
>   store virtual address of virtio hdr
>   add vhost TX offload support capability in virtio-net
>   add vhost TX offload support capability in vhost
>   enqueue TX offload
>   dequeue TX offload
>   change vhost App to support TX offload
>   fix csumonly fwd issue
> 
>  app/test-pmd/csumonly.c|6 ++
>  drivers/net/virtio/virtio_ethdev.c |3 +
>  drivers/net/virtio/virtio_ethdev.h |5 +-
>  drivers/net/virtio/virtio_rxtx.c   |   61 +
>  drivers/net/virtio/virtqueue.h |1 +
>  examples/vhost/main.c  |  128
> +++-
>  lib/librte_vhost/vhost_rxtx.c  |  108 ++-
>  lib/librte_vhost/virtio-net.c  |6 ++-
>  8 files changed, 298 insertions(+), 20 deletions(-)
> 
> --
> 1.7.7.6

[dpdk-dev] [PATCH] librte: Link status interrupt race condition, IGB E1000

[Lu, Wenzhuo]

Hi Tim,

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Monday, October 26, 2015 6:56 AM
> To: Lu, Wenzhuo
> Cc: dev at dpdk.org; Tim Shearer
> Subject: Re: [dpdk-dev] [PATCH] librte: Link status interrupt race condition,
> IGB E1000
> 
> Wenzhuo,
> Please could you have a look?
> Thanks
> 
> 2015-09-24 20:44, Tim Shearer:
> > I encountered an issue with DPDK 2.1.0  which occasionally causes the link
> status interrupt callback not to be called after the interface is started for 
> the
> first time. I traced the problem back to the function eth_igb_link_update(),
> which is used to determine if the link has changed state since the previous
> time it was called. It appears that this function can be called simultaneously
> from two different threads:
> >
> > (1) From the main application/configuration thread, via rte_eth_dev_start()
> - pointed to by (*dev->dev_ops->link_update)
> > (2) From the eal interrupt thread, via eth_igb_interrupt_action(), to check
> if the link state has transitioned up or down. The user callback is only
> executed if the link has changed state.
> >
> > The race condition manifests itself as follows:
> >  - Main thread configures the interface with link status interrupt (LSI)
> enabled, sets up the queues etc.
> >  - Main thread calls rte_eth_dev_start. The interface is started and then we
> call eth_igb_link_update()
> >  - While in this call, the link goes up. Accordingly, we  detect the 
> > transition,
> and write the new link state (up) into the global rte_eth_dev struct
> >  - The interrupt fires, which also drops into the eth_igb_link_update
> function, finds that the global link status has already been set to up (no
> change)
> >  - Therefore, the handler thinks the interrupt was spurious, and the
> callback doesn't get called.
> >
> > I suspect that rte_eth_dev_start shouldn't be checking the link state if
> interrupts are enabled. Would someone mind taking a quick look at the
> patch below?
> >
> > Thanks!
> > Tim
> >
> > --- a/lib/librte_ether/rte_ethdev.c
> > +++ b/lib/librte_ether/rte_ethdev.c
> > @@ -1300,7 +1300,7 @@ rte_eth_dev_start(uint8_t port_id)
> >
> > rte_eth_dev_config_restore(port_id);
> >
> > -   if (dev->data->dev_conf.intr_conf.lsc != 0) {
> > +   if (dev->data->dev_conf.intr_conf.lsc == 0) {
> > FUNC_PTR_OR_ERR_RET(*dev->dev_ops->link_update, -
> ENOTSUP);
> > (*dev->dev_ops->link_update)(dev, 0);
> > }
> >
> >
> 
I think you're right. To my opinion, this if is added to avoid the race 
condition. So, it should be " dev->data->dev_conf.intr_conf.lsc == 0". It means 
if the interrupts are not enabled, we'd update the link when starting, if not 
we can leave it the interrupt handler.
Seems it's not an igb specific but common issue. 

[dpdk-dev] i40e: problem with rx packet drops not accounted in statistics

[Zhang, Helin]

Hi Arnon

Sorry for any inconvenience!
Yes, we knew that there are statistics issues there, and now in being fixed. 
Hopefully we can have some progress soon.
Thank you very much for reporting out that!

Regards,
Helin

From: Arnon Warshavsky [mailto:ar...@qwilt.com]
Sent: Monday, October 26, 2015 2:51 AM
To: Zhang, Helin
Cc: Martin Weiser; dev at dpdk.org; Eimear Morrissey
Subject: Re: [dpdk-dev] i40e: problem with rx packet drops not accounted in 
statistics

Hi Helin
I would like to add my input for this as well.
I encountered the same issue, and as you suggested I updated to the latest fw 
and changed rx and tx ring sizes to 1024.
Drop counters still do not increment as they should.
I Inject 10mpps into an x710 nic  (a 4 ports card, 10mpps on each port) read by 
a simple rx-only dpdk app.
I read 10mpps from the in-packets counter ,  not getting any drop counters 
incrementing , while my application counts only 8 mpps per port that are 
actually arriving to the app.
Running the same on x520 I get 8 mpps from the in-packets counter and 2 mpps 
from dropped packets as it should.
Something seems to be broken in the error/discard accounting.

/Arnon


On Fri, Oct 23, 2015 at 3:42 AM, Zhang, Helin mailto:helin.zhang at intel.com>> wrote:
Hi Martin

Could you help to try bigger size of rx/tx ring, but not the default sizes?
For example, could you help to try 1024 for RX ring size, and 512 or 1024 for 
TX ring size.

In addition, please make sure you are using the latest version of NIC firmware.

Regards,
Helin

> -Original Message-
> From: Martin Weiser [mailto:martin.weiser at 
> allegro-packets.com]
> Sent: Thursday, October 22, 2015 3:59 PM
> To: Zhang, Helin
> Cc: dev at dpdk.org
> Subject: Re: i40e: problem with rx packet drops not accounted in statistics
>
> Hi Helin,
>
> good to know that there is work being done on that issue.
> By performance problem I mean that theses packet discards start to appear at
> low bandwidths where I would not expect any packets to be dropped. On the
> same system we can reach higher bandwidths using ixgbe NICs without loosing a
> single packet so seeing packets being lost at only ~5GBit/s and ~1.5Mpps on a
> 40Gb adapter worries me a bit.
>
> Best regards,
> Martin
>
>
> On 22.10.15 02:16, Zhang, Helin wrote:
> > Hi Martin
> >
> > Yes, we have a developer working on it now, and hopefully he will have
> something soon later on this fix.
> > But what do you mean the performance problem? Did you mean the
> performance number is not good as expected, or else?
> >
> > Regards,
> > Helin
> >
> >> -Original Message-
> >> From: Martin Weiser [mailto:martin.weiser at 
> >> allegro-packets.com]
> >> Sent: Wednesday, October 21, 2015 4:44 PM
> >> To: Zhang, Helin
> >> Cc: dev at dpdk.org
> >> Subject: Re: i40e: problem with rx packet drops not accounted in
> >> statistics
> >>
> >> Hi Helin,
> >>
> >> any news on this issue? By the way this is not just a problem with
> >> statistics for us but also a performance problem since these packet
> >> discards start appearing at a relatively low bandwidth (~5GBit/s and
> ~1.5Mpps).
> >>
> >> Best regards,
> >> Martin
> >>
> >> On 10.09.15 03:09, Zhang, Helin wrote:
> >>> Hi Martin
> >>>
> >>> Yes, the statistics issue has been reported several times recently.
> >>> We will check the issue and try to fix it or get a workaround soon.
> >>> Thank you
> >> very much!
> >>> Regards,
> >>> Helin
> >>>
>  -Original Message-
>  From: Martin Weiser [mailto:martin.weiser at 
>  allegro-packets.com]
>  Sent: Wednesday, September 9, 2015 7:58 PM
>  To: Zhang, Helin
>  Cc: dev at dpdk.org
>  Subject: i40e: problem with rx packet drops not accounted in
>  statistics
> 
>  Hi Helin,
> 
>  in one of our test setups involving i40e adapters we are
>  experiencing packet drops which are not reflected in the interfaces
> statistics.
>  The call to rte_eth_stats_get suggests that all packets were
>  properly received but the total number of packets received through
>  rte_eth_rx_burst is less than the ipackets counter.
>  When for example running the l2fwd application (l2fwd -c 0xfe -n 4
>  -- -p
>  0x3) and having driver debug messages enabled the following output
>  is generated for the interface in question:
> 
>  ...
>  PMD: i40e_update_vsi_stats(): * VSI[6] stats start
>  ***
>  PMD: i40e_update_vsi_stats(): rx_bytes:24262434
>  PMD: i40e_update_vsi_stats(): rx_unicast:  16779
>  PMD: i40e_update_vsi_stats(): rx_multicast:0
>  PMD: i40e_update_vsi_stats(): rx_broadcast:0
>  PMD: i40e_update_vsi_stats(): rx_discards: 1192557
>  

[dpdk-dev] [PATCH v5 3/4] vhost: using EVENTFD_COPY2

[Xie, Huawei]

On 10/21/2015 8:16 PM, Pavel Boldin wrote:
> Xie,
>
> Please find my comments intermixed below.
>
> On Tue, Oct 20, 2015 at 12:52 PM, Xie, Huawei  > wrote:
>
> Thanks Pavel for this work.
> This is what we think is the better implementation for eventfd
> proxy, in
> our last review.
> Could you add an additional patch to remove the old implementation?
>
> I'm not really sure if we should do it -- imagine upgrading from one
> version of DPDK to another.
> Given the current implementation there is a backward compatibility.
I couldn't image the case any one would run old dpdk app with the new
dpdk module. However I am ok you leave it here, :), we could remove this
in next release.
Could you finish rebasing the patch before end of next week, otherwise
it will lose chance of being merged.
>  
>
>
> Again, please run checkpatch.pl  against
> your patch.
>
> Oops. Thanks for pointing out.
>  
>
> On 8/29/2015 2:51 AM, Pavel Boldin wrote:
>
> [...]
> > +
> > +int
> > +eventfd_init(void)
> > +{
> > + if (eventfd_link > 0)
> 0 could be valid fd. Change it to:
>
> Got it. Thanks.
>  
>
> if (eventfd_link >= 0)
> Change elsewhere if i miss it.
> > +int
> > +eventfd_free(void)
> > +{
> > + if (eventfd_link > 0)
> same as above:
> if (eventfd_link >= 0)
>
> [...]
>
>
> --
> Sincerely,
>  Pavel

[dpdk-dev] [PATCH v8 0/8] vhost-user multiple queues enabling

[Xie, Huawei]

On 10/22/2015 8:35 PM, Yuanhan Liu wrote:
> This patch set enables vhost-user multiple queue feature.
>
>
> ---
> Changchun Ouyang (3):
>   vhost: rxtx: use queue id instead of constant ring index
>   virtio: fix deadloop due to reading virtio_net_config incorrectly
>   vhost: add VHOST_USER_SET_VRING_ENABLE message
>
> Yuanhan Liu (5):
>   vhost-user: add protocol features support
>   vhost-user: add VHOST_USER_GET_QUEUE_NUM message
>   vhost: vring queue setup for multiple queue support
>   vhost-user: enable vhost-user multiple queue
>   doc: update release note for vhost-user mq support
>
>  doc/guides/rel_notes/release_2_2.rst  |   4 +
>  drivers/net/virtio/virtio_ethdev.c|  16 ++-
>  lib/librte_vhost/rte_virtio_net.h |  13 +-
>  lib/librte_vhost/vhost_rxtx.c |  53 +---
>  lib/librte_vhost/vhost_user/vhost-net-user.c  |  25 +++-
>  lib/librte_vhost/vhost_user/vhost-net-user.h  |   4 +
>  lib/librte_vhost/vhost_user/virtio-net-user.c |  86 ++---
>  lib/librte_vhost/vhost_user/virtio-net-user.h |  10 ++
>  lib/librte_vhost/virtio-net.c | 168 
> --
>  9 files changed, 275 insertions(+), 104 deletions(-)
>

Btw, Changchun's patch: "virtio: fix deadloop due to reading
virtio_net_config incorrectly" isn't included, so probably, you could
remove this from this cover-letter.

Acked-by: Huawei Xie 

[dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs

[Zhang, Helin]

> -Original Message-
> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
> Sent: Friday, October 23, 2015 5:00 PM
> To: Zhang, Helin
> Cc: Lu, Wenzhuo; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs
> 
> 
> 
> On 10/23/15 11:32, Zhang, Helin wrote:
> >
> >> -Original Message-
> >> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
> >> Sent: Friday, October 23, 2015 4:27 PM
> >> To: Zhang, Helin
> >> Cc: Lu, Wenzhuo; dev at dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames
> >> from VFs
> >>
> >>
> >>
> >> On 10/23/15 10:14, Zhang, Helin wrote:
> >>> From: Vladislav Zolotarov [mailto:vladz at cloudius-systems.com]
> >>> Sent: Friday, October 23, 2015 2:57 PM
> >>> To: Zhang, Helin
> >>> Cc: Lu, Wenzhuo; dev at dpdk.org
> >>> Subject: RE: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames
> >>> from VFs
> >>>
> >>>
> >>> On Oct 23, 2015 9:30 AM, "Zhang, Helin"  wrote:
> 
>  From: Vladislav Zolotarov [mailto:vladz at cloudius-systems.com]
>  Sent: Friday, October 23, 2015 2:24 PM
>  To: Zhang, Helin
>  Cc: Lu, Wenzhuo; dev at dpdk.org
>  Subject: Re: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames
>  from VFs
> 
> 
>  On Oct 23, 2015 9:02 AM, "Zhang, Helin"  wrote:
> >
> >> -Original Message-
> >> From: Lu, Wenzhuo
> >> Sent: Friday, October 23, 2015 1:52 PM
> >> To: dev at dpdk.org
> >> Cc: Zhang, Helin; Lu, Wenzhuo
> >> Subject: [PATCH v4] ixgbe: Drop flow control frames from VFs
> >>
> >> This patch will drop flow control frames from being transmitted from
> VSIs.
> >> With this patch in place a malicious VF cannot send flow control
> >> or PFC packets out on the wire.
>  The whole idea of this (and similar i40e patches sent before) is
>  really
> >> confusing.
>  If u want to disable FC feature for VFs then go and disable the
>  feature. Why
> >> keep (not malicious) user think that he/she has enabled the feature
> >> while u silently block it?
>  Helin: I don't think disabling FC is equal to filtering out any
>  pause frames. How
> >> about the software application constructs a pause frame and then
> >> tries to send it out?
> >>> But not disabling FC for the user and silently preventing it is
> >>> bogus. First, the
> >> conventional user should not be affected. I think this patch (and all
> >> its clones) should be extended to, first, disable the FC Tx feature
> >> for the relevant devices and only then adding any anti malicious filtering.
> >>> Helin: Disabling FC will disable both PF and VF FC, I don't find out
> >>> where can
> >> disable VF FC only. Am I wrong?
> >>
> >> There are flow_ctrl_get/set callbacks in eth_dev_ops which are used
> >> for configuring FC.
> >> I see that they are not set for either ixgbevf or i40evf, so here we
> >> are all set for these.
> > Helin: The behaviors rely on the hardware capability, but not the SW.
> > I meant I don't think it can support disabling VF FC. Please correct me in 
> > case I
> am wrong!
> 
> I see. After a shallow sweep on the x540 and xl710 specs it seems that u r 
> right.
> However I was talking about the SW interface only and since it is not enabled 
> for
> the devices in question my whole objection is removed.
> 
> thanks,
> vlad

Vlad, thank you very much!
The best way for this issue is to do that in hardware, but now we need a 
fix/workaround.
It is really good to have the discussion with you, and clarify a lot. I think 
it can also remove a lot of questions from others. Thank you!

Regards,
Helin

> 
> >
> >
> >> V2:
> >> Reword the comments.
> >>
> >> V3:
> >> Move the check of set_ethertype_anti_spoofing to the top of the
> >> function,
> >> to
> >> avoid occupying an ethertype_filter entity without using it.
> >>
> >> V4:
> >> Remove the useless braces and return.
> >>
> >> Signed-off-by: Wenzhuo Lu 
> > Acked-by: Helin Zhang 
> >

[dpdk-dev] [PATCH] librte: Link status interrupt race condition, IGB E1000

[Thomas Monjalon]

Wenzhuo,
Please could you have a look?
Thanks

2015-09-24 20:44, Tim Shearer:
> I encountered an issue with DPDK 2.1.0  which occasionally causes the link 
> status interrupt callback not to be called after the interface is started for 
> the first time. I traced the problem back to the function 
> eth_igb_link_update(), which is used to determine if the link has changed 
> state since the previous time it was called. It appears that this function 
> can be called simultaneously from two different threads:
> 
> (1) From the main application/configuration thread, via rte_eth_dev_start() - 
> pointed to by (*dev->dev_ops->link_update)
> (2) From the eal interrupt thread, via eth_igb_interrupt_action(), to check 
> if the link state has transitioned up or down. The user callback is only 
> executed if the link has changed state.
> 
> The race condition manifests itself as follows:
>  - Main thread configures the interface with link status interrupt (LSI) 
> enabled, sets up the queues etc.
>  - Main thread calls rte_eth_dev_start. The interface is started and then we 
> call eth_igb_link_update()
>  - While in this call, the link goes up. Accordingly, we  detect the 
> transition, and write the new link state (up) into the global rte_eth_dev 
> struct
>  - The interrupt fires, which also drops into the eth_igb_link_update 
> function, finds that the global link status has already been set to up (no 
> change)
>  - Therefore, the handler thinks the interrupt was spurious, and the callback 
> doesn't get called.
> 
> I suspect that rte_eth_dev_start shouldn't be checking the link state if 
> interrupts are enabled. Would someone mind taking a quick look at the patch 
> below?
> 
> Thanks!
> Tim
> 
> --- a/lib/librte_ether/rte_ethdev.c
> +++ b/lib/librte_ether/rte_ethdev.c
> @@ -1300,7 +1300,7 @@ rte_eth_dev_start(uint8_t port_id)
>  
> rte_eth_dev_config_restore(port_id);
>  
> -   if (dev->data->dev_conf.intr_conf.lsc != 0) {
> +   if (dev->data->dev_conf.intr_conf.lsc == 0) {
> FUNC_PTR_OR_ERR_RET(*dev->dev_ops->link_update, -ENOTSUP);
> (*dev->dev_ops->link_update)(dev, 0);
> }
> 
> 

[dpdk-dev] [PATCH] eal: change to prevent memory leak in eal debug

[Thomas Monjalon]

2015-09-21 17:00, Zhe Tao:
> Free the memory allocated by the backtrace_symbols
>  to prevent the memory leak
> 
> Signed-off-by: Zhe Tao 

Applied, with reverted comparisons:

WARNING:CONSTANT_COMPARISON: Comparisons should place the constant on the right 
side of the test
+   if (NULL == symb)

[dpdk-dev] [PATCH v5 6/7] virtio: simple tx routine

[Huawei Xie]

Changes in v5:
- call __rte_pktmbuf_prefree_seg to check refcnt when free mbufs

Changes in v4:
- move virtio_xmit_cleanup ahead to free descriptors earlier

Changes in v3:
- Remove return at the end of void function
- Remove always_inline attribute for virtio_xmit_cleanup

bulk free of mbufs when clean used ring.
shift operation of idx could be saved if vq_free_cnt means
free slots rather than free descriptors.

TODO: rearrange vq data structure, pack the stats var together so that we
could use one vec instruction to update all of them.

Signed-off-by: Huawei Xie 
---
 drivers/net/virtio/virtio_ethdev.h  |   3 +
 drivers/net/virtio/virtio_rxtx_simple.c | 106 
 2 files changed, 109 insertions(+)

diff --git a/drivers/net/virtio/virtio_ethdev.h 
b/drivers/net/virtio/virtio_ethdev.h
index d7797ab..ae2d47d 100644
--- a/drivers/net/virtio/virtio_ethdev.h
+++ b/drivers/net/virtio/virtio_ethdev.h
@@ -111,6 +111,9 @@ uint16_t virtio_xmit_pkts(void *tx_queue, struct rte_mbuf 
**tx_pkts,
 uint16_t virtio_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts);

+uint16_t virtio_xmit_pkts_simple(void *tx_queue, struct rte_mbuf **tx_pkts,
+   uint16_t nb_pkts);
+
 /*
  * The VIRTIO_NET_F_GUEST_TSO[46] features permit the host to send us
  * frames larger than 1514 bytes. We do not yet support software LRO
diff --git a/drivers/net/virtio/virtio_rxtx_simple.c 
b/drivers/net/virtio/virtio_rxtx_simple.c
index ef17562..624e789 100644
--- a/drivers/net/virtio/virtio_rxtx_simple.c
+++ b/drivers/net/virtio/virtio_rxtx_simple.c
@@ -288,6 +288,112 @@ virtio_recv_pkts_vec(void *rx_queue, struct rte_mbuf 
**rx_pkts,
return nb_pkts_received;
 }

+#define VIRTIO_TX_FREE_THRESH 32
+#define VIRTIO_TX_MAX_FREE_BUF_SZ 32
+#define VIRTIO_TX_FREE_NR 32
+/* TODO: vq->tx_free_cnt could mean num of free slots so we could avoid shift 
*/
+static inline void
+virtio_xmit_cleanup(struct virtqueue *vq)
+{
+   uint16_t i, desc_idx;
+   int nb_free = 0;
+   struct rte_mbuf *m, *free[VIRTIO_TX_MAX_FREE_BUF_SZ];
+
+   desc_idx = (uint16_t)(vq->vq_used_cons_idx &
+  ((vq->vq_nentries >> 1) - 1));
+   m = (struct rte_mbuf *)vq->vq_descx[desc_idx++].cookie;
+   m = __rte_pktmbuf_prefree_seg(m);
+   if (likely(m != NULL)) {
+   free[0] = m;
+   nb_free = 1;
+   for (i = 1; i < VIRTIO_TX_FREE_NR; i++) {
+   m = (struct rte_mbuf *)vq->vq_descx[desc_idx++].cookie;
+   m = __rte_pktmbuf_prefree_seg(m);
+   if (likely(m != NULL)) {
+   if (likely(m->pool == free[0]->pool))
+   free[nb_free++] = m;
+   else {
+   rte_mempool_put_bulk(free[0]->pool,
+   (void **)free, nb_free);
+   free[0] = m;
+   nb_free = 1;
+   }
+   }
+   }
+   rte_mempool_put_bulk(free[0]->pool, (void **)free, nb_free);
+   } else {
+   for (i = 1; i < VIRTIO_TX_FREE_NR; i++) {
+   m = (struct rte_mbuf *)vq->vq_descx[desc_idx++].cookie;
+   m = __rte_pktmbuf_prefree_seg(m);
+   if (m != NULL)
+   rte_mempool_put(m->pool, m);
+   }
+   }
+
+   vq->vq_used_cons_idx += VIRTIO_TX_FREE_NR;
+   vq->vq_free_cnt += (VIRTIO_TX_FREE_NR << 1);
+}
+
+uint16_t
+virtio_xmit_pkts_simple(void *tx_queue, struct rte_mbuf **tx_pkts,
+   uint16_t nb_pkts)
+{
+   struct virtqueue *txvq = tx_queue;
+   uint16_t nb_used;
+   uint16_t desc_idx;
+   struct vring_desc *start_dp;
+   uint16_t nb_tail, nb_commit;
+   int i;
+   uint16_t desc_idx_max = (txvq->vq_nentries >> 1) - 1;
+
+   nb_used = VIRTQUEUE_NUSED(txvq);
+   rte_compiler_barrier();
+
+   if (nb_used >= VIRTIO_TX_FREE_THRESH)
+   virtio_xmit_cleanup(tx_queue);
+
+   nb_commit = nb_pkts = RTE_MIN((txvq->vq_free_cnt >> 1), nb_pkts);
+   desc_idx = (uint16_t) (txvq->vq_avail_idx & desc_idx_max);
+   start_dp = txvq->vq_ring.desc;
+   nb_tail = (uint16_t) (desc_idx_max + 1 - desc_idx);
+
+   if (nb_commit >= nb_tail) {
+   for (i = 0; i < nb_tail; i++)
+   txvq->vq_descx[desc_idx + i].cookie = tx_pkts[i];
+   for (i = 0; i < nb_tail; i++) {
+   start_dp[desc_idx].addr =
+   RTE_MBUF_DATA_DMA_ADDR(*tx_pkts);
+   start_dp[desc_idx].len = (*tx_pkts)->pkt_len;
+   tx_pkts++;
+   desc_idx++;
+   }
+   nb_commit -= nb_tail;
+   desc_idx 

[dpdk-dev] [PATCH v5 5/7] virtio: virtio vec rx

[Huawei Xie]

With fixed avail ring, we don't need to get desc idx from avail ring.
virtio driver only has to deal with desc ring.
This patch uses vector instruction to accelerate processing desc ring.

Signed-off-by: Huawei Xie 
---
 drivers/net/virtio/virtio_ethdev.h  |   2 +
 drivers/net/virtio/virtio_rxtx.c|   3 +
 drivers/net/virtio/virtio_rxtx.h|   2 +
 drivers/net/virtio/virtio_rxtx_simple.c | 224 
 drivers/net/virtio/virtqueue.h  |   1 +
 5 files changed, 232 insertions(+)

diff --git a/drivers/net/virtio/virtio_ethdev.h 
b/drivers/net/virtio/virtio_ethdev.h
index 9026d42..d7797ab 100644
--- a/drivers/net/virtio/virtio_ethdev.h
+++ b/drivers/net/virtio/virtio_ethdev.h
@@ -108,6 +108,8 @@ uint16_t virtio_recv_mergeable_pkts(void *rx_queue, struct 
rte_mbuf **rx_pkts,
 uint16_t virtio_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
uint16_t nb_pkts);

+uint16_t virtio_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
+   uint16_t nb_pkts);

 /*
  * The VIRTIO_NET_F_GUEST_TSO[46] features permit the host to send us
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index 5162ce6..947fc46 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -432,6 +432,9 @@ virtio_dev_rx_queue_setup(struct rte_eth_dev *dev,
vq->mpool = mp;

dev->data->rx_queues[queue_idx] = vq;
+
+   virtio_rxq_vec_setup(vq);
+
return 0;
 }

diff --git a/drivers/net/virtio/virtio_rxtx.h b/drivers/net/virtio/virtio_rxtx.h
index 7d2d8fe..831e492 100644
--- a/drivers/net/virtio/virtio_rxtx.h
+++ b/drivers/net/virtio/virtio_rxtx.h
@@ -33,5 +33,7 @@

 #define RTE_PMD_VIRTIO_RX_MAX_BURST 64

+int virtio_rxq_vec_setup(struct virtqueue *rxq);
+
 int virtqueue_enqueue_recv_refill_simple(struct virtqueue *vq,
struct rte_mbuf *m);
diff --git a/drivers/net/virtio/virtio_rxtx_simple.c 
b/drivers/net/virtio/virtio_rxtx_simple.c
index cac5b9f..ef17562 100644
--- a/drivers/net/virtio/virtio_rxtx_simple.c
+++ b/drivers/net/virtio/virtio_rxtx_simple.c
@@ -58,6 +58,10 @@
 #include "virtqueue.h"
 #include "virtio_rxtx.h"

+#define RTE_VIRTIO_VPMD_RX_BURST 32
+#define RTE_VIRTIO_DESC_PER_LOOP 8
+#define RTE_VIRTIO_VPMD_RX_REARM_THRESH RTE_VIRTIO_VPMD_RX_BURST
+
 int __attribute__((cold))
 virtqueue_enqueue_recv_refill_simple(struct virtqueue *vq,
struct rte_mbuf *cookie)
@@ -82,3 +86,223 @@ virtqueue_enqueue_recv_refill_simple(struct virtqueue *vq,

return 0;
 }
+
+static inline void
+virtio_rxq_rearm_vec(struct virtqueue *rxvq)
+{
+   int i;
+   uint16_t desc_idx;
+   struct rte_mbuf **sw_ring;
+   struct vring_desc *start_dp;
+   int ret;
+
+   desc_idx = rxvq->vq_avail_idx & (rxvq->vq_nentries - 1);
+   sw_ring = >sw_ring[desc_idx];
+   start_dp = >vq_ring.desc[desc_idx];
+
+   ret = rte_mempool_get_bulk(rxvq->mpool, (void **)sw_ring,
+   RTE_VIRTIO_VPMD_RX_REARM_THRESH);
+   if (unlikely(ret)) {
+   rte_eth_devices[rxvq->port_id].data->rx_mbuf_alloc_failed +=
+   RTE_VIRTIO_VPMD_RX_REARM_THRESH;
+   return;
+   }
+
+   for (i = 0; i < RTE_VIRTIO_VPMD_RX_REARM_THRESH; i++) {
+   uintptr_t p;
+
+   p = (uintptr_t)_ring[i]->rearm_data;
+   *(uint64_t *)p = rxvq->mbuf_initializer;
+
+   start_dp[i].addr =
+   (uint64_t)((uintptr_t)sw_ring[i]->buf_physaddr +
+   RTE_PKTMBUF_HEADROOM - sizeof(struct virtio_net_hdr));
+   start_dp[i].len = sw_ring[i]->buf_len -
+   RTE_PKTMBUF_HEADROOM + sizeof(struct virtio_net_hdr);
+   }
+
+   rxvq->vq_avail_idx += RTE_VIRTIO_VPMD_RX_REARM_THRESH;
+   rxvq->vq_free_cnt -= RTE_VIRTIO_VPMD_RX_REARM_THRESH;
+   vq_update_avail_idx(rxvq);
+}
+
+/* virtio vPMD receive routine, only accept(nb_pkts >= 
RTE_VIRTIO_DESC_PER_LOOP)
+ *
+ * This routine is for non-mergable RX, one desc for each guest buffer.
+ * This routine is based on the RX ring layout optimization. Each entry in the
+ * avail ring points to the desc with the same index in the desc ring and this
+ * will never be changed in the driver.
+ *
+ * - nb_pkts < RTE_VIRTIO_DESC_PER_LOOP, just return no packet
+ */
+uint16_t
+virtio_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
+   uint16_t nb_pkts)
+{
+   struct virtqueue *rxvq = rx_queue;
+   uint16_t nb_used;
+   uint16_t desc_idx;
+   struct vring_used_elem *rused;
+   struct rte_mbuf **sw_ring;
+   struct rte_mbuf **sw_ring_end;
+   uint16_t nb_pkts_received;
+   __m128i shuf_msk1, shuf_msk2, len_adjust;
+
+   shuf_msk1 = _mm_set_epi8(
+   0xFF, 0xFF, 0xFF, 0xFF,
+   0xFF, 0xFF, /* vlan tci */
+   5, 4,   /* dat len */
+   0xFF, 0xFF, 5, 4,   /* pkt len 

[dpdk-dev] [PATCH v5 4/7] virtio: fill RX avail ring with blank mbufs

[Huawei Xie]

fill avail ring with blank mbufs in virtio_dev_vring_start

Signed-off-by: Huawei Xie 
---
 drivers/net/virtio/Makefile |  2 +-
 drivers/net/virtio/virtio_rxtx.c|  6 ++-
 drivers/net/virtio/virtio_rxtx.h|  3 ++
 drivers/net/virtio/virtio_rxtx_simple.c | 84 +
 4 files changed, 92 insertions(+), 3 deletions(-)
 create mode 100644 drivers/net/virtio/virtio_rxtx_simple.c

diff --git a/drivers/net/virtio/Makefile b/drivers/net/virtio/Makefile
index 930b60f..43835ba 100644
--- a/drivers/net/virtio/Makefile
+++ b/drivers/net/virtio/Makefile
@@ -50,7 +50,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtqueue.c
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_pci.c
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx.c
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_ethdev.c
-
+SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_simple.c

 # this lib depends upon:
 DEPDIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += lib/librte_eal lib/librte_ether
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index 7c82a6a..5162ce6 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -320,8 +320,10 @@ virtio_dev_vring_start(struct virtqueue *vq, int 
queue_type)
/**
* Enqueue allocated buffers*
***/
-   error = virtqueue_enqueue_recv_refill(vq, m);
-
+   if (use_simple_rxtx)
+   error = 
virtqueue_enqueue_recv_refill_simple(vq, m);
+   else
+   error = virtqueue_enqueue_recv_refill(vq, m);
if (error) {
rte_pktmbuf_free(m);
break;
diff --git a/drivers/net/virtio/virtio_rxtx.h b/drivers/net/virtio/virtio_rxtx.h
index a10aa69..7d2d8fe 100644
--- a/drivers/net/virtio/virtio_rxtx.h
+++ b/drivers/net/virtio/virtio_rxtx.h
@@ -32,3 +32,6 @@
  */

 #define RTE_PMD_VIRTIO_RX_MAX_BURST 64
+
+int virtqueue_enqueue_recv_refill_simple(struct virtqueue *vq,
+   struct rte_mbuf *m);
diff --git a/drivers/net/virtio/virtio_rxtx_simple.c 
b/drivers/net/virtio/virtio_rxtx_simple.c
new file mode 100644
index 000..cac5b9f
--- /dev/null
+++ b/drivers/net/virtio/virtio_rxtx_simple.c
@@ -0,0 +1,84 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "virtio_logs.h"
+#include "virtio_ethdev.h"
+#include "virtqueue.h"
+#include "virtio_rxtx.h"
+
+int __attribute__((cold))
+virtqueue_enqueue_recv_refill_simple(struct virtqueue *vq,
+   struct rte_mbuf *cookie)
+{
+   struct vq_desc_extra *dxp;
+   struct vring_desc *start_dp;
+   uint16_t desc_idx;
+
+   desc_idx = vq->vq_avail_idx & (vq->vq_nentries - 1);
+   dxp = >vq_descx[desc_idx];
+   dxp->cookie = (void *)cookie;
+   vq->sw_ring[desc_idx] = cookie;
+
+   start_dp = vq->vq_ring.desc;
+   

[dpdk-dev] [PATCH v5 3/7] virtio: rx/tx ring layout optimization

[Huawei Xie]

Changes in V4:
- fix the error in tx ring layout chart in this commit message.

In DPDK based switching envrioment, mostly vhost runs on a dedicated core
while virtio processing in guest VMs runs on different cores.
Take RX for example, with generic implementation, for each guest buffer,
a) virtio driver allocates a descriptor from free descriptor list
b) modify the entry of avail ring to point to allocated descriptor
c) after packet is received, free the descriptor

When vhost fetches the avail ring, it need to fetch the modified L1 cache from
virtio core, which is a heavy cost in current CPU implementation.

This idea of this optimization is:
allocate the fixed descriptor for each entry of avail ring, so avail ring 
will
always be the same during the run.
This removes L1M cache transfer from virtio core to vhost core for avail ring.
(Note we couldn't avoid the cache transfer for descriptors).
Besides, descriptor allocation and free operation is eliminated.
This also makes vector procesing possible to further accelerate the processing.

This is the layout for the avail ring(take 256 ring entries for example), with
each entry pointing to the descriptor with the same index.
avail
idx
+
|
+++---+-+--+
| 0  | 1  | 2 | ... |  254  | 255  |  avail ring
+-+--+-+--+-+-+-+---+--+---+
  |||   |   |  |
  |||   |   |  |
  vvv   |   v  v
+-+--+-+--+-+-+-+---+--+---+
| 0  | 1  | 2 | ... |  254  | 255  |  desc ring
+++---+-+--+
|
|
+++---+-+--+
| 0  | 1  | 2 | |  254  | 255  |  used ring
+++---+-+--+
|
+

This is the ring layout for TX.
As we need one virtio header for each xmit packet, we have 128 slots available.

 ++
 ||
 ||
+-+-+-+--+--+--+--+
|  0  |  1  | ... |  127 || 128  | 129  | ...  | 255  |   avail ring
+--+--+--+--+-+---+--+---+--+---+--+--+---+
   | ||  ||  |  | |
   v vv  ||  v  v v
+--+--+--+--+-+---+--+---+--+---+--+--+---+
| 128 | 129 | ... |  255 || 128  | 129  | ...  | 255  |   desc ring for 
virtio_net_hdr
+--+--+--+--+-+---+--+---+--+---+--+--+---+
   | ||  ||  |  | |
   v vv  ||  v  v v
+--+--+--+--+-+---+--+---+--+---+--+--+---+
|  0  |  1  | ... |  127 ||  0   |  1   | ...  | 127  |   desc ring for tx dat
+-+-+-+--+--+--+--+
 ||
 ||
 ++

Signed-off-by: Huawei Xie 
---
 drivers/net/virtio/virtio_rxtx.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index 5c00e9d..7c82a6a 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -302,6 +302,12 @@ virtio_dev_vring_start(struct virtqueue *vq, int 
queue_type)
nbufs = 0;
error = ENOSPC;

+   if (use_simple_rxtx)
+   for (i = 0; i < vq->vq_nentries; i++) {
+   vq->vq_ring.avail->ring[i] = i;
+   vq->vq_ring.desc[i].flags = VRING_DESC_F_WRITE;
+   }
+
memset(>fake_mbuf, 0, sizeof(vq->fake_mbuf));
for (i = 0; i < RTE_PMD_VIRTIO_RX_MAX_BURST; i++)
vq->sw_ring[vq->vq_nentries + i] = >fake_mbuf;
@@ -332,6 +338,24 @@ virtio_dev_vring_start(struct virtqueue *vq, int 
queue_type)
VIRTIO_WRITE_REG_4(vq->hw, VIRTIO_PCI_QUEUE_PFN,
vq->mz->phys_addr >> VIRTIO_PCI_QUEUE_ADDR_SHIFT);
} else if (queue_type == VTNET_TQ) {
+   if (use_simple_rxtx) {
+   int mid_idx  = vq->vq_nentries >> 1;
+   for (i = 0; i < mid_idx; i++) {
+   vq->vq_ring.avail->ring[i] = i + mid_idx;
+   vq->vq_ring.desc[i + mid_idx].next = i;
+   vq->vq_ring.desc[i + mid_idx].addr =
+   vq->virtio_net_hdr_mem +
+   mid_idx * 
vq->hw->vtnet_hdr_size;
+   vq->vq_ring.desc[i + mid_idx].len =
+   vq->hw->vtnet_hdr_size;
+   vq->vq_ring.desc[i + mid_idx].flags =
+   VRING_DESC_F_NEXT;
+   vq->vq_ring.desc[i].flags = 0;
+   }
+

[dpdk-dev] [PATCH v5 2/7] virtio: add software rx ring, fake_buf into virtqueue

[Huawei Xie]

Changes in v3:
- Remove unnecessary NULL test for rte_free
- Remove unnecessary assign of local var vq after free

Add software RX ring in virtqueue.
Add fake_mbuf in virtqueue for wraparound processing.
Use global simple_rxtx to indicate whether simple rxtx is enabled

Signed-off-by: Huawei Xie 
---
 drivers/net/virtio/virtio_ethdev.c | 11 ++-
 drivers/net/virtio/virtio_rxtx.c   |  7 +++
 drivers/net/virtio/virtqueue.h |  4 
 3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 79a3640..82676d3 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -247,8 +247,8 @@ virtio_dev_queue_release(struct virtqueue *vq) {
VIRTIO_WRITE_REG_2(hw, VIRTIO_PCI_QUEUE_SEL, vq->queue_id);
VIRTIO_WRITE_REG_4(hw, VIRTIO_PCI_QUEUE_PFN, 0);

+   rte_free(vq->sw_ring);
rte_free(vq);
-   vq = NULL;
}
 }

@@ -292,6 +292,9 @@ int virtio_dev_queue_setup(struct rte_eth_dev *dev,
dev->data->port_id, queue_idx);
vq = rte_zmalloc(vq_name, sizeof(struct virtqueue) +
vq_size * sizeof(struct vq_desc_extra), 
RTE_CACHE_LINE_SIZE);
+   vq->sw_ring = rte_zmalloc_socket("rxq->sw_ring",
+   (RTE_PMD_VIRTIO_RX_MAX_BURST + vq_size) *
+   sizeof(vq->sw_ring[0]), RTE_CACHE_LINE_SIZE, socket_id);
} else if (queue_type == VTNET_TQ) {
snprintf(vq_name, sizeof(vq_name), "port%d_tvq%d",
dev->data->port_id, queue_idx);
@@ -308,6 +311,12 @@ int virtio_dev_queue_setup(struct rte_eth_dev *dev,
PMD_INIT_LOG(ERR, "%s: Can not allocate virtqueue", __func__);
return (-ENOMEM);
}
+   if (queue_type == VTNET_RQ && vq->sw_ring == NULL) {
+   PMD_INIT_LOG(ERR, "%s: Can not allocate RX soft ring",
+   __func__);
+   rte_free(vq);
+   return -ENOMEM;
+   }

vq->hw = hw;
vq->port_id = dev->data->port_id;
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index 9324f7f..5c00e9d 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -62,6 +62,8 @@
 #define  VIRTIO_DUMP_PACKET(m, len) do { } while (0)
 #endif

+static int use_simple_rxtx;
+
 static void
 vq_ring_free_chain(struct virtqueue *vq, uint16_t desc_idx)
 {
@@ -299,6 +301,11 @@ virtio_dev_vring_start(struct virtqueue *vq, int 
queue_type)
/* Allocate blank mbufs for the each rx descriptor */
nbufs = 0;
error = ENOSPC;
+
+   memset(>fake_mbuf, 0, sizeof(vq->fake_mbuf));
+   for (i = 0; i < RTE_PMD_VIRTIO_RX_MAX_BURST; i++)
+   vq->sw_ring[vq->vq_nentries + i] = >fake_mbuf;
+
while (!virtqueue_full(vq)) {
m = rte_rxmbuf_alloc(vq->mpool);
if (m == NULL)
diff --git a/drivers/net/virtio/virtqueue.h b/drivers/net/virtio/virtqueue.h
index 7789411..6a1ec48 100644
--- a/drivers/net/virtio/virtqueue.h
+++ b/drivers/net/virtio/virtqueue.h
@@ -190,6 +190,10 @@ struct virtqueue {
uint16_t vq_avail_idx;
phys_addr_t virtio_net_hdr_mem; /**< hdr for each xmit packet */

+   struct rte_mbuf **sw_ring; /**< RX software ring. */
+   /* dummy mbuf, for wraparound when processing RX ring. */
+   struct rte_mbuf fake_mbuf;
+
/* Statistics */
uint64_tpackets;
uint64_tbytes;
-- 
1.8.1.4

[dpdk-dev] [PATCH v5 1/7] virtio: add virtio_rxtx.h header file

[Huawei Xie]

Would move all rx/tx related declarations into this header file in future.
Add RTE_VIRTIO_PMD_MAX_BURST.

Signed-off-by: Huawei Xie 
---
 drivers/net/virtio/virtio_ethdev.c |  1 +
 drivers/net/virtio/virtio_rxtx.c   |  1 +
 drivers/net/virtio/virtio_rxtx.h   | 34 ++
 3 files changed, 36 insertions(+)
 create mode 100644 drivers/net/virtio/virtio_rxtx.h

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 465d3cd..79a3640 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -61,6 +61,7 @@
 #include "virtio_pci.h"
 #include "virtio_logs.h"
 #include "virtqueue.h"
+#include "virtio_rxtx.h"


 static int eth_virtio_dev_init(struct rte_eth_dev *eth_dev);
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index c5b53bb..9324f7f 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -54,6 +54,7 @@
 #include "virtio_logs.h"
 #include "virtio_ethdev.h"
 #include "virtqueue.h"
+#include "virtio_rxtx.h"

 #ifdef RTE_LIBRTE_VIRTIO_DEBUG_DUMP
 #define VIRTIO_DUMP_PACKET(m, len) rte_pktmbuf_dump(stdout, m, len)
diff --git a/drivers/net/virtio/virtio_rxtx.h b/drivers/net/virtio/virtio_rxtx.h
new file mode 100644
index 000..a10aa69
--- /dev/null
+++ b/drivers/net/virtio/virtio_rxtx.h
@@ -0,0 +1,34 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#define RTE_PMD_VIRTIO_RX_MAX_BURST 64
-- 
1.8.1.4

[dpdk-dev] [PATCH v5 0/7] virtio ring layout optimization and simple rx/tx processing

[Huawei Xie]

Changes in v5:
- Call __rte_pktmbuf_prefree_seg to check refcnt when free mbufs

Changes in v4:
- Fix the error in virtio tx ring layout ascii chart in the commit message
- Move virtio_xmit_cleanup ahead to free descriptors earlier
- Test merge-able feature when select simple rx/tx functions

Changes in v3:
- Remove unnecessary NULL test for rte_free
- Remove unnecessary assign of local var after free
- Remove return at the end of void function
- Remove always_inline attribute for virtio_xmit_cleanup
- Reword some commit messages
- Add TODO in the commit message of simple tx patch

Changes in v2:
- Remove the configure macro
- Enable simple R/TX processing when user specifies simple txq flags
- Reword some comments and commit messages

In DPDK based switching enviroment, mostly vhost runs on a dedicated core
while virtio processing in guest VMs runs on other different cores.
Take RX for example, with generic implementation, for each guest buffer,
a) virtio driver allocates a descriptor from free descriptor list
b) modify the entry of avail ring to point to allocated descriptor
c) after packet is received, free the descriptor

When vhost fetches the avail ring, it need to fetch the modified L1 cache from
virtio core, which is a heavy cost in current CPU implementation.

This idea of this optimization is:
allocate the fixed descriptor for each entry of avail ring, so avail ring 
will
always be the same during the run.
This removes L1M cache transfer from virtio core to vhost core for avail ring.
(Note we couldn't avoid the cache transfer for descriptors).
Besides, descriptor allocation and free operation is eliminated.
This also makes vector procesing possible to further accelerate the processing.

This is the layout for the avail ring(take 256 ring entries for example), with
each entry pointing to the descriptor with the same index.
avail
idx
+
|
+++---+-+--+
| 0  | 1  | 2 | ... |  254  | 255  |  avail ring
+-+--+-+--+-+-+-+---+--+---+
  |||   |   |  |
  |||   |   |  |
  vvv   |   v  v
+-+--+-+--+-+-+-+---+--+---+
| 0  | 1  | 2 | ... |  254  | 255  |  desc ring
+++---+-+--+
|
|
+++---+-+--+
| 0  | 1  | 2 | |  254  | 255  |  used ring
+++---+-+--+
|
+

This is the ring layout for TX.
As we need one virtio header for each xmit packet, we have 128 slots available.

 ++
 ||
 ||
+-+-+-+--+--+--+--+
|  0  |  1  | ... |  127 || 128  | 129  | ...  | 255  |   avail ring
+--+--+--+--+-+---+--+---+--+---+--+--+---+
   | ||  ||  |  | |
   v vv  ||  v  v v
+--+--+--+--+-+---+--+---+--+---+--+--+---+
| 127 | 128 | ... |  255 || 127  | 128  | ...  | 255  |   desc ring for 
virtio_net_hdr
+--+--+--+--+-+---+--+---+--+---+--+--+---+
   | ||  ||  |  | |
   v vv  ||  v  v v
+--+--+--+--+-+---+--+---+--+---+--+--+---+
|  0  |  1  | ... |  127 ||  0   |  1   | ...  | 127  |   desc ring for tx dat
+-+-+-+--+--+--+--+
 ||
 ||
 ++


Performance boost could be observed only if the virtio backend isn't the 
bottleneck or in VM2VM
case.
There are also several vhost optimization patches to be submitted later.


Huawei Xie (7):
  virtio: add virtio_rxtx.h header file
  virtio: add software rx ring, fake_buf into virtqueue
  virtio: rx/tx ring layout optimization
  virtio: fill RX avail ring with blank mbufs
  virtio: virtio vec rx
  virtio: simple tx routine
  virtio: pick simple rx/tx func

 drivers/net/virtio/Makefile |   2 +-
 drivers/net/virtio/virtio_ethdev.c  |  12 +-
 drivers/net/virtio/virtio_ethdev.h  |   5 +
 drivers/net/virtio/virtio_rxtx.c|  56 -
 drivers/net/virtio/virtio_rxtx.h|  39 +++
 drivers/net/virtio/virtio_rxtx_simple.c | 414 
 drivers/net/virtio/virtqueue.h  |   5 +
 7 files changed, 529 insertions(+), 4 deletions(-)
 create mode 100644 drivers/net/virtio/virtio_rxtx.h
 create mode 100644 drivers/net/virtio/virtio_rxtx_simple.c

-- 
1.8.1.4

[dpdk-dev] [PATCH v6 3/5] ethdev: redesign link speed config API

[Marc Sune]

While testing this patch with some XL710, it seems even with current HEAD,
setting link speed into dev_conf to 10G does not work, it always takes
autoneg with all speeds.

Besides, this patch in particular should be tested for the rest of drivers
which I don't have HW for.

Regards
marc

2015-10-25 22:59 GMT+01:00 Marc Sune :

> This patch redesigns the API to set the link speed/s configure
> for an ethernet port. Specifically:
>
> - it allows to define a set of advertised speeds for
>   auto-negociation.
> - it allows to disable link auto-negociation (single fixed speed).
> - default: auto-negociate all supported speeds.
>
> Other changes:
>
> * Added utility MACROs ETH_SPEED_NUM_XXX with the numeric
>   values of all supported link speeds, in Mbps.
> * Converted link_speed to uint32_t to accomodate 100G speeds
>   (bug).
> * Added autoneg flag in struct rte_eth_link to indicate if
>   link speed was a result of auto-negociation or was fixed
>   by configuration.
> * Added utility function to convert numeric speeds to bitmap
>   fields.
>
> Signed-off-by: Marc Sune 
> ---
>  app/test-pmd/cmdline.c | 124
> +++--
>  app/test/virtual_pmd.c |   4 +-
>  drivers/net/af_packet/rte_eth_af_packet.c  |   5 +-
>  drivers/net/bonding/rte_eth_bond_8023ad.c  |  14 ++--
>  drivers/net/cxgbe/base/t4_hw.c |   8 +-
>  drivers/net/e1000/base/e1000_80003es2lan.c |   6 +-
>  drivers/net/e1000/base/e1000_82541.c   |   8 +-
>  drivers/net/e1000/base/e1000_82543.c   |   4 +-
>  drivers/net/e1000/base/e1000_82575.c   |  11 +--
>  drivers/net/e1000/base/e1000_api.c |   2 +-
>  drivers/net/e1000/base/e1000_api.h |   2 +-
>  drivers/net/e1000/base/e1000_defines.h |   4 +-
>  drivers/net/e1000/base/e1000_hw.h  |   2 +-
>  drivers/net/e1000/base/e1000_ich8lan.c |   4 +-
>  drivers/net/e1000/base/e1000_mac.c |   9 ++-
>  drivers/net/e1000/base/e1000_mac.h |   6 +-
>  drivers/net/e1000/base/e1000_vf.c  |   4 +-
>  drivers/net/e1000/base/e1000_vf.h  |   2 +-
>  drivers/net/e1000/em_ethdev.c  | 113
> +-
>  drivers/net/e1000/igb_ethdev.c | 108 +
>  drivers/net/fm10k/fm10k_ethdev.c   |   8 +-
>  drivers/net/i40e/i40e_ethdev.c |  73 -
>  drivers/net/i40e/i40e_ethdev_vf.c  |  11 +--
>  drivers/net/ixgbe/ixgbe_ethdev.c   |  72 -
>  drivers/net/mlx4/mlx4.c|   2 +
>  drivers/net/mpipe/mpipe_tilegx.c   |   6 +-
>  drivers/net/null/rte_eth_null.c|   5 +-
>  drivers/net/pcap/rte_eth_pcap.c|   9 ++-
>  drivers/net/ring/rte_eth_ring.c|   5 +-
>  drivers/net/virtio/virtio_ethdev.c |   2 +-
>  drivers/net/virtio/virtio_ethdev.h |   2 -
>  drivers/net/vmxnet3/vmxnet3_ethdev.c   |   5 +-
>  drivers/net/xenvirt/rte_eth_xenvirt.c  |   5 +-
>  examples/ip_pipeline/config_parse.c|   3 +-
>  lib/librte_ether/rte_ethdev.c  |  49 
>  lib/librte_ether/rte_ethdev.h  | 113
> --
>  36 files changed, 449 insertions(+), 361 deletions(-)
>
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> index 0f8f48f..c62f5be 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -897,14 +897,65 @@ struct cmd_config_speed_all {
> cmdline_fixed_string_t value2;
>  };
>
> +static int
> +parse_and_check_speed_duplex(char *value1, char *value2, uint32_t
> *link_speed)
> +{
> +
> +   int duplex;
> +
> +   if (!strcmp(value2, "half")) {
> +   duplex = 0;
> +   } else if (!strcmp(value2, "full")) {
> +   duplex = 1;
> +   } else if (!strcmp(value2, "auto")) {
> +   duplex = 1;
> +   } else {
> +   printf("Unknown parameter\n");
> +   return -1;
> +   }
> +
> +   if (!strcmp(value1, "10")) {
> +   *link_speed = (duplex) ? ETH_LINK_SPEED_10M :
> +
>  ETH_LINK_SPEED_10M_HD;
> +   } else if (!strcmp(value1, "100")) {
> +   *link_speed = (duplex) ? ETH_LINK_SPEED_100M :
> +
>  ETH_LINK_SPEED_100M_HD;
> +   } else if (!strcmp(value1, "1000")) {
> +   if (!duplex)
> +   goto invalid_speed_param;
> +   *link_speed = ETH_LINK_SPEED_1G;
> +   } else if (!strcmp(value1, "1")) {
> +   if (!duplex)
> +   goto invalid_speed_param;
> +   *link_speed = ETH_LINK_SPEED_10G;
> +   } else if (!strcmp(value1, "4")) {
> +   if (!duplex)
> +   goto invalid_speed_param;
> +   *link_speed = ETH_LINK_SPEED_40G;
> +   } else if (!strcmp(value1, "auto")) {
> +   if (!duplex)
> +   goto invalid_speed_param;
> +   *link_speed = 

[dpdk-dev] [PATCH v6 5/5] ethdev: add rte_eth_speed_to_bm_flag() to ver. map

[Marc Sune]

Added rte_eth_speed_to_bm_flag() to DPDK2.2 version map.

Signed-off-by: Marc Sune 
---
 lib/librte_ether/rte_ether_version.map | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lib/librte_ether/rte_ether_version.map 
b/lib/librte_ether/rte_ether_version.map
index 8345a6c..cbfe0c8 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -127,3 +127,9 @@ DPDK_2.1 {
rte_eth_timesync_read_tx_timestamp;

 } DPDK_2.0;
+
+DPDK_2.2 {
+   global:
+
+   rte_eth_speed_to_bm_flag;
+} DPDK_2.1;
-- 
2.1.4