[dpdk-dev] [igb_uio PATCH 0/3] igb_uio: fixed typos and pci lock/unlock calls
2014-07-22 15:07, Thomas Monjalon: > The compilation with old kernels should be fixed now. > If some distributions have backported the new PCI config locking functions, > the compilation may fail. Please report such errors. Compilation with RHEL6 is broken because of some backported functions, some unknown MSIX values and some MSI functions missing. include/linux/pci.h:1572: note: previous declaration of ?pci_num_vf? was here include/linux/pci.h:868: note: previous declaration of ?pci_intx_mask_supported? was here include/linux/pci.h:869: note: previous declaration of ?pci_check_and_mask_intx? was here igb_uio.c:294: error: ?PCI_MSIX_ENTRY_SIZE? undeclared (first use in this function) igb_uio.c:295: error: ?PCI_MSIX_ENTRY_VECTOR_CTRL? undeclared (first use in this function) igb_uio.c:298: error: ?PCI_MSIX_ENTRY_CTRL_MASKBIT? undeclared (first use in this function) igb_uio.c:312: error: implicit declaration of function ?irq_data_get_msi? igb_uio.c:350: error: implicit declaration of function ?irq_get_irq_data? If someone has time to fix it, patch is welcome. Thanks -- Thomas
[dpdk-dev] maintainer help solicited for dpdk-rumptcpip
Hi, In case someone is interested in seeing new releases of dpdk tested against against the dpdk driver for the rump kernels, please help out. There's usually a few hours of toying around with build/compiler/assembler stuff to figure out how to build a new release of dpdk, and I don't seem to be able to find those hours. repo.rumpkernel.org/dpdk-rumptcpip, signup in the normal open source fashion by sending pull requests. thanks, antti
[dpdk-dev] symbol conflicts between netinet/in.h, arpa/inet.h, and rte_ip.h
On 24/07/14 07:59, Matthew Hall wrote: > Hello, > > I ran into some weird symbol conflicts between system netinet/in.h and DPDK > rte_ip.h. They have a lot of duplicated definitions for stuff like IPPROTO_IP > and so on. This breaks when you want to use inet_pton from arpa/inet.h, > because it includes netinet/in.h to define struct in_addr. I would namespace the definitions in DPDK, i.e. make them DPDK_IPPROTO_FOO etc. > Thus with all the conflicts it's impossible to use a DPDK IP struct instead of > all the system's sockaddr stuff, to store a value from the system copy of > inet_pton. This would be a common operation if, for example, you want to > configure all the IP addresses on your box from a JSON file, which is what I > was doing. > > The DPDK kludged around it internally by using a file called > cmdline_parse_ipaddr.c with private copies of these functions. But it in my > opinion very unwisely marked all of the functions as static except for > cmdline_parse_ipaddr, which only works on the DPDK's proprietary argument > handling, and not with anything the user might have which is a different > format. In my experience from years of fighting with more or less this exact same problem -- the fight is now thankfully over but the scars remain -- you either want to expose a complete set of types and provide support for everything, or you want to expose nothing. Approaches where you use cute definitions and reuse some host routines is like asking for an audience with Tyranthraxus when armed with a kitten. It's that doubly so if you don't have to and do it anyway. > So, it would be a big help for users if the macros in librte_net files would > check if the symbols already existed, or if they had subheader files available > to grab only non conflicting symbols, or if they would make a proper .h and > factor all the inet_pton and inet_ntop inside the cmdline lib into a place > where users can access them. It would also be a help if they had a less ugly > equivalent to struct sockaddr, which let you work with IP addresses a bit more > easily, such as something like this: Again, I recommend steering away from any tightrope approaches that "know" which types are non-conflicting, or pick out half-and-half from the host and IP stack. "Do, or do not, there is no half-and-half"
[dpdk-dev] [PATCH] ixgbe: convert sse intrinsics to use __builtin variants
On Thu, Jul 24, 2014 at 08:41:33PM +, Venkatesan, Venky wrote: > Neil, > > Nice patch! One question - what gcc versions did you try this out on? We'll > round out with checking the other versions. > Thanks! This was built using gcc 4.8.3. I had hoped to do something simmilar for the ACL library, but the sse instructions used there only emitted code when sse was enabled (IOW there was no genereic non-sse variant)? Neil
[dpdk-dev] symbol conflicts between netinet/in.h, arpa/inet.h, and rte_ip.h
I don't know if it will work right on both Linux and BSD and/or if they also 100% agree with the libc / glibc values compiled into the system's .so files. That's the risk that you run if you don't have more complete support in the DPDK itself for these features. -- Sent from my mobile device. On July 24, 2014 6:12:18 PM PDT, "Wu, Jingjing" wrote: >Hello, > >We also notice these conflicts, we just planned to fix it in our new >feature development. The proposal is like: > >#ifndef _NETINET_IN_H >#ifndef _NETINET_IN_H_ > >#define IPPROTO_IP 0 > ... ... >#define IPPROTO_MAX 256 > >#endif >#endif > >Do you think it is a good idea? > >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Antti Kantee >> Sent: Friday, July 25, 2014 6:56 AM >> To: Matthew Hall; dev at dpdk.org >> Subject: Re: [dpdk-dev] symbol conflicts between netinet/in.h, >arpa/inet.h, and rte_ip.h >> >> On 24/07/14 07:59, Matthew Hall wrote: >> > Hello, >> > >> > I ran into some weird symbol conflicts between system netinet/in.h >and DPDK >> > rte_ip.h. They have a lot of duplicated definitions for stuff like >IPPROTO_IP >> > and so on. This breaks when you want to use inet_pton from >arpa/inet.h, >> > because it includes netinet/in.h to define struct in_addr. >> >> I would namespace the definitions in DPDK, i.e. make them >> DPDK_IPPROTO_FOO etc. >> >> > Thus with all the conflicts it's impossible to use a DPDK IP struct >instead of >> > all the system's sockaddr stuff, to store a value from the system >copy of >> > inet_pton. This would be a common operation if, for example, you >want to >> > configure all the IP addresses on your box from a JSON file, which >is what I >> > was doing. >> > >> > The DPDK kludged around it internally by using a file called >> > cmdline_parse_ipaddr.c with private copies of these functions. But >it in my >> > opinion very unwisely marked all of the functions as static except >for >> > cmdline_parse_ipaddr, which only works on the DPDK's proprietary >argument >> > handling, and not with anything the user might have which is a >different >> > format. >> >> In my experience from years of fighting with more or less this exact >> same problem -- the fight is now thankfully over but the scars remain >-- >> you either want to expose a complete set of types and provide support >> for everything, or you want to expose nothing. Approaches where you >use >> cute definitions and reuse some host routines is like asking for an >> audience with Tyranthraxus when armed with a kitten. It's that >doubly >> so if you don't have to and do it anyway. >> >> > So, it would be a big help for users if the macros in librte_net >files would >> > check if the symbols already existed, or if they had subheader >files available >> > to grab only non conflicting symbols, or if they would make a >proper .h and >> > factor all the inet_pton and inet_ntop inside the cmdline lib into >a place >> > where users can access them. It would also be a help if they had a >less ugly >> > equivalent to struct sockaddr, which let you work with IP addresses >a bit more >> > easily, such as something like this: >> >> Again, I recommend steering away from any tightrope approaches that >> "know" which types are non-conflicting, or pick out half-and-half >from >> the host and IP stack. "Do, or do not, there is no half-and-half"
[dpdk-dev] [PATCH] ixgbe: convert sse intrinsics to use __builtin variants
Neil, Nice patch! One question - what gcc versions did you try this out on? We'll round out with checking the other versions. Regards, -Venky -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Neil Horman Sent: Thursday, July 24, 2014 11:24 AM To: dev at dpdk.org Subject: [dpdk-dev] [PATCH] ixgbe: convert sse intrinsics to use __builtin variants The ixgbe pmd currently can't be built without enabling sse instructions at compile time. While sse extensions provide better performance, theres no reason that we can't still create builds to run on systems that don't support sse. If we modify the ixgbe code to use the __builtin_shuffle and __builtin_popcountll functions, I've confirmed that the gcc compiler emits the appropriate sse instructions when the provided -march parameter indicates a machine that includes sse support, and emits generic code when see isn't available. Signed-off-by: Neil Horman CC: Thomas Monjalon --- lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c index 09e19a3..5747072 100644 --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c @@ -38,8 +38,6 @@ #include "ixgbe_ethdev.h" #include "ixgbe_rxtx.h" -#include - #ifndef __INTEL_COMPILER #pragma GCC diagnostic ignored "-Wcast-qual" #endif @@ -294,8 +292,8 @@ ixgbe_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts, rte_compiler_barrier(); /* D.1 pkt 3,4 convert format from desc to pktmbuf */ - pkt_mb4 = _mm_shuffle_epi8(descs[3], shuf_msk); - pkt_mb3 = _mm_shuffle_epi8(descs[2], shuf_msk); + pkt_mb4 = __builtin_shuffle(descs[3], shuf_msk); + pkt_mb3 = __builtin_shuffle(descs[2], shuf_msk); /* C.1 4=>2 filter staterr info only */ sterr_tmp2 = _mm_unpackhi_epi32(descs[3], descs[2]); @@ -310,8 +308,8 @@ ixgbe_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts, pkt_mb3 = _mm_add_epi16(pkt_mb3, in_port); /* D.1 pkt 1,2 convert format from desc to pktmbuf */ - pkt_mb2 = _mm_shuffle_epi8(descs[1], shuf_msk); - pkt_mb1 = _mm_shuffle_epi8(descs[0], shuf_msk); + pkt_mb2 = __builtin_shuffle(descs[1], shuf_msk); + pkt_mb1 = __builtin_shuffle(descs[0], shuf_msk); /* C.2 get 4 pkts staterr value */ zero = _mm_xor_si128(dd_check, dd_check); @@ -338,7 +336,7 @@ ixgbe_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts, pkt_mb1); /* C.4 calc avaialbe number of desc */ - var = _mm_popcnt_u64(_mm_cvtsi128_si64(staterr)); + var = __builtin_popcountll(_mm_cvtsi128_si64(staterr)); nb_pkts_recd += var; if (likely(var != RTE_IXGBE_DESCS_PER_LOOP)) break; -- 1.8.3.1
[dpdk-dev] [PATCH] kni: fixed compilation error on Ubuntu 14.04 LTS (kernel 3.13.0-30.54)
Hi Chris, 2014-07-24 08:20, Chris Wright: > * Pablo de Lara (pablo.de.lara.guarch at intel.com) wrote: > > Signed-off-by: Patrice Buriez > > Just a mechanical nitpick on DCO. Pablo, this patch appears to be > written by Patrice. If so, it should begin with "From: Patrice Buriez > " and should include your own Signed-off-by. I agree that the author name (From:) should be fixed. But I'm not sure we should follow Linux guidelines for Signed-off-by when patch is simply forwarded. Does it mean more than "I am authorized to send it" ? -- Thomas
[dpdk-dev] [PATCH] kni: fixed compilation error on Ubuntu 14.04 LTS (kernel 3.13.0-30.54)
2014-07-24 16:54, Thomas Monjalon: > > Unlike RHEL_RELEASE_CODE, there is no such UBUNTU_RELEASE_CODE available > > out of > > the box, so it needs to be crafted from the Makefile > > Similarly, UBUNTU_KERNEL_CODE is generated with ABI and upload numbers. > > It's quite amazing to see that Linux distributions do backports and do not > provide a way to check them. > Anyway, thanks for the fix. > > > +ifeq ($(shell type lsb_release >/dev/null 2>&1 && lsb_release -si),Ubuntu) > > Why not this simpler form? > $(shell lsb_release -si 2>/dev/null) > > > +MODULE_CFLAGS += -DUBUNTU_RELEASE_CODE=$(subst .,,$(shell lsb_release -sr)) > > Or you can use | tr -d . instead of subst and keep the flow from left to > right. > > > +UBUNTU_KERNEL_CODE := $(shell cut -d' ' -f2 /proc/version_signature |cut > > -d- -f1,2) > ^ > space missing here > > > +UBUNTU_KERNEL_CODE := $(subst -,$(comma),$(UBUNTU_KERNEL_CODE)) > > +UBUNTU_KERNEL_CODE := $(subst .,$(comma),$(UBUNTU_KERNEL_CODE)) > > Would be simpler with | tr -d .- Sorry, I mean tr -d .- $(comma) -- Thomas
[dpdk-dev] [PATCH] kni: fixed compilation error on Ubuntu 14.04 LTS (kernel 3.13.0-30.54)
> Unlike RHEL_RELEASE_CODE, there is no such UBUNTU_RELEASE_CODE available out > of > the box, so it needs to be crafted from the Makefile > Similarly, UBUNTU_KERNEL_CODE is generated with ABI and upload numbers. It's quite amazing to see that Linux distributions do backports and do not provide a way to check them. Anyway, thanks for the fix. > +ifeq ($(shell type lsb_release >/dev/null 2>&1 && lsb_release -si),Ubuntu) Why not this simpler form? $(shell lsb_release -si 2>/dev/null) > +MODULE_CFLAGS += -DUBUNTU_RELEASE_CODE=$(subst .,,$(shell lsb_release -sr)) Or you can use | tr -d . instead of subst and keep the flow from left to right. > +UBUNTU_KERNEL_CODE := $(shell cut -d' ' -f2 /proc/version_signature |cut -d- > -f1,2) ^ space missing here > +UBUNTU_KERNEL_CODE := $(subst -,$(comma),$(UBUNTU_KERNEL_CODE)) > +UBUNTU_KERNEL_CODE := $(subst .,$(comma),$(UBUNTU_KERNEL_CODE)) Would be simpler with | tr -d .- -- Thomas
[dpdk-dev] rte_eth_dev_configure
Thanks and it is working and help me a lot. On Thu, Jul 24, 2014 at 3:05 PM, Thomas Monjalon wrote: > 2014-07-24 15:00, sothy shan: > > I have problem when I try dpdk ovs with DPDK 1.7. DPDK 1.7 alone working > > well. > [...] > > I am not sure when I using DPDK ovs, how to debug at DPDK 1.7.0 code. I > > guess I need to enable to print PMD_DEBUG_TRACE message. At this point, > > DPDK ovs message is only printed. > > You should enable CONFIG_RTE_LIBRTE_ETHDEV_DEBUG before compiling. > > > I too suspect it is problem with port_conf message. Not sure. First I > need > > to know how to use PMD_DEBUG_TRACE with DPDK_ovs. > > > > You understand my question? > > Yes I understand that you should enable debugging and ask for help on the > right mailling list. > If DPDK alone works well, we cannot do anything for you. > > -- > Thomas >
[dpdk-dev] symbol conflicts between netinet/in.h, arpa/inet.h, and rte_ip.h
On Thu, Jul 24, 2014 at 10:55:59PM +, Antti Kantee wrote: > In my experience from years of fighting with more or less this exact same > problem -- the fight is now thankfully over but the scars remain -- you > either want to expose a complete set of types and provide support for > everything, or you want to expose nothing. I don't have a problem with this approach. Implementing it would require the DPDK to create user accessible functions for creating MAC addresses, IPs, CIDRs, and TCP / UDP port numbers. Many of the things required are hiding inside of *cmdline* code where it's impossible for anybody to access them. Matthew.
[dpdk-dev] symbol conflicts between netinet/in.h, arpa/inet.h, and rte_ip.h
I also noticed this problem. It is a serious one. I would like it solved.
-- Niraj Sharma
Principal Eng.
Cisco System, Inc.
On 7/24/14 12:59 AM, "Matthew Hall" wrote:
>Hello,
>
>I ran into some weird symbol conflicts between system netinet/in.h and
>DPDK
>rte_ip.h. They have a lot of duplicated definitions for stuff like
>IPPROTO_IP
>and so on. This breaks when you want to use inet_pton from arpa/inet.h,
>because it includes netinet/in.h to define struct in_addr.
>
>Thus with all the conflicts it's impossible to use a DPDK IP struct
>instead of
>all the system's sockaddr stuff, to store a value from the system copy of
>inet_pton. This would be a common operation if, for example, you want to
>configure all the IP addresses on your box from a JSON file, which is
>what I
>was doing.
>
>The DPDK kludged around it internally by using a file called
>cmdline_parse_ipaddr.c with private copies of these functions. But it in
>my
>opinion very unwisely marked all of the functions as static except for
>cmdline_parse_ipaddr, which only works on the DPDK's proprietary argument
>handling, and not with anything the user might have which is a different
>format.
>
>So, it would be a big help for users if the macros in librte_net files
>would
>check if the symbols already existed, or if they had subheader files
>available
>to grab only non conflicting symbols, or if they would make a proper .h
>and
>factor all the inet_pton and inet_ntop inside the cmdline lib into a
>place
>where users can access them. It would also be a help if they had a less
>ugly
>equivalent to struct sockaddr, which let you work with IP addresses a bit
>more
>easily, such as something like this:
>
>struct ip4_addr {
>uint32_t addr;
>};
>
>typedef struct ip4_addr ip4_addr;
>
>struct ip6_addr {
>uint8_t addr[16];
>};
>
>typedef struct ip6_addr ip6_addr;
>
>struct ip_addr {
>uint8_t family;
>uint8_t prefix;
>union {
>struct ip4_addr ipv4;
>struct ip6_addr ipv6;
>};
>};
>
>I had to create a bunch of duplicate code to handle it in my project,
>since
>the DPDK marked its copies of all these functions as "secret" and didn't
>make
>a .h for them. If any of it is useful I am happy to donate it, although I
>don't think I've got quite enough experience with this specifc part of
>the
>DPDK to code it up all by myself.
>
>Thanks,
>Matthew.
[dpdk-dev] [PATCH] kni: fixed compilation error on Ubuntu 14.04 LTS (kernel 3.13.0-30.54)
Recent Ubuntu kernel 3.13.0-30.54, although based on Linux kernel 3.13.11,
already provides skb_set_hash() inline function, slightly different than
the one provided by lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
Ubuntu kernel 3.13.0-30.54 provides:
* i40e/i40evf: i40e implementation for skb_set_hash
- https://bugs.launchpad.net/bugs/1328037
-
http://changelogs.ubuntu.com/changelogs/pool/main/l/linux/linux_3.13.0-30.54/changelog
As a result, the implementation provided by kcompat.h must be skipped.
It is not appropriate to test whether LINUX_VERSION_CODE >=
KERNEL_VERSION(3,13,11)
because previous Ubuntu kernel 3.13.0-29.53, already based on 3.13.11, needs to
get the implementation provided by kcompat.h
So the full Ubuntu kernel version numbering scheme must be tested:
-.-
See "What does a specific Ubuntu kernel version number mean?"
and "How can we determine the version of the running kernel?"
at: https://wiki.ubuntu.com/Kernel/FAQ
Unlike RHEL_RELEASE_CODE, there is no such UBUNTU_RELEASE_CODE available out of
the box, so it needs to be crafted from the Makefile
Similarly, UBUNTU_KERNEL_CODE is generated with ABI and upload numbers.
`lsb_release -si` is first used to check whether we are running Ubuntu
`lsb_release -sr` provides release number 14.04, then converted to integer 1404
/proc/version_signature is parsed to get base kernel version, ABI and upload
numbers, and flavour is dropped
UBUNTU_KERNEL_CODE is indirectly defined using the UBUNTU_KERNEL_VERSION macro,
which in turn is defined in kcompat.h
This makes a single place to define the Ubuntu kernel version numbering scheme,
which is slightly different than the usual "shift by 8" scheme: ABI numbers can
be big (see: https://wiki.ubuntu.com/Kernel/Dev/TopicBranches), so 16-bits have
been reserved for them.
Finally, the implementaion of skb_set_hash is skipped in kcompat.h if we are
running Ubuntu 14.04 with an Ubuntu kernel >= 3.13.0-30.54
Signed-off-by: Patrice Buriez
---
lib/librte_eal/linuxapp/kni/Makefile |9 +
lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h | 16
2 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/lib/librte_eal/linuxapp/kni/Makefile
b/lib/librte_eal/linuxapp/kni/Makefile
index fb9462f..725d3e7 100644
--- a/lib/librte_eal/linuxapp/kni/Makefile
+++ b/lib/librte_eal/linuxapp/kni/Makefile
@@ -44,6 +44,15 @@ MODULE_CFLAGS += -I$(RTE_OUTPUT)/include
-I$(SRCDIR)/ethtool/ixgbe -I$(SRCDIR)/e
MODULE_CFLAGS += -include $(RTE_OUTPUT)/include/rte_config.h
MODULE_CFLAGS += -Wall -Werror
+ifeq ($(shell type lsb_release >/dev/null 2>&1 && lsb_release -si),Ubuntu)
+MODULE_CFLAGS += -DUBUNTU_RELEASE_CODE=$(subst .,,$(shell lsb_release -sr))
+UBUNTU_KERNEL_CODE := $(shell cut -d' ' -f2 /proc/version_signature |cut -d-
-f1,2)
+UBUNTU_KERNEL_CODE := $(subst -,$(comma),$(UBUNTU_KERNEL_CODE))
+UBUNTU_KERNEL_CODE := $(subst .,$(comma),$(UBUNTU_KERNEL_CODE))
+MODULE_CFLAGS +=
-D"UBUNTU_KERNEL_CODE=UBUNTU_KERNEL_VERSION($(UBUNTU_KERNEL_CODE))"
+endif
+
+
# this lib needs main eal
DEPDIRS-y += lib/librte_eal/linuxapp/eal
diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
index 521a35d..5a06383 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
@@ -713,6 +713,20 @@ struct _kc_ethtool_pauseparam {
#define SLE_VERSION_CODE 0
#endif /* SLE_VERSION_CODE */
+/* Ubuntu release and kernel codes must be specified from Makefile */
+#ifndef UBUNTU_RELEASE_VERSION
+#define UBUNTU_RELEASE_VERSION(a,b) (((a) * 100) + (b))
+#endif
+#ifndef UBUNTU_KERNEL_VERSION
+#define UBUNTU_KERNEL_VERSION(a,b,c,abi,upload) (((a) << 40) + ((b) << 32) +
((c) << 24) + ((abi) << 8) + (upload))
+#endif
+#ifndef UBUNTU_RELEASE_CODE
+#define UBUNTU_RELEASE_CODE 0
+#endif
+#ifndef UBUNTU_KERNEL_CODE
+#define UBUNTU_KERNEL_CODE 0
+#endif
+
#ifdef __KLOCWORK__
#ifdef ARRAY_SIZE
#undef ARRAY_SIZE
@@ -3847,6 +3861,7 @@ static inline struct sk_buff
*__kc__vlan_hwaccel_put_tag(struct sk_buff *skb,
#if ( LINUX_VERSION_CODE < KERNEL_VERSION(3,14,0) )
#if (!(RHEL_RELEASE_CODE && RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(7,0)))
+#if (!(UBUNTU_RELEASE_CODE == UBUNTU_RELEASE_VERSION(14,4) &&
UBUNTU_KERNEL_CODE >= UBUNTU_KERNEL_VERSION(3,13,0,30,54)))
#ifdef NETIF_F_RXHASH
#define PKT_HASH_TYPE_L3 0
static inline void
@@ -3855,6 +3870,7 @@ skb_set_hash(struct sk_buff *skb, __u32 hash,
__always_unused int type)
skb->rxhash = hash;
}
#endif /* NETIF_F_RXHASH */
+#endif /* < 3.13.0-30.54 (Ubuntu 14.04) */
#endif /* < RHEL7 */
#endif /* < 3.14.0 */
--
1.7.0.7
[dpdk-dev] [PATCH v2] user space vhost driver library
Hi Franck: The natural wrapper for vhost library would be like port in OVDK, which you can receive from or send to. In DPDK, we have a vhost example, which demonstrates simple switching functionality between guest virtual machines. BR -huawei > -Original Message- > From: Franck BAUDIN [mailto:Franck.BAUDIN at qosmos.com] > Sent: Thursday, July 24, 2014 5:23 PM > To: Xie, Huawei; dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH v2] user space vhost driver library > > Hello, > > My understanding is that this is a helper library, but not a PMD driver. Is my > understanding correct? If so, do you plan to write a vhost PMD driver? > > Regards, > Franck. > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Xie, Huawei > > Sent: vendredi 18 juillet 2014 12:03 > > To: Xie, Huawei; dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v2] user space vhost driver library > > > > Merged two patches in previous patch set into 1. > > > > > -Original Message- > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Huawei Xie > > > Sent: Friday, July 18, 2014 5:56 PM > > > To: dev at dpdk.org > > > Subject: [dpdk-dev] [PATCH v2] user space vhost driver library > > > > > > This user space vhost library is based off user space vhost example > > > and aims to provide same API for different vhost implementations. This > > > implementation includes user space vhost cuse driver, kernel module > > > for eventfd proxy and vhost enqueue/dequeue functionalities. > > > > > > Huawei Xie (1): > > > vhost library support to facilitate integration with vswitch. > > > > > > config/common_linuxapp |7 + > > > lib/Makefile |1 + > > > lib/librte_vhost/Makefile| 48 ++ > > > lib/librte_vhost/eventfd_link/Makefile | 39 + > > > lib/librte_vhost/eventfd_link/eventfd_link.c | 205 ++ > > > lib/librte_vhost/eventfd_link/eventfd_link.h | 79 ++ > > > lib/librte_vhost/rte_virtio_net.h| 192 + > > > lib/librte_vhost/vhost-net-cdev.c| 363 ++ > > > lib/librte_vhost/vhost-net-cdev.h| 112 +++ > > > lib/librte_vhost/vhost_rxtx.c| 292 > > > lib/librte_vhost/virtio-net.c| 1002 > > ++ > > > 11 files changed, 2340 insertions(+) > > > create mode 100644 lib/librte_vhost/Makefile create mode 100644 > > > lib/librte_vhost/eventfd_link/Makefile > > > create mode 100644 lib/librte_vhost/eventfd_link/eventfd_link.c > > > create mode 100644 lib/librte_vhost/eventfd_link/eventfd_link.h > > > create mode 100644 lib/librte_vhost/rte_virtio_net.h create mode > > > 100644 lib/librte_vhost/vhost-net-cdev.c create mode 100644 > > > lib/librte_vhost/vhost-net-cdev.h create mode 100644 > > > lib/librte_vhost/vhost_rxtx.c create mode 100644 > > > lib/librte_vhost/virtio-net.c > > > > > > -- > > > 1.8.1.4 > > This message and any attachments (the "message") are confidential, intended > solely for the addressees. If you are not the intended recipient, please > notify the > sender immediately by e-mail and delete this message from your system. In this > case, you are not authorized to use, copy this message and/or disclose the > content to any other person. E-mails are susceptible to alteration. Neither > Qosmos nor any of its subsidiaries or affiliates shall be liable for the > message if > altered, changed or falsified. > > Ce message et toutes ses pi?ces jointes (ci-apr?s le "message")sont > confidentiels > et ?tablis ? l'intention exclusive de ses destinataires. Si vous avez re?u ce > message par erreur, merci d?en informer imm?diatement son ?metteur par > courrier ?lectronique et d?effacer ce message de votre syst?me. Dans cette > hypoth?se, vous n??tes pas autoris? ? utiliser, copier ce message et/ou en > divulguer le contenu ? un tiers. Tout message ?lectronique est susceptible > d'alt?ration. Qosmos et ses filiales d?clinent toute responsabilit? au titre > de ce > message s'il a ?t? alt?r?, d?form? ou falsifi?.
[dpdk-dev] rte_eth_dev_configure
2014-07-24 15:00, sothy shan: > I have problem when I try dpdk ovs with DPDK 1.7. DPDK 1.7 alone working > well. [...] > I am not sure when I using DPDK ovs, how to debug at DPDK 1.7.0 code. I > guess I need to enable to print PMD_DEBUG_TRACE message. At this point, > DPDK ovs message is only printed. You should enable CONFIG_RTE_LIBRTE_ETHDEV_DEBUG before compiling. > I too suspect it is problem with port_conf message. Not sure. First I need > to know how to use PMD_DEBUG_TRACE with DPDK_ovs. > > You understand my question? Yes I understand that you should enable debugging and ask for help on the right mailling list. If DPDK alone works well, we cannot do anything for you. -- Thomas
[dpdk-dev] rte_eth_dev_configure
I have problem when I try dpdk ovs with DPDK 1.7. DPDK 1.7 alone working well. Drive I installed is compiled with T=x86_64-ivshmem-linuxapp-gcc. I am not sure when I using DPDK ovs, how to debug at DPDK 1.7.0 code. I guess I need to enable to print PMD_DEBUG_TRACE message. At this point, DPDK ovs message is only printed. I too suspect it is problem with port_conf message. Not sure. First I need to know how to use PMD_DEBUG_TRACE with DPDK_ovs. You understand my question? Thanks again On Thu, Jul 24, 2014 at 2:51 PM, Thomas Monjalon wrote: > 2014-07-24 14:44, Thomas Monjalon: > > 2014-07-24 14:34, sothy shan: > > > Second, any clue why rte_eth_dev_configure give an error with code -22? > > > > It depends of your driver. > > Example: #define IXGBE_ERR_NO_SAN_ADDR_PTR -22 > > It's more probably -EINVAL without driver dependency. > It means there is a mistake in your configuration. > PMD_DEBUG_TRACE will help you. > > -- > Thomas >
[dpdk-dev] rte_eth_dev_configure
2014-07-24 14:44, Thomas Monjalon: > 2014-07-24 14:34, sothy shan: > > Second, any clue why rte_eth_dev_configure give an error with code -22? > > It depends of your driver. > Example: #define IXGBE_ERR_NO_SAN_ADDR_PTR -22 It's more probably -EINVAL without driver dependency. It means there is a mistake in your configuration. PMD_DEBUG_TRACE will help you. -- Thomas
[dpdk-dev] rte_eth_dev_configure
Hello, 2014-07-24 14:34, sothy shan: > I am trying to use DPDK ovs (development branch) with DPDK1.7. Could you try with testpmd? > Cannot initi NIC port 0 (-22). > > Based on my search within code, rte_eth_dev_configure gives an error with > code -22. Which driver are you using? > My question is that how to debug or print the PMD_DEBUG_TRACE into file or > terminal when running ovs-dpdk? The default is to print on stdout. > Second, any clue why rte_eth_dev_configure give an error with code -22? It depends of your driver. Example: #define IXGBE_ERR_NO_SAN_ADDR_PTR -22 -- Thomas
[dpdk-dev] [PATCH 5/5] app/testpmd: new commands for configuring hash functions
Six commands are added in testpmd to support configuring
hash functions. They are,
* i40e_get_sym_hash_ena_per_port
* i40e_set_sym_hash_ena_per_port
* i40e_get_sym_hash_ena_per_pctype
* i40e_set_sym_hash_ena_per_pctype
* i40e_get_filter_swap
* i40e_set_filter_swap
Signed-off-by: Helin Zhang
---
app/test-pmd/cmdline.c | 455 +
1 file changed, 455 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 345be11..0e075da 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -74,6 +74,10 @@
#include
#include
#include
+#include
+#ifdef RTE_LIBRTE_I40E_PMD
+#include
+#endif
#include
#include
@@ -655,6 +659,34 @@ static void cmd_help_long_parsed(void *parsed_result,
"get_flex_filter (port_id) index (idx)\n"
"get info of a flex filter.\n\n"
+
+#ifdef RTE_LIBRTE_I40E_PMD
+ "i40e_get_sym_hash_ena_per_port (port_id)\n"
+ "get symmetric hash enable configuration per port,"
+ " on i40e only\n\n"
+
+ "i40e_set_sym_hash_ena_per_port (port_id)"
+ " enable|disable\n"
+ "set symmetric hash enable configuration per port"
+ " to enable or disable, on i40e only\n\n"
+
+ "i40e_get_sym_hash_ena_per_pctype (port_id) (pctype)\n"
+ "get symmetric hash enable configuration per port,"
+ " on i40e only\n\n"
+
+ "i40e_set_sym_hash_ena_per_pctype (port_id) (pctype)"
+ " enable|disable\n"
+ "set symmetric hash enable configuration per"
+ " pctype to enable or disable, on i40e only\n\n"
+
+ "i40e_get_filter_swap (port_id) (pctype)\n"
+ "get filter swap configurations on i40e,"
+ " on i40e only\n\n"
+
+ "i40e_set_filter_swap (port_id) (pctype) (off0_src0)"
+ " (off0_src1) (len0) (off1_src0) (off1_src1) (len1)\n"
+ "set filter swap configurations, on i40e only\n\n"
+#endif /* RTE_LIBRTE_I40E_PMD */
);
}
}
@@ -7304,6 +7336,421 @@ cmdline_parse_inst_t cmd_get_flex_filter = {
},
};
+/* *** Classification Filters Control *** */
+#ifdef RTE_LIBRTE_I40E_PMD
+/* *** Get symmetric hash enable per port *** */
+struct cmd_i40e_get_sym_hash_ena_per_port_result {
+ cmdline_fixed_string_t i40e_get_sym_hash_ena_per_port;
+ uint8_t port_id;
+};
+
+static void
+cmd_i40e_get_sym_hash_per_port_parsed(void *parsed_result,
+ __rte_unused struct cmdline *cl,
+ __rte_unused void *data)
+{
+ struct cmd_i40e_get_sym_hash_ena_per_port_result *res = parsed_result;
+ uint8_t enable = 0;
+ int ret;
+
+ if (rte_eth_dev_check_command_supported(res->port_id,
+ RTE_CMD_GET_SYM_HASH_ENABLE_PER_PORT) <= 0) {
+ printf("Command of RTE_CMD_GET_SYM_HASH_ENABLE_PER_PORT "
+ "not supported on port: %d\n", res->port_id);
+ return;
+ }
+
+ ret = rte_eth_dev_rx_classification_filter_ctl(res->port_id,
+ RTE_CMD_GET_SYM_HASH_ENABLE_PER_PORT, &enable);
+ if (ret < 0) {
+ printf("Cannot get symmetric hash enable per port "
+ "on i40e port %u\n", res->port_id);
+ return;
+ }
+
+ printf("Symmetric hash is %s on i40e port %u\n",
+ enable ? "enabled" : "disabled", res->port_id);
+}
+
+cmdline_parse_token_string_t cmd_i40e_get_sym_hash_ena_per_port_all =
+ TOKEN_STRING_INITIALIZER(
+ struct cmd_i40e_get_sym_hash_ena_per_port_result,
+ i40e_get_sym_hash_ena_per_port,
+ "i40e_get_sym_hash_ena_per_port");
+cmdline_parse_token_num_t cmd_i40e_get_sym_hash_ena_per_port_port_id =
+ TOKEN_NUM_INITIALIZER(struct cmd_i40e_get_sym_hash_ena_per_port_result,
+ port_id, UINT8);
+
+cmdline_parse_inst_t cmd_i40e_get_sym_hash_ena_per_port = {
+ .f = cmd_i40e_get_sym_hash_per_port_parsed,
+ .data = NULL,
+ .help_str = "i40e_get_sym_hash_ena_per_port port_id",
+ .tokens = {
+ (void *)&cmd_i40e_get_sym_hash_ena_per_port_all,
+ (void *)&cmd_i40e_get_sym_hash_ena_per_port_port_id,
+ NULL,
+ },
+};
+
+/* *** Set symmetric hash enable per port *** */
+struct cmd_i40e_set_sym_hash_ena_per_port_result {
+ cmdline_fixed_string_t i40e_set_sym_hash_ena_per_port;
+ cmdline_fixed_string_t enable;
+ uint8_t port_id;
+};
+
+static void
+cmd_i40e_set_sym_hash_per_port_parsed(void *parsed_result,
+
[dpdk-dev] [PATCH 4/5] i40e: support configuring symmetric hash function
Symmetric hash function can be configured:
* Set symmetric hash enable per port.
* Set symmetric hash enable per pctype (packet classification type).
* Set the swap configurations.
Commands are implemented for 'rx_classification_filter_ctl'
to support above operations which can be called in applications.
Also 'check_command_supported' is also implemented to check if
a specific capability(command) is supported or not.
Signed-off-by: Helin Zhang
---
lib/librte_ether/Makefile | 1 +
lib/librte_ether/rte_eth_features.h | 65 ++
lib/librte_pmd_i40e/Makefile| 6 +
lib/librte_pmd_i40e/i40e_ethdev.c | 409
lib/librte_pmd_i40e/rte_i40e.h | 95 +
5 files changed, 576 insertions(+)
create mode 100644 lib/librte_ether/rte_eth_features.h
create mode 100644 lib/librte_pmd_i40e/rte_i40e.h
diff --git a/lib/librte_ether/Makefile b/lib/librte_ether/Makefile
index b310f8b..8089723 100644
--- a/lib/librte_ether/Makefile
+++ b/lib/librte_ether/Makefile
@@ -46,6 +46,7 @@ SRCS-y += rte_ethdev.c
#
SYMLINK-y-include += rte_ether.h
SYMLINK-y-include += rte_ethdev.h
+SYMLINK-y-include += rte_eth_features.h
# this lib depends upon:
DEPDIRS-y += lib/librte_eal lib/librte_mempool lib/librte_ring lib/librte_mbuf
diff --git a/lib/librte_ether/rte_eth_features.h
b/lib/librte_ether/rte_eth_features.h
new file mode 100644
index 000..d1790e2
--- /dev/null
+++ b/lib/librte_ether/rte_eth_features.h
@@ -0,0 +1,65 @@
+/*-
+ * 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 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_ETH_FEATURES_H_
+#define _RTE_ETH_FEATURES_H_
+
+/**
+ * @file
+ *
+ * Ethernet device specific features
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#define RTE_CMD_UNKNOWN0
+/**< Command unknown. */
+#define RTE_CMD_GET_SYM_HASH_ENABLE_PER_PCTYPE 1
+/**< Command to set symmetric hash enable per pctype. */
+#define RTE_CMD_SET_SYM_HASH_ENABLE_PER_PCTYPE 2
+/**< Command to get symmetric hash enable per port. */
+#define RTE_CMD_GET_SYM_HASH_ENABLE_PER_PORT 3
+/**< Command to set symmetric hash enable per port. */
+#define RTE_CMD_SET_SYM_HASH_ENABLE_PER_PORT 4
+/**< Command to get filter swap configurations. */
+#define RTE_CMD_GET_FILTER_SWAP5
+/**< Command to set filter swap configurations. */
+#define RTE_CMD_SET_FILTER_SWAP6
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_ETH_FEATURES_H_ */
diff --git a/lib/librte_pmd_i40e/Makefile b/lib/librte_pmd_i40e/Makefile
index 4b31675..a777a76 100644
--- a/lib/librte_pmd_i40e/Makefile
+++ b/lib/librte_pmd_i40e/Makefile
@@ -87,6 +87,12 @@ SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_ethdev.c
SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_rxtx.c
SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_ethdev_vf.c
SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_pf.c
+
+#
+# Export include file
+#
+SYMLINK-$(CONFIG_RTE_LIBRTE_I40E_PMD)-include += rte_i40e.h
+
# this lib depends upon:
DEPDIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += lib/librte_eal lib/librte_ether
DEPDIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += lib/librte_mempool lib/librte_mbuf
diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c
b/lib/librte_pmd_i40e/i40e_ethdev.c
index cc04c70..b699638 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -48,7 +48,9 @@
[dpdk-dev] [PATCH 3/5] i40e: support selecting hash functions
Toeplitz and simple XOR hash functions are supported by
hardware, code changes are to tell the hardware which hash
function is selected according to the configuration.
Signed-off-by: Helin Zhang
---
config/common_bsdapp | 1 +
config/common_linuxapp| 1 +
lib/librte_pmd_i40e/i40e_ethdev.c | 30 ++
3 files changed, 32 insertions(+)
diff --git a/config/common_bsdapp b/config/common_bsdapp
index bf6d8a0..e73629e 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -187,6 +187,7 @@ CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
# interval up to 8160 us, aligned to 2 (or default value)
CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=-1
+CONFIG_RTE_LIBRTE_I40E_HASH_FUNC_TOEPLITZ=y
#
# Compile burst-oriented VIRTIO PMD driver
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 9047975..9e00513 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -210,6 +210,7 @@ CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
# interval up to 8160 us, aligned to 2 (or default value)
CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=-1
+CONFIG_RTE_LIBRTE_I40E_HASH_FUNC_TOEPLITZ=y
#
# Compile burst-oriented VIRTIO PMD driver
diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c
b/lib/librte_pmd_i40e/i40e_ethdev.c
index 9ed31b5..cc04c70 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -203,6 +203,7 @@ static int i40e_dev_rss_hash_update(struct rte_eth_dev *dev,
struct rte_eth_rss_conf *rss_conf);
static int i40e_dev_rss_hash_conf_get(struct rte_eth_dev *dev,
struct rte_eth_rss_conf *rss_conf);
+static void i40e_select_hash_function(struct i40e_hw *hw);
/* Default hash key buffer for RSS */
static uint32_t rss_key_default[I40E_PFQF_HKEY_MAX_INDEX + 1];
@@ -384,6 +385,9 @@ eth_i40e_dev_init(__rte_unused struct eth_driver *eth_drv,
return ret;
}
+ /* Select hash functions */
+ i40e_select_hash_function(hw);
+
/* Initialize the shared code (base driver) */
ret = i40e_init_shared_code(hw);
if (ret) {
@@ -3956,3 +3960,29 @@ i40e_pf_config_mq_rx(struct i40e_pf *pf)
return 0;
}
+
+static void
+i40e_select_hash_function(struct i40e_hw *hw)
+{
+ uint32_t reg;
+
+ reg = I40E_READ_REG(hw, I40E_GLQF_CTL);
+#ifdef RTE_LIBRTE_I40E_HASH_FUNC_TOEPLITZ
+ if (reg & I40E_GLQF_CTL_HTOEP_MASK) {
+ PMD_DRV_LOG(DEBUG, "Hash function already set to Hoeplitz\n");
+ return;
+ }
+ reg |= I40E_GLQF_CTL_HTOEP_MASK;
+#else
+ if (!(reg & I40E_GLQF_CTL_HTOEP_MASK)) {
+ PMD_DRV_LOG(DEBUG, "Hash function already set to "
+ "Simple XOR\n");
+ return;
+ }
+ reg &= ~I40E_GLQF_CTL_HTOEP_MASK;
+#endif
+ PMD_DRV_LOG(INFO, "Hash function set to %s\n",
+ (reg & I40E_GLQF_CTL_HTOEP_MASK) ? "Toeplitz" : "XOR");
+ I40E_WRITE_REG(hw, I40E_GLQF_CTL, reg);
+ I40E_WRITE_FLUSH(hw);
+}
--
1.8.1.4
[dpdk-dev] [PATCH 2/5] ethdev: add new ops of 'check_command_supported' and 'rx_classification_filter_ctl'
Two ops of 'check_command_supported' and 'rx_classification_filter_ctl'
are added.
* 'check_command_supported' is for capability discovery. In anothoer
word, it is to check if specific feature/command is supported by
the specific port.
* 'rx_classification_filter_ctl' is for receive classifcation filter
configuring. e.g. hash function configuration, flow director
configuration. It is a common API where a lot of commands can
be implemented for different sub features.
Signed-off-by: Helin Zhang
---
lib/librte_ether/rte_ethdev.c | 31 ++
lib/librte_ether/rte_ethdev.h | 52 +++
2 files changed, 83 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index fd1010a..7afffb4 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -3002,3 +3002,34 @@ rte_eth_dev_get_flex_filter(uint8_t port_id, uint16_t
index,
return (*dev->dev_ops->get_flex_filter)(dev, index, filter,
rx_queue);
}
+
+int
+rte_eth_dev_check_command_supported(uint8_t port_id, uint32_t cmd)
+{
+ struct rte_eth_dev *dev;
+
+ if (port_id >= nb_ports) {
+ PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
+ return -ENODEV;
+ }
+ dev = &rte_eth_devices[port_id];
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->check_command_supported, -ENOTSUP);
+ return (*dev->dev_ops->check_command_supported)(dev, cmd);
+}
+
+int
+rte_eth_dev_rx_classification_filter_ctl(uint8_t port_id,
+uint32_t cmd,
+void *args)
+{
+ struct rte_eth_dev *dev;
+
+ if (port_id >= nb_ports) {
+ PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
+ return -ENODEV;
+ }
+ dev = &rte_eth_devices[port_id];
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_classification_filter_ctl,
+ -ENOTSUP);
+ return (*dev->dev_ops->rx_classification_filter_ctl)(dev, cmd, args);
+}
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index a262463..482e64d 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1240,6 +1240,15 @@ typedef int (*eth_mirror_rule_reset_t)(struct
rte_eth_dev *dev,
uint8_t rule_id);
/**< @internal Remove a traffic mirroring rule on an Ethernet device */
+typedef int (*eth_check_command_supported_t)(struct rte_eth_dev *dev,
+uint32_t cmd);
+/**< @internal check if the command is supported by the Ethernet device */
+
+typedef int (*eth_rx_classification_filter_ctl_t)(struct rte_eth_dev *dev,
+ uint32_t cmd,
+ void *arg);
+/**< @internal receive classification filter control operations */
+
#ifdef RTE_NIC_BYPASS
enum {
@@ -1467,6 +1476,10 @@ struct eth_dev_ops {
eth_add_flex_filter_t add_flex_filter; /**< add flex
filter. */
eth_remove_flex_filter_t remove_flex_filter; /**< remove flex
filter. */
eth_get_flex_filter_t get_flex_filter; /**< get flex
filter. */
+ eth_check_command_supported_t check_command_supported;
+ /**< check if a command is supported. */
+ eth_rx_classification_filter_ctl_t rx_classification_filter_ctl;
+ /**< common control function of hw hash */
};
/**
@@ -3557,6 +3570,45 @@ int rte_eth_dev_remove_flex_filter(uint8_t port_id,
uint16_t index);
int rte_eth_dev_get_flex_filter(uint8_t port_id, uint16_t index,
struct rte_flex_filter *filter, uint16_t *rx_queue);
+/**
+ * Check if the command is supported by an Ethernet device.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param cmd
+ * The command.
+ *
+ * @return
+ * - (> 0) The command is supported.
+ * - (0) The command is not supported.
+ * - (-ENOTSUP) if hardware doesn't support.
+ * - (-ENODEV) if is invalid.
+ */
+int rte_eth_dev_check_command_supported(uint8_t port_id, uint32_t cmd);
+
+/**
+ * Control the receive classification filter, including hash function
+ * selection. The commands are NIC specific in its exported public
+ * header file. Different types of NIC may have different commands.
+ * For example, the supported commands for i40e can be found in rte_i40e.h.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param cmd
+ * The commands.
+ * @param args
+ * A pointer to arguments defined specifically for the command.
+ *
+ * @return
+ * - (0) if successful.
+ * - (-ENOTSUP) if hardware doesn't support.
+ * - (-ENODEV) if is invalid.
+ * - others depends on the specific command implementation.
+ */
+int rte_eth_dev_rx_classification_filte
[dpdk-dev] [PATCH 1/5] ethdev: Rename macros of packet classification type
For better understanding, 'PCTYPE' was added to the name of i40e
RSS shift macros.
Signed-off-by: Helin Zhang
---
lib/librte_ether/rte_ethdev.h | 74 +--
1 file changed, 37 insertions(+), 37 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 50df654..a262463 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -346,46 +346,46 @@ struct rte_eth_rss_conf {
#define ETH_RSS_IPV6_UDP_SHIFT7
#define ETH_RSS_IPV6_UDP_EX_SHIFT 8
/* for 40G only */
-#define ETH_RSS_NONF_IPV4_UDP_SHIFT 31
-#define ETH_RSS_NONF_IPV4_TCP_SHIFT 33
-#define ETH_RSS_NONF_IPV4_SCTP_SHIFT 34
-#define ETH_RSS_NONF_IPV4_OTHER_SHIFT 35
-#define ETH_RSS_FRAG_IPV4_SHIFT 36
-#define ETH_RSS_NONF_IPV6_UDP_SHIFT 41
-#define ETH_RSS_NONF_IPV6_TCP_SHIFT 43
-#define ETH_RSS_NONF_IPV6_SCTP_SHIFT 44
-#define ETH_RSS_NONF_IPV6_OTHER_SHIFT 45
-#define ETH_RSS_FRAG_IPV6_SHIFT 46
-#define ETH_RSS_FCOE_OX_SHIFT 48
-#define ETH_RSS_FCOE_RX_SHIFT 49
-#define ETH_RSS_FCOE_OTHER_SHIFT 50
-#define ETH_RSS_L2_PAYLOAD_SHIFT 63
+#define ETH_PCTYPE_NONF_IPV4_UDP 31
+#define ETH_PCTYPE_NONF_IPV4_TCP 33
+#define ETH_PCTYPE_NONF_IPV4_SCTP 34
+#define ETH_PCTYPE_NONF_IPV4_OTHER35
+#define ETH_PCTYPE_FRAG_IPV4 36
+#define ETH_PCTYPE_NONF_IPV6_UDP 41
+#define ETH_PCTYPE_NONF_IPV6_TCP 43
+#define ETH_PCTYPE_NONF_IPV6_SCTP 44
+#define ETH_PCTYPE_NONF_IPV6_OTHER45
+#define ETH_PCTYPE_FRAG_IPV6 46
+#define ETH_PCTYPE_FCOE_OX48 /* not used */
+#define ETH_PCTYPE_FCOE_RX49 /* not used */
+#define ETH_PCTYPE_FCOE_OTHER 50 /* not used */
+#define ETH_PCTYPE_L2_PAYLOAD 63
/* for 1G & 10G */
-#define ETH_RSS_IPV4((uint16_t)1 << ETH_RSS_IPV4_SHIFT)
-#define ETH_RSS_IPV4_TCP((uint16_t)1 << ETH_RSS_IPV4_TCP_SHIFT)
-#define ETH_RSS_IPV6((uint16_t)1 << ETH_RSS_IPV6_SHIFT)
-#define ETH_RSS_IPV6_EX ((uint16_t)1 << ETH_RSS_IPV6_EX_SHIFT)
-#define ETH_RSS_IPV6_TCP((uint16_t)1 << ETH_RSS_IPV6_TCP_SHIFT)
-#define ETH_RSS_IPV6_TCP_EX ((uint16_t)1 <<
ETH_RSS_IPV6_TCP_EX_SHIFT)
-#define ETH_RSS_IPV4_UDP((uint16_t)1 << ETH_RSS_IPV4_UDP_SHIFT)
-#define ETH_RSS_IPV6_UDP((uint16_t)1 << ETH_RSS_IPV6_UDP_SHIFT)
-#define ETH_RSS_IPV6_UDP_EX ((uint16_t)1 <<
ETH_RSS_IPV6_UDP_EX_SHIFT)
+#define ETH_RSS_IPV4(1 << ETH_RSS_IPV4_SHIFT)
+#define ETH_RSS_IPV4_TCP(1 << ETH_RSS_IPV4_TCP_SHIFT)
+#define ETH_RSS_IPV6(1 << ETH_RSS_IPV6_SHIFT)
+#define ETH_RSS_IPV6_EX (1 << ETH_RSS_IPV6_EX_SHIFT)
+#define ETH_RSS_IPV6_TCP(1 << ETH_RSS_IPV6_TCP_SHIFT)
+#define ETH_RSS_IPV6_TCP_EX (1 << ETH_RSS_IPV6_TCP_EX_SHIFT)
+#define ETH_RSS_IPV4_UDP(1 << ETH_RSS_IPV4_UDP_SHIFT)
+#define ETH_RSS_IPV6_UDP(1 << ETH_RSS_IPV6_UDP_SHIFT)
+#define ETH_RSS_IPV6_UDP_EX (1 << ETH_RSS_IPV6_UDP_EX_SHIFT)
/* for 40G only */
-#define ETH_RSS_NONF_IPV4_UDP ((uint64_t)1 <<
ETH_RSS_NONF_IPV4_UDP_SHIFT)
-#define ETH_RSS_NONF_IPV4_TCP ((uint64_t)1 <<
ETH_RSS_NONF_IPV4_TCP_SHIFT)
-#define ETH_RSS_NONF_IPV4_SCTP ((uint64_t)1 <<
ETH_RSS_NONF_IPV4_SCTP_SHIFT)
-#define ETH_RSS_NONF_IPV4_OTHER ((uint64_t)1 <<
ETH_RSS_NONF_IPV4_OTHER_SHIFT)
-#define ETH_RSS_FRAG_IPV4 ((uint64_t)1 <<
ETH_RSS_FRAG_IPV4_SHIFT)
-#define ETH_RSS_NONF_IPV6_UDP ((uint64_t)1 <<
ETH_RSS_NONF_IPV6_UDP_SHIFT)
-#define ETH_RSS_NONF_IPV6_TCP ((uint64_t)1 <<
ETH_RSS_NONF_IPV6_TCP_SHIFT)
-#define ETH_RSS_NONF_IPV6_SCTP ((uint64_t)1 <<
ETH_RSS_NONF_IPV6_SCTP_SHIFT)
-#define ETH_RSS_NONF_IPV6_OTHER ((uint64_t)1 <<
ETH_RSS_NONF_IPV6_OTHER_SHIFT)
-#define ETH_RSS_FRAG_IPV6 ((uint64_t)1 <<
ETH_RSS_FRAG_IPV6_SHIFT)
-#define ETH_RSS_FCOE_OX ((uint64_t)1 << ETH_RSS_FCOE_OX_SHIFT)
/* not used */
-#define ETH_RSS_FCOE_RX ((uint64_t)1 << ETH_RSS_FCOE_RX_SHIFT)
/* not used */
-#define ETH_RSS_FCOE_OTHER ((uint64_t)1 <<
ETH_RSS_FCOE_OTHER_SHIFT) /* not used */
-#define ETH_RSS_L2_PAYLOAD ((uint64_t)1 <<
ETH_RSS_L2_PAYLOAD_SHIFT)
+#define ETH_RSS_NONF_IPV4_UDP (1ULL << ETH_PCTYPE_NONF_IPV4_UDP)
+#define ETH_RSS_NONF_IPV4_TCP (1ULL << ETH_PCTYPE_NONF_IPV4_TCP)
+#define ETH_RSS_NONF_IPV4_SCTP (1ULL << ETH_PCTYPE_NONF_IPV4_SCTP)
+#define ETH_RSS_NONF_IPV4_OTHER (1ULL << ETH_PCTYPE_NONF_IPV4_OTHER)
+#define
[dpdk-dev] [PATCH 0/5] Support configuring hash functions
These pathches mainly support configuring hash functions. In detail, it can select Toeplitz and simple XOR hash functions. It can configure symmetric hash function. Also 'ethdev' level interfaces are implemented in i40e, which provides commands for application invoking, and to check if specific capability (command) is supported on a port. Helin Zhang (5): ethdev: Rename macros of packet classification type ethdev: add new ops of 'check_command_supported' and 'rx_classification_filter_ctl' i40e: support selecting hash functions i40e: support configuring symmetric hash function app/testpmd: new commands for configuring hash functions app/test-pmd/cmdline.c | 455 config/common_bsdapp| 1 + config/common_linuxapp | 1 + lib/librte_ether/Makefile | 1 + lib/librte_ether/rte_eth_features.h | 65 ++ lib/librte_ether/rte_ethdev.c | 31 +++ lib/librte_ether/rte_ethdev.h | 126 +++--- lib/librte_pmd_i40e/Makefile| 6 + lib/librte_pmd_i40e/i40e_ethdev.c | 439 ++ lib/librte_pmd_i40e/rte_i40e.h | 95 10 files changed, 1183 insertions(+), 37 deletions(-) create mode 100644 lib/librte_ether/rte_eth_features.h create mode 100644 lib/librte_pmd_i40e/rte_i40e.h -- 1.8.1.4
[dpdk-dev] Pktgen-DPDK compile error on Ubuntu 14.04
Hi Luke, From: lukego at gmail.com [mailto:luk...@gmail.com] On Behalf Of Luke Gorrie Sent: Thursday, July 24, 2014 11:58 AM To: De Lara Guarch, Pablo Cc: dev at dpdk.org; Putteneers, SvenX Subject: Re: [dpdk-dev] Pktgen-DPDK compile error on Ubuntu 14.04 Hi Pablo, On 24 July 2014 12:33, De Lara Guarch, Pablo mailto:pablo.de.lara.guarch at intel.com>> wrote: I think you are seeing the same error as other people are seeing for DPDK-1.7 on Ubuntu 14.04. Are you using kernel 3.13.0-24 or 3.13.0-30/32? Thanks for the quick response. I'm currently using kernel 3.13.0-24. The patch I just sent should fix your issue. Thanks, Pablo
[dpdk-dev] rte_eth_dev_configure
Hello! I am trying to use DPDK ovs (development branch) with DPDK1.7. There is an error when running ovs_dpdk command. Error is PANIC in ovdk_vport_phy_port_init. Cannot initi NIC port 0 (-22). Based on my search within code, rte_eth_dev_configure gives an error with code -22. My question is that how to debug or print the PMD_DEBUG_TRACE into file or terminal when running ovs-dpdk? Second, any clue why rte_eth_dev_configure give an error with code -22? Thanks for your help. Best regards Sothy
[dpdk-dev] [PATCH] ixgbe: convert sse intrinsics to use __builtin variants
The ixgbe pmd currently can't be built without enabling sse instructions at compile time. While sse extensions provide better performance, theres no reason that we can't still create builds to run on systems that don't support sse. If we modify the ixgbe code to use the __builtin_shuffle and __builtin_popcountll functions, I've confirmed that the gcc compiler emits the appropriate sse instructions when the provided -march parameter indicates a machine that includes sse support, and emits generic code when see isn't available. Signed-off-by: Neil Horman CC: Thomas Monjalon --- lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c index 09e19a3..5747072 100644 --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c @@ -38,8 +38,6 @@ #include "ixgbe_ethdev.h" #include "ixgbe_rxtx.h" -#include - #ifndef __INTEL_COMPILER #pragma GCC diagnostic ignored "-Wcast-qual" #endif @@ -294,8 +292,8 @@ ixgbe_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts, rte_compiler_barrier(); /* D.1 pkt 3,4 convert format from desc to pktmbuf */ - pkt_mb4 = _mm_shuffle_epi8(descs[3], shuf_msk); - pkt_mb3 = _mm_shuffle_epi8(descs[2], shuf_msk); + pkt_mb4 = __builtin_shuffle(descs[3], shuf_msk); + pkt_mb3 = __builtin_shuffle(descs[2], shuf_msk); /* C.1 4=>2 filter staterr info only */ sterr_tmp2 = _mm_unpackhi_epi32(descs[3], descs[2]); @@ -310,8 +308,8 @@ ixgbe_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts, pkt_mb3 = _mm_add_epi16(pkt_mb3, in_port); /* D.1 pkt 1,2 convert format from desc to pktmbuf */ - pkt_mb2 = _mm_shuffle_epi8(descs[1], shuf_msk); - pkt_mb1 = _mm_shuffle_epi8(descs[0], shuf_msk); + pkt_mb2 = __builtin_shuffle(descs[1], shuf_msk); + pkt_mb1 = __builtin_shuffle(descs[0], shuf_msk); /* C.2 get 4 pkts staterr value */ zero = _mm_xor_si128(dd_check, dd_check); @@ -338,7 +336,7 @@ ixgbe_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts, pkt_mb1); /* C.4 calc avaialbe number of desc */ - var = _mm_popcnt_u64(_mm_cvtsi128_si64(staterr)); + var = __builtin_popcountll(_mm_cvtsi128_si64(staterr)); nb_pkts_recd += var; if (likely(var != RTE_IXGBE_DESCS_PER_LOOP)) break; -- 1.8.3.1
[dpdk-dev] Performance - linking against DPDK shared vs static libraries
Many thanks to all for your help. -Original Message- From: Matthew Hall [mailto:mh...@mhcomputing.net] Sent: Wednesday, July 23, 2014 10:56 PM To: Kavanagh, Mark B Cc: Antti Kantee; dev at dpdk.org Subject: Re: [dpdk-dev] Performance - linking against DPDK shared vs static libraries On Wed, Jul 23, 2014 at 09:43:49PM +, Kavanagh, Mark B wrote: > I take it ... that the performance drop when using shared libraries is > expected behavior? s/expected behavior/and unavoidable consequence/g ;) Matthew Hall. -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
[dpdk-dev] Pktgen-DPDK compile error on Ubuntu 14.04
Hi Pablo, On 24 July 2014 12:33, De Lara Guarch, Pablo wrote: > I think you are seeing the same error as other people are seeing for > DPDK-1.7 on Ubuntu 14.04. > Are you using kernel 3.13.0-24 or 3.13.0-30/32? > Thanks for the quick response. I'm currently using kernel 3.13.0-24.
[dpdk-dev] [PATCH] virtio: Fix 2 compilation issues in virtio PMD
Fix 2 compilation issues in virtio PMD when dump option is enabled. Signed-off-by: Changchun Ouyang --- lib/librte_pmd_virtio/virtio_ethdev.c | 2 +- lib/librte_pmd_virtio/virtqueue.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c b/lib/librte_pmd_virtio/virtio_ethdev.c index b9f5529..6293ac6 100644 --- a/lib/librte_pmd_virtio/virtio_ethdev.c +++ b/lib/librte_pmd_virtio/virtio_ethdev.c @@ -580,7 +580,7 @@ virtio_negotiate_features(struct virtio_hw *hw) /* Prepare guest_features: feature that driver wants to support */ hw->guest_features = VTNET_FEATURES & ~mask; PMD_INIT_LOG(DEBUG, "guest_features before negotiate = %x", - guest_features); + hw->guest_features); /* Read device(host) feature bits */ host_features = VIRTIO_READ_REG_4(hw, VIRTIO_PCI_HOST_FEATURES); diff --git a/lib/librte_pmd_virtio/virtqueue.h b/lib/librte_pmd_virtio/virtqueue.h index 02fe00b..87db35f 100644 --- a/lib/librte_pmd_virtio/virtqueue.h +++ b/lib/librte_pmd_virtio/virtqueue.h @@ -269,10 +269,10 @@ virtqueue_notify(struct virtqueue *vq) used_idx = (vq)->vq_ring.used->idx; \ nused = (uint16_t)(used_idx - (vq)->vq_used_cons_idx); \ PMD_INIT_LOG(DEBUG, \ - "VQ: %s - size=%d; free=%d; used=%d; desc_head_idx=%d;" \ + "VQ: - size=%d; free=%d; used=%d; desc_head_idx=%d;" \ " avail.idx=%d; used_cons_idx=%d; used.idx=%d;" \ " avail.flags=0x%x; used.flags=0x%x", \ - (vq)->vq_name, (vq)->vq_nentries, (vq)->vq_free_cnt, nused, \ + (vq)->vq_nentries, (vq)->vq_free_cnt, nused, \ (vq)->vq_desc_head_idx, (vq)->vq_ring.avail->idx, \ (vq)->vq_used_cons_idx, (vq)->vq_ring.used->idx, \ (vq)->vq_ring.avail->flags, (vq)->vq_ring.used->flags); \ -- 1.8.4.2
[dpdk-dev] About round trip latency with DPDK
Refer to DPDK getting started guide paragraph 5.4. It might help. Also it might be easier to do write simple application that send a packet on port 1 and rx it on port 2 in separate threads on separate cores (simple physical loop). You can then add timestamp and send packet back and see how long it will take TX to RX and RX to TX process. Pawel Wodkowski -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
[dpdk-dev] About round trip latency with DPDK
Kai, the latency depends both on what you do and how much you send. A bigger packet will take longer time to transmit. Now that thats out of the way I propose you use perf to see how busy is the cpu and with what. FYI, ~10us is something that can be achieved with netperf with a kernel driver based on interrupts. The 0.7m latency indicates that something is wrong with your system. Basically make sure that the cpu is busy with polling only and a small percent handling the messages. Hope this helps somehow. On Wed, Jul 23, 2014 at 10:24 PM, Kai Zhang wrote: > Hello, > > I am trying to develop a low-latency application, and I measured the round > trip latency with DPDK. However I got an average of 650~720 microseconds > round-trip latency with Intel 82599 10Gbps NIC. > > The experiment method is as follows. 2 machines (A and B) are connected > back-to-back. Machine A embeds a time stamp in the packet and sends to B, B > (use testpmd or l2fwd) forwards packets back to A immediately (A->B->A), > and A receives packets and calculates time difference between current time > and the embedded time stamp. (code : > https://github.com/kay21s/dpdk/tree/master/examples/recv_send) > > I have 3 machines, and performing the above experiment on each pair leads > to a similar latency. However, previous academic papers report that DPDK > offers only a few 10 microseconds round trip latency. > > What's the round trip latency DPDK is supposed to offer? Have you measured > it at Intel? > > Thanks a lot, > Kai
[dpdk-dev] Pktgen-DPDK compile error on Ubuntu 14.04
Hi Luke, I think you are seeing the same error as other people are seeing for DPDK-1.7 on Ubuntu 14.04. Are you using kernel 3.13.0-24 or 3.13.0-30/32? Thanks, Pablo > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Luke Gorrie > Sent: Thursday, July 24, 2014 9:16 AM > To: dev at dpdk.org > Cc: Putteneers, SvenX > Subject: [dpdk-dev] Pktgen-DPDK compile error on Ubuntu 14.04 > > Howdy! > > I am having trouble building Pktgen-DPDK from Github on Ubuntu 14.04. Is > this supported? If so, would anybody tell me how to get the build working? > > I have tried to be faithful to the instructions in README.md and I have > tested with both master and the latest release tag (pktgen-2.7.1). > > The compiler output is pasted below and also in this Gist: > https://gist.github.com/lukego/bc8f7ef97ad0110c60e1 > > Any ideas appreciated :). > > CC [M] > /home/luke/github/Pktgen-DPDK.release/dpdk/x86_64-pktgen-linuxapp- > gcc/build/lib/librte_eal/linuxapp/kni/igb_main.o > > /home/luke/github/Pktgen-DPDK.release/dpdk/x86_64-pktgen-linuxapp- > gcc/build/lib/librte_eal/linuxapp/kni/igb_main.c: > In function ?igb_rx_hash?: > > /home/luke/github/Pktgen-DPDK.release/dpdk/x86_64-pktgen-linuxapp- > gcc/build/lib/librte_eal/linuxapp/kni/igb_main.c:7379:3: > error: implicit declaration of function ?skb_set_hash? > [-Werror=implicit-function-declaration] > >skb_set_hash(skb, le32_to_cpu(rx_desc->wb.lower.hi_dword.rss), > >^ > > /home/luke/github/Pktgen-DPDK.release/dpdk/x86_64-pktgen-linuxapp- > gcc/build/lib/librte_eal/linuxapp/kni/igb_main.c:7380:9: > error: ?PKT_HASH_TYPE_L3? undeclared (first use in this function) > > PKT_HASH_TYPE_L3); > > ^ > > /home/luke/github/Pktgen-DPDK.release/dpdk/x86_64-pktgen-linuxapp- > gcc/build/lib/librte_eal/linuxapp/kni/igb_main.c:7380:9: > note: each undeclared identifier is reported only once for each function it > appears in > > cc1: all warnings being treated as errors > > make[10]: *** > [/home/luke/github/Pktgen-DPDK.release/dpdk/x86_64-pktgen-linuxapp- > gcc/build/lib/librte_eal/linuxapp/kni/igb_main.o] > Error 1
[dpdk-dev] [PATCH 1/5] ethdev: Rename macros of packet classification type
2014-07-24 08:14, Zhang, Helin: > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > 2014-07-24 14:42, Helin Zhang: > > > For better understanding, 'PCTYPE' was added to the name of i40e RSS > > > shift macros. > > > > > > Signed-off-by: Helin Zhang > > > > > -#define ETH_RSS_NONF_IPV4_UDP_SHIFT 31 > > > +#define ETH_PCTYPE_NONF_IPV4_UDP 31 > > > > Why is it clearer? I don't understand what means PCTYPE. > > It is 'packet classification type' defined in data sheet, and widely used. Widely used? No it seems to be an i40e naming. Which datasheet are you pointing? > It is not just for RSS only, it can be used for flow director possibly. > That's why I think it would be better to rename it with PCTYPE names. At least, you should add a comment in the code to explain the meaning. Thank you -- Thomas
[dpdk-dev] Pktgen-DPDK compile error on Ubuntu 14.04
Howdy! I am having trouble building Pktgen-DPDK from Github on Ubuntu 14.04. Is this supported? If so, would anybody tell me how to get the build working? I have tried to be faithful to the instructions in README.md and I have tested with both master and the latest release tag (pktgen-2.7.1). The compiler output is pasted below and also in this Gist: https://gist.github.com/lukego/bc8f7ef97ad0110c60e1 Any ideas appreciated :). CC [M] /home/luke/github/Pktgen-DPDK.release/dpdk/x86_64-pktgen-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/igb_main.o /home/luke/github/Pktgen-DPDK.release/dpdk/x86_64-pktgen-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/igb_main.c: In function ?igb_rx_hash?: /home/luke/github/Pktgen-DPDK.release/dpdk/x86_64-pktgen-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/igb_main.c:7379:3: error: implicit declaration of function ?skb_set_hash? [-Werror=implicit-function-declaration] skb_set_hash(skb, le32_to_cpu(rx_desc->wb.lower.hi_dword.rss), ^ /home/luke/github/Pktgen-DPDK.release/dpdk/x86_64-pktgen-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/igb_main.c:7380:9: error: ?PKT_HASH_TYPE_L3? undeclared (first use in this function) PKT_HASH_TYPE_L3); ^ /home/luke/github/Pktgen-DPDK.release/dpdk/x86_64-pktgen-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/igb_main.c:7380:9: note: each undeclared identifier is reported only once for each function it appears in cc1: all warnings being treated as errors make[10]: *** [/home/luke/github/Pktgen-DPDK.release/dpdk/x86_64-pktgen-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/igb_main.o] Error 1
[dpdk-dev] [PATCH 3/5] i40e: support selecting hash functions
2014-07-24 01:01, Matthew Hall: > On Thu, Jul 24, 2014 at 09:59:23AM +0200, Thomas Monjalon wrote: > > Is it really a good idea to configure this kind of thing at build time? > > Maybe yes, I'm not sure. > > Whether it's safe to set at runtime probably depends what happens to the card > if it gets changed. Do you have to reset the card or the port? Or is it OK if > it's more dynamic? No, we can change configuration with rte_eth_dev_configure() before initializing port. So it is truly configurable. Requiring recompilation means it's not really configurable between 2 runs. And it breaks binary packaging for Linux distributions. Many things in DPDK are configured at build time. But we should wonder if it's really a good design. -- Thomas
[dpdk-dev] [PATCH 3/5] i40e: support selecting hash functions
2014-07-24 14:42, Helin Zhang: > Toeplitz and simple XOR hash functions are supported by > hardware, code changes are to tell the hardware which hash > function is selected according to the configuration. > > Signed-off-by: Helin Zhang > +CONFIG_RTE_LIBRTE_I40E_HASH_FUNC_TOEPLITZ=y Is it really a good idea to configure this kind of thing at build time? Maybe yes, I'm not sure. -- Thomas
[dpdk-dev] [PATCH 2/5] ethdev: add new ops of 'check_command_supported' and 'rx_classification_filter_ctl'
2014-07-24 14:42, Helin Zhang: > Two ops of 'check_command_supported' and 'rx_classification_filter_ctl' > are added. > * 'check_command_supported' is for capability discovery. In anothoer > word, it is to check if specific feature/command is supported by > the specific port. This generic service is really needed to add NIC-specific functions. I'd suggest to name it "is_supported". > * 'rx_classification_filter_ctl' is for receive classifcation filter > configuring. e.g. hash function configuration, flow director > configuration. It is a common API where a lot of commands can > be implemented for different sub features. Not sure about this one. You are hiding specific API in an opaque structure. By the way, it should be in another patch. > +/** > + * Check if the command is supported by an Ethernet device. > + * > + * @param port_id > + * The port identifier of the Ethernet device. > + * @param cmd > + * The command. > + * > + * @return > + * - (> 0) The command is supported. > + * - (0) The command is not supported. > + * - (-ENOTSUP) if hardware doesn't support. > + * - (-ENODEV) if is invalid. > + */ > +int rte_eth_dev_check_command_supported(uint8_t port_id, uint32_t cmd); What are the possible commands? You should define enum/constants here. -- Thomas
[dpdk-dev] free a memzone
Hi Bruce, Thank you for the response. That's a great Idea! But I do not understand the last four parameters of this function. (vaddr, paddr, pg_num, pg_shift) I guess vaddr is the virtual address of the previously allocated mempool, paddr is calculated using function call rte_mem_virt2phy(vaddr), am I right? what about pg_num and pg_shift? how can I pass them correctly? Best Regards, Mahdi. On Thu, Jul 24, 2014 at 9:48 AM, Mahdi Dashtbozorgi wrote: > Hi Bruce, > > Thank you for the response. That's a great Idea! > But I do not understand the last four parameters of this function. (vaddr, > paddr, pg_num, pg_shift) > I guess vaddr is the virtual address of the previously allocated mempool, > paddr is calculated using function call rte_mem_virt2phy(vaddr), am I > right? what about pg_num and pg_shift? how can I pass them correctly? > > Best Regards, > Mahdi. > > > On Wed, Jul 23, 2014 at 11:09 PM, Richardson, Bruce < > bruce.richardson at intel.com> wrote: > >> Rather than freeing the previously allocated memzone, could you not just >> re-initialize the mempool using something like rte_mempool_xmem_create? >> >> > -Original Message- >> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mahdi Dashtbozorgi >> > Sent: Wednesday, July 23, 2014 2:05 AM >> > To: dev at dpdk.org >> > Subject: Re: [dpdk-dev] free a memzone >> > >> > Hi guys, >> > >> > Is there any suggestion to free the previously allocated memzone? >> > I really need help in this issue. >> > Any help is appreciated. >> > >> > Best Regards, >> > Mahdi. >> > >> > >> > >> > On Tue, Jul 22, 2014 at 4:03 PM, Mahdi Dashtbozorgi >> > wrote: >> > >> > > Hi, >> > > >> > > I have two processes, which uses DPDK multi-process feature to >> communicate. >> > > Master process captures packets from NIC and put them to a ring >> buffer, >> > > which is shared between master and slave process. >> > > The slave process looks up the shared ring buffer using >> rte_ring_lookup >> > > function and reads the packets. >> > > The slave process needs a memory pool, too. Therefore, it creates a >> > > mempool using rte_mempool_create. But If the slave process crashes >> during >> > > its processing and runs again, rte_mempool_create function fails and >> tells >> > > that there is a memory zone with that name. >> > > If I use rte_mempool_lookup in this case, the memory pool is not a >> clean >> > > memory pool. Because the previous run of slave process did not >> terminate >> > > gracefully and did not return all the objects to the pool. >> > > Is there any function to free an existing memory zone, which I call >> before >> > > rte_mempool_create to ensure that previous memory pool does not exists >> > > anymore? >> > > >> > > Best Regards, >> > > Mahdi. >> > > >> > >
[dpdk-dev] [PATCH 1/5] ethdev: Rename macros of packet classification type
Hi Helin, 2014-07-24 14:42, Helin Zhang: > For better understanding, 'PCTYPE' was added to the name of i40e > RSS shift macros. > > Signed-off-by: Helin Zhang > -#define ETH_RSS_NONF_IPV4_UDP_SHIFT 31 > +#define ETH_PCTYPE_NONF_IPV4_UDP 31 Why is it clearer? I don't understand what means PCTYPE. -- Thomas
[dpdk-dev] Inter-VM communication packet flow
2014-07-24 05:41, Harish Patil: > Gentle second request. No need to do second request few hours after the first one. You probably would have more answers if you better described the context of what you are speaking. If nobody has time to explain how it works, you can still read the code. > >DPDK-dev, > >From the documentation, its not very clear to me how would the inter-VM > >communication packet path (traffic crossing the physical port), especially > >the way macaddr table is populated in each PF port and role of the PF poll > >mode driver in this context. Could you please explain the flow here? > This message and any attached documents contain information from QLogic > Corporation or its wholly-owned subsidiaries that may be confidential. If > you are not the intended recipient, you may not read, copy, distribute, or > use this information. If you have received this transmission in error, > please notify the sender immediately by reply e-mail and then delete this > message. Please remove this footer from your emails. -- Thomas
[dpdk-dev] [PATCH v2] user space vhost driver library
Hello, My understanding is that this is a helper library, but not a PMD driver. Is my understanding correct? If so, do you plan to write a vhost PMD driver? Regards, Franck. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Xie, Huawei > Sent: vendredi 18 juillet 2014 12:03 > To: Xie, Huawei; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2] user space vhost driver library > > Merged two patches in previous patch set into 1. > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Huawei Xie > > Sent: Friday, July 18, 2014 5:56 PM > > To: dev at dpdk.org > > Subject: [dpdk-dev] [PATCH v2] user space vhost driver library > > > > This user space vhost library is based off user space vhost example > > and aims to provide same API for different vhost implementations. This > > implementation includes user space vhost cuse driver, kernel module > > for eventfd proxy and vhost enqueue/dequeue functionalities. > > > > Huawei Xie (1): > > vhost library support to facilitate integration with vswitch. > > > > config/common_linuxapp |7 + > > lib/Makefile |1 + > > lib/librte_vhost/Makefile| 48 ++ > > lib/librte_vhost/eventfd_link/Makefile | 39 + > > lib/librte_vhost/eventfd_link/eventfd_link.c | 205 ++ > > lib/librte_vhost/eventfd_link/eventfd_link.h | 79 ++ > > lib/librte_vhost/rte_virtio_net.h| 192 + > > lib/librte_vhost/vhost-net-cdev.c| 363 ++ > > lib/librte_vhost/vhost-net-cdev.h| 112 +++ > > lib/librte_vhost/vhost_rxtx.c| 292 > > lib/librte_vhost/virtio-net.c| 1002 > ++ > > 11 files changed, 2340 insertions(+) > > create mode 100644 lib/librte_vhost/Makefile create mode 100644 > > lib/librte_vhost/eventfd_link/Makefile > > create mode 100644 lib/librte_vhost/eventfd_link/eventfd_link.c > > create mode 100644 lib/librte_vhost/eventfd_link/eventfd_link.h > > create mode 100644 lib/librte_vhost/rte_virtio_net.h create mode > > 100644 lib/librte_vhost/vhost-net-cdev.c create mode 100644 > > lib/librte_vhost/vhost-net-cdev.h create mode 100644 > > lib/librte_vhost/vhost_rxtx.c create mode 100644 > > lib/librte_vhost/virtio-net.c > > > > -- > > 1.8.1.4 This message and any attachments (the "message") are confidential, intended solely for the addressees. If you are not the intended recipient, please notify the sender immediately by e-mail and delete this message from your system. In this case, you are not authorized to use, copy this message and/or disclose the content to any other person. E-mails are susceptible to alteration. Neither Qosmos nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. Ce message et toutes ses pi?ces jointes (ci-apr?s le "message")sont confidentiels et ?tablis ? l'intention exclusive de ses destinataires. Si vous avez re?u ce message par erreur, merci d?en informer imm?diatement son ?metteur par courrier ?lectronique et d?effacer ce message de votre syst?me. Dans cette hypoth?se, vous n??tes pas autoris? ? utiliser, copier ce message et/ou en divulguer le contenu ? un tiers. Tout message ?lectronique est susceptible d'alt?ration. Qosmos et ses filiales d?clinent toute responsabilit? au titre de ce message s'il a ?t? alt?r?, d?form? ou falsifi?.
[dpdk-dev] [PATCH] igb_uio: fall back to enable/disable irq mode
24.07.2014 0:09, Stephen Hemminger ?: >> Rewritten IRQ mode handling code introduced in commit 399a3f0d >> (igb_uio: fix IRQ mode handling) renders some faulty NICs (VMware >> e1000, for example) unusable if INTX mode is not supported. >> >> This patch gets these NICs up and running, but throwing a kernel >> warning. >> >> Signed-off-by: Yerden Zhumabekov > That is because the VMWare PCI INTX is broken. > The masking logic doesn't work. > > Rather than applying this patch a deeper fix in E1000 and DPDK handling > of link state is needed. Better to just make the E1000 able > to function without IRQ for Link state than just pretend masking works I'll dig deeper then, maybe I'll figure out something. If IRQ doesn't hook anything then, I guess, NIC should be continuously checked for link state. If so, where should I put my efforts? PMD? -- Sincerely, Yerden Zhumabekov STS, ACI Astana, KZ
[dpdk-dev] [PATCH 3/5] i40e: support selecting hash functions
> -Original Message- > From: Matthew Hall [mailto:mhall at mhcomputing.net] > Sent: Thursday, July 24, 2014 4:15 PM > To: Thomas Monjalon; Zhang, Helin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH 3/5] i40e: support selecting hash functions > > If no reboot of the card is needed then it's probably better to add it to one > of > the ethtool style APIs... > -- > Sent from my mobile device. > > On July 24, 2014 1:07:37 AM PDT, Thomas Monjalon > wrote: > >2014-07-24 01:01, Matthew Hall: > >> On Thu, Jul 24, 2014 at 09:59:23AM +0200, Thomas Monjalon wrote: > >> > Is it really a good idea to configure this kind of thing at build > >time? > >> > Maybe yes, I'm not sure. > >> > >> Whether it's safe to set at runtime probably depends what happens to > >the card > >> if it gets changed. Do you have to reset the card or the port? Or is > >it OK if > >> it's more dynamic? > > > >No, we can change configuration with rte_eth_dev_configure() before > >initializing port. So it is truly configurable. > >Requiring recompilation means it's not really configurable between 2 > >runs. > >And it breaks binary packaging for Linux distributions. > > > >Many things in DPDK are configured at build time. But we should wonder > >if it's really a good design. Hi Thomas, Matt Good points! Thank you guys! Regards, Helin
[dpdk-dev] [PATCH 2/5] ethdev: add new ops of 'check_command_supported' and 'rx_classification_filter_ctl'
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Thursday, July 24, 2014 3:57 PM > To: Zhang, Helin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH 2/5] ethdev: add new ops of > 'check_command_supported' and 'rx_classification_filter_ctl' > > 2014-07-24 14:42, Helin Zhang: > > Two ops of 'check_command_supported' and 'rx_classification_filter_ctl' > > are added. > > * 'check_command_supported' is for capability discovery. In anothoer > > word, it is to check if specific feature/command is supported by > > the specific port. > > This generic service is really needed to add NIC-specific functions. > I'd suggest to name it "is_supported". > I tried to name it as the same style of rte_cpu_check_supported(). As you indicated, 'is_commmand_supported' might be a better name. > > * 'rx_classification_filter_ctl' is for receive classifcation filter > > configuring. e.g. hash function configuration, flow director > > configuration. It is a common API where a lot of commands can > > be implemented for different sub features. > > Not sure about this one. You are hiding specific API in an opaque structure. > By the way, it should be in another patch. > We want to implement several common API for NIC specific features, to avoid creating quite a lot of ops in 'struct eth_dev_ops'. The idea came from ioctl. > > +/** > > + * Check if the command is supported by an Ethernet device. > > + * > > + * @param port_id > > + * The port identifier of the Ethernet device. > > + * @param cmd > > + * The command. > > + * > > + * @return > > + * - (> 0) The command is supported. > > + * - (0) The command is not supported. > > + * - (-ENOTSUP) if hardware doesn't support. > > + * - (-ENODEV) if is invalid. > > + */ > > +int rte_eth_dev_check_command_supported(uint8_t port_id, uint32_t > cmd); > > What are the possible commands? > You should define enum/constants here. > The idea came from ioctl(). Enum could be a choice. The commands was defined in rte_eth_features.h. Comments should be added here for telling that. > -- > Thomas
[dpdk-dev] [PATCH] kni: fixed compilation error on Ubuntu 14.04 LTS (kernel 3.13.0-30.54)
* Thomas Monjalon (thomas.monjalon at 6wind.com) wrote: > 2014-07-24 08:20, Chris Wright: > > * Pablo de Lara (pablo.de.lara.guarch at intel.com) wrote: > > > Signed-off-by: Patrice Buriez > > > > Just a mechanical nitpick on DCO. Pablo, this patch appears to be > > written by Patrice. If so, it should begin with "From: Patrice Buriez > > " and should include your own Signed-off-by. > > I agree that the author name (From:) should be fixed. > But I'm not sure we should follow Linux guidelines for Signed-off-by > when patch is simply forwarded. Does it mean more than "I am authorized to > send it" ? Yeah, that's right. Basically showing the chain of people who touched the patch on the way to the repo. thanks, -chris
[dpdk-dev] [PATCH 1/5] ethdev: Rename macros of packet classification type
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Thursday, July 24, 2014 4:20 PM > To: Zhang, Helin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH 1/5] ethdev: Rename macros of packet > classification type > > 2014-07-24 08:14, Zhang, Helin: > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > 2014-07-24 14:42, Helin Zhang: > > > > For better understanding, 'PCTYPE' was added to the name of i40e > > > > RSS shift macros. > > > > > > > > Signed-off-by: Helin Zhang > > > > > > > -#define ETH_RSS_NONF_IPV4_UDP_SHIFT 31 > > > > +#define ETH_PCTYPE_NONF_IPV4_UDP 31 > > > > > > Why is it clearer? I don't understand what means PCTYPE. > > > > It is 'packet classification type' defined in data sheet, and widely used. > > Widely used? No it seems to be an i40e naming. > Which datasheet are you pointing? Sorry, it is widely used in i40e. That might not so widely for the whole DPDK. The datasheet I mentioned is the Intel(r) 40G NIC datasheet. > > > It is not just for RSS only, it can be used for flow director possibly. > > That's why I think it would be better to rename it with PCTYPE names. > > At least, you should add a comment in the code to explain the meaning. OK, good comments! > > Thank you > -- > Thomas
[dpdk-dev] [PATCH] kni: fixed compilation error on Ubuntu 14.04 LTS (kernel 3.13.0-30.54)
* Pablo de Lara (pablo.de.lara.guarch at intel.com) wrote:
> Signed-off-by: Patrice Buriez
Just a mechanical nitpick on DCO. Pablo, this patch appears to be
written by Patrice. If so, it should begin with "From: Patrice Buriez
" and should include your own Signed-off-by.
thanks,
-chris
> ---
> lib/librte_eal/linuxapp/kni/Makefile |9 +
> lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h | 16
> 2 files changed, 25 insertions(+), 0 deletions(-)
>
> diff --git a/lib/librte_eal/linuxapp/kni/Makefile
> b/lib/librte_eal/linuxapp/kni/Makefile
> index fb9462f..725d3e7 100644
> --- a/lib/librte_eal/linuxapp/kni/Makefile
> +++ b/lib/librte_eal/linuxapp/kni/Makefile
> @@ -44,6 +44,15 @@ MODULE_CFLAGS += -I$(RTE_OUTPUT)/include
> -I$(SRCDIR)/ethtool/ixgbe -I$(SRCDIR)/e
> MODULE_CFLAGS += -include $(RTE_OUTPUT)/include/rte_config.h
> MODULE_CFLAGS += -Wall -Werror
>
> +ifeq ($(shell type lsb_release >/dev/null 2>&1 && lsb_release -si),Ubuntu)
> +MODULE_CFLAGS += -DUBUNTU_RELEASE_CODE=$(subst .,,$(shell lsb_release -sr))
> +UBUNTU_KERNEL_CODE := $(shell cut -d' ' -f2 /proc/version_signature |cut -d-
> -f1,2)
> +UBUNTU_KERNEL_CODE := $(subst -,$(comma),$(UBUNTU_KERNEL_CODE))
> +UBUNTU_KERNEL_CODE := $(subst .,$(comma),$(UBUNTU_KERNEL_CODE))
> +MODULE_CFLAGS +=
> -D"UBUNTU_KERNEL_CODE=UBUNTU_KERNEL_VERSION($(UBUNTU_KERNEL_CODE))"
> +endif
> +
> +
> # this lib needs main eal
> DEPDIRS-y += lib/librte_eal/linuxapp/eal
>
> diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
> b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
> index 521a35d..5a06383 100644
> --- a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
> +++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
> @@ -713,6 +713,20 @@ struct _kc_ethtool_pauseparam {
> #define SLE_VERSION_CODE 0
> #endif /* SLE_VERSION_CODE */
>
> +/* Ubuntu release and kernel codes must be specified from Makefile */
> +#ifndef UBUNTU_RELEASE_VERSION
> +#define UBUNTU_RELEASE_VERSION(a,b) (((a) * 100) + (b))
> +#endif
> +#ifndef UBUNTU_KERNEL_VERSION
> +#define UBUNTU_KERNEL_VERSION(a,b,c,abi,upload) (((a) << 40) + ((b) << 32) +
> ((c) << 24) + ((abi) << 8) + (upload))
> +#endif
> +#ifndef UBUNTU_RELEASE_CODE
> +#define UBUNTU_RELEASE_CODE 0
> +#endif
> +#ifndef UBUNTU_KERNEL_CODE
> +#define UBUNTU_KERNEL_CODE 0
> +#endif
> +
> #ifdef __KLOCWORK__
> #ifdef ARRAY_SIZE
> #undef ARRAY_SIZE
> @@ -3847,6 +3861,7 @@ static inline struct sk_buff
> *__kc__vlan_hwaccel_put_tag(struct sk_buff *skb,
>
> #if ( LINUX_VERSION_CODE < KERNEL_VERSION(3,14,0) )
> #if (!(RHEL_RELEASE_CODE && RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(7,0)))
> +#if (!(UBUNTU_RELEASE_CODE == UBUNTU_RELEASE_VERSION(14,4) &&
> UBUNTU_KERNEL_CODE >= UBUNTU_KERNEL_VERSION(3,13,0,30,54)))
> #ifdef NETIF_F_RXHASH
> #define PKT_HASH_TYPE_L3 0
> static inline void
> @@ -3855,6 +3870,7 @@ skb_set_hash(struct sk_buff *skb, __u32 hash,
> __always_unused int type)
> skb->rxhash = hash;
> }
> #endif /* NETIF_F_RXHASH */
> +#endif /* < 3.13.0-30.54 (Ubuntu 14.04) */
> #endif /* < RHEL7 */
> #endif /* < 3.14.0 */
>
> --
> 1.7.0.7
>
[dpdk-dev] [PATCH 1/5] ethdev: Rename macros of packet classification type
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Thursday, July 24, 2014 3:48 PM > To: Zhang, Helin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH 1/5] ethdev: Rename macros of packet > classification type > > Hi Helin, > > 2014-07-24 14:42, Helin Zhang: > > For better understanding, 'PCTYPE' was added to the name of i40e RSS > > shift macros. > > > > Signed-off-by: Helin Zhang > > > -#define ETH_RSS_NONF_IPV4_UDP_SHIFT 31 > > +#define ETH_PCTYPE_NONF_IPV4_UDP 31 > > Why is it clearer? I don't understand what means PCTYPE. > > -- > Thomas Hi Thomas It is 'packet classification type' defined in data sheet, and widely used. It is not just for RSS only, it can be used for flow director possibly. That's why I think it would be better to rename it with PCTYPE names. Thank you! Regards, Helin
[dpdk-dev] [PATCH] igb_uio: fall back to enable/disable irq mode
On Thu, 24 Jul 2014 09:11:36 +0600 Yerden Zhumabekov wrote: > 24.07.2014 0:09, Stephen Hemminger ?: > >> Rewritten IRQ mode handling code introduced in commit 399a3f0d > >> (igb_uio: fix IRQ mode handling) renders some faulty NICs (VMware > >> e1000, for example) unusable if INTX mode is not supported. > >> > >> This patch gets these NICs up and running, but throwing a kernel > >> warning. > >> > >> Signed-off-by: Yerden Zhumabekov > > That is because the VMWare PCI INTX is broken. > > The masking logic doesn't work. > > > > Rather than applying this patch a deeper fix in E1000 and DPDK handling > > of link state is needed. Better to just make the E1000 able > > to function without IRQ for Link state than just pretend masking works > > I'll dig deeper then, maybe I'll figure out something. > If IRQ doesn't hook anything then, I guess, NIC should be continuously > checked for link state. If so, where should I put my efforts? PMD? > I think what would be the best fix is: 1. In igb_uio, if INTX test fails then setup with interrupts. This can be done by setting the irq # to 0. UIO in kernel will then setup device without any IRQ support 2. In DPDK, change PCI code to handle case of UIO without interrupts, and set flag in the device structure. 3. In an accessor function in rte_ethdev layer add new function rte_eth_dev_has_link_intr() which checks for RTE_PCI_DRV_INTR_LSC flag and that interrupt setup was successful. 4. Application only configures dev_conf->intr_conf.lsc iff device supports it (see check #3)
[dpdk-dev] Inter-VM communication packet flow
Gentle second request. >DPDK-dev, >From the documentation, its not very clear to me how would the inter-VM >communication packet path (traffic crossing the physical port), especially >the way macaddr table is populated in each PF port and role of the PF poll >mode driver in this context. Could you please explain the flow here? > >Thanks, >Harish > > > > This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
[dpdk-dev] [PATCH 3/5] i40e: support selecting hash functions
If no reboot of the card is needed then it's probably better to add it to one of the ethtool style APIs... -- Sent from my mobile device. On July 24, 2014 1:07:37 AM PDT, Thomas Monjalon wrote: >2014-07-24 01:01, Matthew Hall: >> On Thu, Jul 24, 2014 at 09:59:23AM +0200, Thomas Monjalon wrote: >> > Is it really a good idea to configure this kind of thing at build >time? >> > Maybe yes, I'm not sure. >> >> Whether it's safe to set at runtime probably depends what happens to >the card >> if it gets changed. Do you have to reset the card or the port? Or is >it OK if >> it's more dynamic? > >No, we can change configuration with rte_eth_dev_configure() before >initializing port. So it is truly configurable. >Requiring recompilation means it's not really configurable between 2 >runs. >And it breaks binary packaging for Linux distributions. > >Many things in DPDK are configured at build time. But we should wonder >if >it's really a good design.
[dpdk-dev] [PATCH 3/5] i40e: support selecting hash functions
On Thu, Jul 24, 2014 at 09:59:23AM +0200, Thomas Monjalon wrote: > Is it really a good idea to configure this kind of thing at build time? > Maybe yes, I'm not sure. Whether it's safe to set at runtime probably depends what happens to the card if it gets changed. Do you have to reset the card or the port? Or is it OK if it's more dynamic? Matthew.
[dpdk-dev] symbol conflicts between netinet/in.h, arpa/inet.h, and rte_ip.h
Hello,
I ran into some weird symbol conflicts between system netinet/in.h and DPDK
rte_ip.h. They have a lot of duplicated definitions for stuff like IPPROTO_IP
and so on. This breaks when you want to use inet_pton from arpa/inet.h,
because it includes netinet/in.h to define struct in_addr.
Thus with all the conflicts it's impossible to use a DPDK IP struct instead of
all the system's sockaddr stuff, to store a value from the system copy of
inet_pton. This would be a common operation if, for example, you want to
configure all the IP addresses on your box from a JSON file, which is what I
was doing.
The DPDK kludged around it internally by using a file called
cmdline_parse_ipaddr.c with private copies of these functions. But it in my
opinion very unwisely marked all of the functions as static except for
cmdline_parse_ipaddr, which only works on the DPDK's proprietary argument
handling, and not with anything the user might have which is a different
format.
So, it would be a big help for users if the macros in librte_net files would
check if the symbols already existed, or if they had subheader files available
to grab only non conflicting symbols, or if they would make a proper .h and
factor all the inet_pton and inet_ntop inside the cmdline lib into a place
where users can access them. It would also be a help if they had a less ugly
equivalent to struct sockaddr, which let you work with IP addresses a bit more
easily, such as something like this:
struct ip4_addr {
uint32_t addr;
};
typedef struct ip4_addr ip4_addr;
struct ip6_addr {
uint8_t addr[16];
};
typedef struct ip6_addr ip6_addr;
struct ip_addr {
uint8_t family;
uint8_t prefix;
union {
struct ip4_addr ipv4;
struct ip6_addr ipv6;
};
};
I had to create a bunch of duplicate code to handle it in my project, since
the DPDK marked its copies of all these functions as "secret" and didn't make
a .h for them. If any of it is useful I am happy to donate it, although I
don't think I've got quite enough experience with this specifc part of the
DPDK to code it up all by myself.
Thanks,
Matthew.
