[dpdk-dev] [PATCH] eal/linux: fix rte_epoll_wait
Hi,
> -Original Message-
> From: Robert Sanford [mailto:rsanford2 at gmail.com]
> Sent: Tuesday, August 18, 2015 11:54 PM
> To: Liang, Cunming; dev at dpdk.org
> Subject: [PATCH] eal/linux: fix rte_epoll_wait
>
> Function rte_epoll_wait should return when underlying call
> to epoll_wait times out.
>
> Signed-off-by: Robert Sanford
> ---
> lib/librte_eal/linuxapp/eal/eal_interrupts.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
> b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
> index 3f87875..25cae6a 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
> @@ -1012,6 +1012,9 @@ rte_epoll_wait(int epfd, struct rte_epoll_event *events,
> strerror(errno));
> rc = -1;
> break;
> + } else {
> + /* rc == 0, epoll_wait timed out */
> + break;
> }
> }
>
> --
> 1.7.1
Acked-by: Cunming Liang
[dpdk-dev] [PATCH v2] Change rte_eal_vdev_init to update port_id
On 2015/08/21 4:16, Ravi Kerur wrote: > > > /** > > * Uninitalize a driver specified by name. > > @@ -125,6 +127,38 @@ int rte_eal_vdev_init(const char *name, > const char *args); > > */ > > int rte_eal_vdev_uninit(const char *name); > > > > +/** > > + * Given name, return port_id associated with the device. > > + * > > + * @param name > > + * Name associated with device. > > + * @param port_id > > + * The port identifier of the device. > > + * > > + * @return > > + * - 0: Success. > > + * - -EINVAL: NULL string (name) > > + * - -ENODEV failure > > Please define above in 'rte_ethdev.h.' > > > Hi Tetsuya, > > I would like to take a step back and explain why function declarations > are in rte_dev.h and not in rte_ethdev.h > > Approach 1: > Initially I thought of modifying driver init routine to return/update > port_id as the init routine is the place port_id gets allocated and it > would have been clean approach. However, it required changes to all > PMD_VDEV driver init routine to modify function signature for the > changes which I thought may be an overkill. > > Approach 2: > Instead I chose to define 2 functions in librte_ether/rte_ethdev.c and > make use of it. In this approach new functions are invoked from > librte_eal/common/.c to get port_id. If I had new function > declarations in rte_ethdev.h and included that file in > librte_eal/common/.c files it creates circular dependancy and > compilation fails, hence I took hybrid approach of definitions in > librte_ether and declarations in librte_eal. > > Please let me know if there is a better approach to take care of your > comments. As it stands declarations cannot be moved to rte_ethdev.h > for compilation reasons. > > Thanks, > Ravi > Hi Ravi, (Adding David) I appreciate your description. I understand why you define the functions in rte_dev.h. About Approach2, I don't know a way to implement cleanly. I guess if we define the functions in rte_dev.h, the developers who want to use the functions will be confused because the functions are implemented in ethdev.c, but it is needed to include rte_dev.h. To avoid such a confusion, following implementation might be worked, but I am not sure this cording style is allowed in eal library. Define the functions in rte_ethdev.h, then fix librte_eal/common/.c files like below ex) lib/librte_eal/common/eal_common_dev.c +#include #include #include #include #include "eal_private.h" +extern int rte_eth_dev_get_port_by_name(const char *name, uint8_t *port_id); +extern int rte_eth_dev_get_port_by_addr(const struct rte_pci_addr *addr, uint8_t *port_id); In this case, the developer might be able to notice that above usage in eal library is some kind of exception. But I guess the DPDK code won't be clean if we start having a exception. So it might be good to choose Approach1, because apparently it is straight forward. Anyone won't be confused and complained about coding style. Hi David, Could you please let us know what you think? Do you have a good approach for this? Thanks, Tetsuya
[dpdk-dev] DPDK 2.1.0 build error: inlining failed in call to always_inline
On Thu, Aug 20, 2015 at 05:35:10PM +, Keith E. Fleming wrote: > make config T=x86_64-native-linuxapp-gccsed -ri 's,(PMD_PCAP=).*,\1y,' > build/.configmake > [root at neutron dpdk-2.1.0]# make 2>&1 | more > == Build lib > == Build lib/librte_compat > == Build lib/librte_eal > == Build lib/librte_eal/common > == Build lib/librte_eal/linuxapp > == Build lib/librte_eal/linuxapp/igb_uio > (cat /dev/null;?? echo > kernel//root/dpdk-2.1.0/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.ko;) > > /root/dpdk-2.1.0/build/build > /lib/librte_eal/linuxapp/igb_uio/modules.order > ? Building modules, stage 2. > ? MODPOST 1 modules > == Build lib/librte_eal/linuxapp/eal > ? CC eal_common_options.o > In file included from > /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/x86intrin.h:37:0, > from /root/dpdk-2.1.0/build/include/rte_vect.h:67, > from /root/dpdk-2.1.0/build/include/rte_memcpy.h:46, > from > /root/dpdk-2.1.0/lib/librte_eal/common/eal_common_options.c:48: > /root/dpdk-2.1.0/build/include/rte_memcpy.h: In function ?rte_memcpy?: > /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/tmmintrin.h:185:1: error: > inlining failed in call to always_inline ?_mm_alignr_epi8?: t > arget specific option mismatch > ?_mm_alignr_epi8(__m128i __X, __m128i __Y, const int __N) > ?^ > In file included from > /root/dpdk-2.1.0/lib/librte_eal/common/eal_common_options.c:48:0: > /root/dpdk-2.1.0/build/include/rte_memcpy.h:425:9: error: called from here > > I can't even guess at what the problem is here. It's a total trainwreck. I > assume this has compiled successfully for someone somewhere? Thanks What OS platform is this on - from the gcc path, it looks like gcc 4.9 on Redhat 7? Is that correct? /Bruce
[dpdk-dev] [PATCH 1/4] cryptodev: Initial DPDK Crypto APIs and device framework release
On 20/08/15 20:07, Neil Horman wrote: > On Thu, Aug 20, 2015 at 03:07:20PM +0100, Declan Doherty wrote: >> Co-authored-by: Des O Dea >> Co-authored-by: John Griffin >> Co-authored-by: Fiona Trahe >> >> This patch contains the initial proposed APIs and device framework for >> integrating crypto packet processing into DPDK. >> >> features include: >> - Crypto device configuration / management APIs >> - Definitions of supported cipher algorithms and operations. >> - Definitions of supported hash/authentication algorithms and >> operations. >> - Crypto session management APIs >> - Crypto operation data structures and APIs allocation of crypto >> operation structure used to specify the crypto operations to >> be performed on a particular mbuf. >> - Extension of mbuf to contain crypto operation data pointer and >> extra flags. >> - Burst enqueue / dequeue APIs for processing of crypto operations. >> >> Signed-off-by: Declan Doherty > > Hey, only had a qick read so some of this might be off base, but a few > comments > in line > Hey Neil, thanks for the feedback, I've reply in line below. >> > > So, this seems a bit...not sure what the word is..specific perhaps? For an > API. > That is to say, if a underlying device supports performing multiple operations > in a single transaction, I'm not sure that should be exposed in this way. As > the number of devices and chain combinations grow, so too will this list, and > if > there are multiple simmilar (but distinct) chain operations, an application > will > have to know which chains are applicable to which devices which is sub-optimal > > Instead, perhaps it would be better to simply ennumerate the list of crypto > primitives that a device supports (HASH/CIPHER/etc), and allow the application > to define the desired chain when creating a session. That is to say, an > appilcation can create a session that requests a given chain of operations > (using an array of the primitive enum perhaps). The implementing PMD is then > responsible for implementing that chain in hardware or software if need be. > If > you need to report on the disposition of the implementation, you can do so via > return code (i.e. SESSION_OK_HW_IMPL or SESSION_OK_SW_IMPL). > > Using this method, more complex operations can be implemented with chain > macros > (e.g. AEAD is just an array of primitives [CIPHER, HASH]) > ok, we may have let the hardware which we have available to us bias the scope of the API a little. I guess something similar to the approach taken by the OCF in BSD may be appropriate. This has a more generic structure for specifying any type of crypto operations and a next pointer to the next operations in the chain, this would make the provisioning of operations and there chaining much more generic? I'll put together a prototype and come back to the mailing list with it for further comment. >> > These are all defined in rte_ethdev. You should just move those to a public > place rather then re-creating them > Will do. >> > Shouldn't there be some interlock here if a device is being removed to block > on > closure of all the sessions that may be open against it, and serializtion > againsnt any list modifications for tracking of these devices? > Good point, I hadn't considered the releasing of session resources on device closure. I'll also look further at the device management, at this point we just had the minimal infrastructure in place to allow functional testing. >> > So, I'm a bit confused here. How do you communicate with a cryptodev. I see > you're creating queue pairs here, which I think are intended for input/output, > but you also allow the creation of sessions. The former seems to have no > linkage to the latter, so you have sessionless queue pairs and sessions > without > method to perform operations on? I'm clearly missing something, but I can't > see > the relationship. > All data path communication with the cryptodev is done via the burst enqueue and dequeue functions, see the rte_cryptodev.h . So the session structure is a container for all the immutable data used to perform a crypto operation on a particular packet flow. We have a crypto operation data struct which contains the mutable data such as data offsets and lengths, initialization vectorsand the location of the digest, and additional data etc. The crypto operation can be session based or session-less. If session based, it will have a pointer to a valid session for use with a specific cryptodev otherwise all the immutable crypto operation data parameters need to be set in the crypto operation data struct which is attached to each mbuf which will be enqueued with the cryptodev for processing. Once the crypto operation data struct is completed, it is attached to the specific mbuf which contains the data to be operated on. The cryptodev can then handle a burst of mbuf's for processing enqueued on it using the burst_enqueue functi
[dpdk-dev] DPDK 2.1.0 build error: inlining failed in call to always_inline
Hi Bruce, It is Fedora 21 [root at neutron dpdk-2.1.0]# cat /proc/cpuinfo | more processor??? : 0 vendor_id??? : AuthenticAMD cpu family??? : 16 model??? ??? : 10 model name??? : AMD Phenom(tm) II X6 1055T Processor stepping??? : 0 microcode??? : 0x1dc cpu MHz??? ??? : 800.000 cache size??? : 512 KB physical id??? : 0 siblings??? : 6 core id??? ??? : 0 cpu cores??? : 6 apicid??? ??? : 0 initial apicid??? : 0 fpu??? ??? : yes fpu_exception??? : yes cpuid level??? : 6 wp??? ??? : yes flags??? ??? : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxe xt fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lah f_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate npt lbrv svm_lock nrip_sa ve pausefilter vmmcall [root at neutron dpdk-2.1.0]# uname -a Linux neutron 4.1.5-100.fc21.x86_64 #1 SMP Tue Aug 11 00:24:23 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux [root at neutron dpdk-2.1.0]# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.9.2-20150212/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.9.2-20150212/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC) Let me know if there's anything else you need. Thanks! On Friday, August 21, 2015 6:54 AM, Bruce Richardson wrote: On Thu, Aug 20, 2015 at 05:35:10PM +, Keith E. Fleming wrote: > make config T=x86_64-native-linuxapp-gccsed -ri 's,(PMD_PCAP=).*,\1y,' > build/.configmake > [root at neutron dpdk-2.1.0]# make 2>&1 | more > == Build lib > == Build lib/librte_compat > == Build lib/librte_eal > == Build lib/librte_eal/common > == Build lib/librte_eal/linuxapp > == Build lib/librte_eal/linuxapp/igb_uio > (cat /dev/null;?? echo > kernel//root/dpdk-2.1.0/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.ko;) > > /root/dpdk-2.1.0/build/build > /lib/librte_eal/linuxapp/igb_uio/modules.order > ? Building modules, stage 2. > ? MODPOST 1 modules > == Build lib/librte_eal/linuxapp/eal > ? CC eal_common_options.o > In file included from > /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/x86intrin.h:37:0, > from /root/dpdk-2.1.0/build/include/rte_vect.h:67, > from /root/dpdk-2.1.0/build/include/rte_memcpy.h:46, > from > /root/dpdk-2.1.0/lib/librte_eal/common/eal_common_options.c:48: > /root/dpdk-2.1.0/build/include/rte_memcpy.h: In function ?rte_memcpy?: > /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/tmmintrin.h:185:1: error: > inlining failed in call to always_inline ?_mm_alignr_epi8?: t > arget specific option mismatch > ?_mm_alignr_epi8(__m128i __X, __m128i __Y, const int __N) > ?^ > In file included from > /root/dpdk-2.1.0/lib/librte_eal/common/eal_common_options.c:48:0: > /root/dpdk-2.1.0/build/include/rte_memcpy.h:425:9: error: called from here > > I can't even guess at what the problem is here. It's a total trainwreck. I > assume this has compiled successfully for someone somewhere? Thanks What OS platform is this on - from the gcc path, it looks like gcc 4.9 on Redhat 7? Is that correct? /Bruce
[dpdk-dev] OVS-DPDK performance problem on ixgbe vector PMD
Hi, I've set up a simple packet forwarding perf test on a dual-port 10G 82599ES: one port receives 64 byte UDP packets, the other sends it out, one core used. I've used latest OVS with DPDK 2.1, and the first result was only 13.2 Mpps, which was a bit far from the 13.9 I've seen last year with the same test. The first thing I've changed was to revert back to the old behaviour about this issue: http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/22731 So instead of the new default I've passed 2048 + RTE_PKTMBUF_HEADROOM. That increased the performance to 13.5, but to figure out what's wrong started to play with the receive functions. First I've disabled vector PMD, but ixgbe_recv_pkts_bulk_alloc() was even worse, only 12.5 Mpps. So then I've enabled scattered RX, and with ixgbe_recv_pkts_lro_bulk_alloc() I could manage to get 13.98 Mpps, which is I guess as close as possible to the 14.2 line rate (on my HW at least, with one core) Does anyone has a good explanation about why the vector PMD performs so significantly worse? I would expect that on a 3.2 GHz i5-4570 one core should be able to reach ~14 Mpps, SG and vector PMD shouldn't make a difference. I've tried to look into it with oprofile, but the results were quite strange: 35% of the samples were from miniflow_extract, the part where parse_vlan calls data_pull to jump after the MAC addresses. The oprofile snippet (1M samples): 511454 190.0037 flow.c:511 511458 149 0.0292 dp-packet.h:266 51145f 4264 0.8357 dp-packet.h:267 511466 180.0035 dp-packet.h:268 51146d 430.0084 dp-packet.h:269 511474 172 0.0337 flow.c:511 51147a 4320 0.8467 string3.h:51 51147e 358763 70.3176 flow.c:99 511482 23.9e-04 string3.h:51 511485 3060 0.5998 string3.h:51 511488 1693 0.3318 string3.h:51 51148c 2933 0.5749 flow.c:326 511491 470.0092 flow.c:326 And the corresponding disassembled code: 511454: 49 83 f9 0d cmpr9,0xd 511458: c6 83 81 00 00 00 00movBYTE PTR [rbx+0x81],0x0 51145f: 66 89 83 82 00 00 00movWORD PTR [rbx+0x82],ax 511466: 66 89 93 84 00 00 00movWORD PTR [rbx+0x84],dx 51146d: 66 89 8b 86 00 00 00movWORD PTR [rbx+0x86],cx 511474: 0f 86 af 01 00 00 jbe511629 51147a: 48 8b 45 00 movrax,QWORD PTR [rbp+0x0] 51147e: 4c 8d 5d 0c lear11,[rbp+0xc] 511482: 49 89 00movQWORD PTR [r8],rax 511485: 8b 45 08moveax,DWORD PTR [rbp+0x8] 511488: 41 89 40 08 movDWORD PTR [r8+0x8],eax 51148c: 44 0f b7 55 0c movzx r10d,WORD PTR [rbp+0xc] 511491: 66 41 81 fa 81 00 cmpr10w,0x81 My only explanation to this so far is that I misunderstand something about the oprofile results. Regards, Zoltan
[dpdk-dev] OVS-DPDK performance problem on ixgbe vector PMD
Use perf top it gives much better data than oprofile On Fri, Aug 21, 2015 at 11:05 AM, Zoltan Kiss wrote: > Hi, > > I've set up a simple packet forwarding perf test on a dual-port 10G > 82599ES: one port receives 64 byte UDP packets, the other sends it out, one > core used. I've used latest OVS with DPDK 2.1, and the first result was > only 13.2 Mpps, which was a bit far from the 13.9 I've seen last year with > the same test. The first thing I've changed was to revert back to the old > behaviour about this issue: > > http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/22731 > > So instead of the new default I've passed 2048 + RTE_PKTMBUF_HEADROOM. > That increased the performance to 13.5, but to figure out what's wrong > started to play with the receive functions. First I've disabled vector PMD, > but ixgbe_recv_pkts_bulk_alloc() was even worse, only 12.5 Mpps. So then > I've enabled scattered RX, and with ixgbe_recv_pkts_lro_bulk_alloc() I > could manage to get 13.98 Mpps, which is I guess as close as possible to > the 14.2 line rate (on my HW at least, with one core) > Does anyone has a good explanation about why the vector PMD performs so > significantly worse? I would expect that on a 3.2 GHz i5-4570 one core > should be able to reach ~14 Mpps, SG and vector PMD shouldn't make a > difference. > I've tried to look into it with oprofile, but the results were quite > strange: 35% of the samples were from miniflow_extract, the part where > parse_vlan calls data_pull to jump after the MAC addresses. The oprofile > snippet (1M samples): > > 511454 190.0037 flow.c:511 > 511458 149 0.0292 dp-packet.h:266 > 51145f 4264 0.8357 dp-packet.h:267 > 511466 180.0035 dp-packet.h:268 > 51146d 430.0084 dp-packet.h:269 > 511474 172 0.0337 flow.c:511 > 51147a 4320 0.8467 string3.h:51 > 51147e 358763 70.3176 flow.c:99 > 511482 23.9e-04 string3.h:51 > 511485 3060 0.5998 string3.h:51 > 511488 1693 0.3318 string3.h:51 > 51148c 2933 0.5749 flow.c:326 > 511491 470.0092 flow.c:326 > > And the corresponding disassembled code: > > 511454: 49 83 f9 0d cmpr9,0xd > 511458: c6 83 81 00 00 00 00movBYTE PTR [rbx+0x81],0x0 > 51145f: 66 89 83 82 00 00 00movWORD PTR [rbx+0x82],ax > 511466: 66 89 93 84 00 00 00movWORD PTR [rbx+0x84],dx > 51146d: 66 89 8b 86 00 00 00movWORD PTR [rbx+0x86],cx > 511474: 0f 86 af 01 00 00 jbe511629 > > 51147a: 48 8b 45 00 movrax,QWORD PTR [rbp+0x0] > 51147e: 4c 8d 5d 0c lear11,[rbp+0xc] > 511482: 49 89 00movQWORD PTR [r8],rax > 511485: 8b 45 08moveax,DWORD PTR [rbp+0x8] > 511488: 41 89 40 08 movDWORD PTR [r8+0x8],eax > 51148c: 44 0f b7 55 0c movzx r10d,WORD PTR [rbp+0xc] > 511491: 66 41 81 fa 81 00 cmpr10w,0x81 > > My only explanation to this so far is that I misunderstand something about > the oprofile results. > > Regards, > > Zoltan >
[dpdk-dev] working example commands for ethertype/flow_director_filter ?
Hello: If anybody has any working example commands for ethertype or flow_director_filter, can you please send it across.. I am using the testpmd app, and it is constantly reporting "bad-arguments" even for the legal commands in the doc!!! Thanks -Navneet
