[dpdk-dev] performance issue with ovs + dpdk2.0 with vhost
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ravi Rao > Sent: Friday, May 15, 2015 5:12 PM > To: therbert at redhat.com; dev at dpdk.org > Subject: Re: [dpdk-dev] performance issue with ovs + dpdk2.0 with vhost > > Hi, > This is what I am trying to Do. > Below is the setup.. > > | +--+ | >| guest| | >| | | >| | | guest >| eth0 L3fwd eth1 | | >| | | | | >+---+--+---+ __| >^ : >| | >: v __ > +-+--+-+ | > | | ovs-br0 | | > | +--+ | | > | ^ : | | > | +--+ +-+ | | host > | : v | | > | +--++--+ | | > | | dpdk0 | ovs-dpdk | dpdk1 | | | > +---+--++--+---+ __| > ^ : > | | > : v > +--+ > | | > |traffic generator | > | | > +--+| > > > Step1: Use the latest ovs and dpdk2.0 to get the ovs running with 2 dpdk > interfaces that are bound to 2 10GB physical interfaces > #** Inser the required Modules > cd /root/dpdk-2.0.0 > modprobe uio > modprobe cuse > rmmod igb_uio > rmmod rte_kni > insmod x86_64-native-linuxapp-gcc/kmod/igb_uio.ko > > # Assign the dpdk capable interfaces to igb_uio driver > tools/dpdk_nic_bind.py --status > tools/dpdk_nic_bind.py -b igb_uio :02:00.0 > tools/dpdk_nic_bind.py -b igb_uio :02:00.1 > tools/dpdk_nic_bind.py --status > > #--- Setup the openVswitch > cd /root/ovs > pkill -9 ovs > mkdir -p /usr/local/etc/openvswitch > mkdir -p /usr/local/var/run/openvswitch > rm -rf /usr/local/etc/openvswitch/conf.db > ovsdb/ovsdb-tool create /usr/local/etc/openvswitch/conf.db > vswitchd/vswitch.ovsschema > > #Start ovsdb-server > ovsdb/ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/db.sock > --remote=db:Open_vSwitch,Open_vSwitch,manager_options --pidfile --detach > utilities/ovs-vsctl --no-wait init > > #Start vswitchd: > export DB_SOCK=/usr/local/var/run/openvswitch/db.sock > rm /dev/vhost-net > vswitchd/ovs-vswitchd --dpdk -c 0x3 -n 4 --socket-mem 1024,0 -- > unix:$DB_SOCK --pidfile --detach > > #Add bridge & ports > utilities/ovs-vsctl add-br ovs-br0 -- set bridge ovs-br0 > datapath_type=netdev > utilities/ovs-vsctl add-port ovs-br0 dpdk0 -- set Interface dpdk0 type=dpdk > utilities/ovs-vsctl add-port ovs-br0 dpdk1 -- set Interface dpdk1 type=dpdk > > Step2: Create the dpdkvhost interfaces and bring up the guestVM using QEMU > export DPDK_DIR=/root/dpdk-2.0.0 > insmod $DPDK_DIR/lib/librte_vhost/eventfd_link/eventfd_link.ko > cd /root/ovs > utilities/ovs-vsctl add-port ovs-br0 dpdkvhost0 -- set Interface > dpdkvhost0 type=dpdkvhost > utilities/ovs-vsctl add-port ovs-br0 dpdkvhost1 -- set Interface > dpdkvhost1 type=dpdkvhost > > # Start the guest ubuntu VM1 from a terminal that is logged in as root > qemu-system-x86_64 --enable-kvm -k fr -m 1G \ > -cpu host -smp cores=2,threads=1,sockets=1 \ > -serial telnet::,server,nowait -monitor > telnet::,server,nowait \ > -hda /root/VMs/images/ubuntu-14.04-template.qcow2 \ > -object > memory-backend-file,id=mem,size=1G,mem-path=/mnt/huge_1GB,share=on \ > -numa node,memdev=mem \ > -netdev > type=tap,id=dpdkvhost0,script=no,downscript=no,ifname=dpdkvhost0,vhost=on \ > -device > virtio-net- > pci,netdev=dpdkvhost0,mac=52:54:00:12:34:56,csum=off,gso=off,guest_tso4=off,g > uest_tso6=off,guest_ecn=off > \ > -netdev > type=tap,id=dpdkvhost1,script=no,downscript=no,ifname=dpdkvhost1,vhost=on \ > -device > virtio-net- > pci,netdev=dpdkvhost1,mac=52:54:00:12:34:57,csum=off,gso=off,guest_tso4=off,g > uest_tso6=off,guest_ecn=off > \ > -device ne2k_pci,mac=DE:AD:DE:01:02:03,netdev=user.0 -netdev > user,id=user.0,hostfwd=tcp::-:22 & > > # Add flows between ports > utilities/ovs-ofctl del-flows ovs-br0 > utilities/ovs-ofctl add-flow ovs-br0 in_port=1,action=output:3 > utilities/ovs-ofctl add-flow ovs-br0 in_port=2,action=output:4 > utilities/o
[dpdk-dev] dev@DPDK Hackathon Proposal
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Rao, Ravi > Sent: Tuesday, May 19, 2015 6:07 PM > To: Czesnowicz, Przemyslaw; Thomas F Herbert; O'Driscoll, Tim; Butler, > Siobhan A; dev at dpdk.org > Subject: Re: [dpdk-dev] dev at DPDK Hackathon Proposal > > Hi Przemek/Thomas, >Thanks for the info. But when I am using the latest ovs and the DPDK2.0 > the performance I am getting through the ovs switch is far less than non > dpdk. > I can send more info if you need. > I am using dpdkvhost0 and dpdkvhos1 interfaces that are based on vhost_cuse > to interact with VM. Is there any post that I can refer to see what I may be > missing ? Hi - I think this is going off topic for this thread, I suggest switching back to other thread where I had made some suggestions. This may be better on ovs-discuss also. > Currently these are my tasks > 1. Measure throughput with Just OVS on Host only == completed (600,000 pps) > *No Flow control > 2. Measure throughput with OVS+DPDK on Host only == completed (6.4 Mpps) > 3. Measure throughput on Guest spunup using QEMU with OVS bridge on Host == > completed (240,000 pps) > 4. Measure throughput on Guest spunup using QEMU with OVS DPDK on Host == > Having issues with perf just getting 60,000 pps > 5. Measure throughput on Guest spunup using Openstack with just OVS on > Compute node == completed (60,000 pps) > 6. Measure throughput on Guest spunup using Openstack with OVS DPDK on > Compute node. I can use the info provided by you and see if I can get this > running ?? > Regards, > Ravi.. > > > -Original Message- > From: Czesnowicz, Przemyslaw [mailto:przemyslaw.czesnowicz at intel.com] > Sent: Tuesday, May 19, 2015 11:09 AM > To: Rao, Ravi; Thomas F Herbert; O'Driscoll, Tim; Butler, Siobhan A; > dev at dpdk.org > Subject: RE: [dpdk-dev] dev at DPDK Hackathon Proposal > > Hi Ravi, > > Kilo release of Openstack allows to use ovs-dpdk with vhostuser. > Nova includes vhost-user vif driver, and for neutron we have a mechanism > driver and agent in stackforge project : > https://github.com/stackforge/networking-ovs-dpdk > > The neutron part is hosted on stackforge because of vendor decomposition > going on in neutron. > The contains a devstack plugin and instructions on how to setup the node. > > Let me know if you need more information. > > Regards > Przemek > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Rao, Ravi > > Sent: Tuesday, May 19, 2015 2:43 PM > > To: Thomas F Herbert; O'Driscoll, Tim; Butler, Siobhan A; dev at dpdk.org > > Subject: Re: [dpdk-dev] dev at DPDK Hackathon Proposal > > > > Hi All, > >Effort and emphasis has to be made to integrate DPDK into openstack > > components like neutron and nova so that this becomes part of std > > openstack release. > > Currently some work was done and published as a patch to devstack's > > Juno but there are no clear path to incorporate these patches to the > > mainline. I think this would be a very good topic to cover. > > Regards, > > Ravi > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas F Herbert > > Sent: Tuesday, May 19, 2015 8:37 AM > > To: O'Driscoll, Tim; Butler, Siobhan A; dev at dpdk.org > > Subject: Re: [dpdk-dev] dev at DPDK Hackathon Proposal > > > > On 5/19/15 8:59 AM, O'Driscoll, Tim wrote: > > > There wasn't any public response to this but we did discuss it with > > > several > > people separately who all thought it was a good idea. Therefore, we've > > decided to go ahead with it. Siobhan is working on the plan now and > > should be in a position to make a formal announcement in a few weeks. > > > > > > In the meantime, I wanted to let people know that this is going > > > ahead so > > that you can: > > > a) Save the date. October 8th/9th, immediately after the European > > LinuxCon, in Dublin Ireland. > > > b) Think about topics that you'd like to see covered. We'll solicit > > > for inputs > > when the formal announcement is made, but it's good for people to > > begin thinking about this now. > > > > > Tim, I for one think it is a good idea. +1 from me. > > > We'd like this to be quite an interactive event with a lot of > > > discussion rather > > than just presentations. We plan to have many of our key DPDK > > developers there, so it will be a great opportunity to network, > > discuss the technical challenges that you're facing and help to build a > stronger DPDK community. > > > > > > > > > > > Tim > > > > > >> -Original Message- > > >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Butler, > > >> Siobhan A > > >> Sent: Tuesday, March 31, 2015 7:19 PM > > >> To: dev at dpdk.org > > >> Subject: [dpdk-dev] dev at DPDK Hackathon Proposal > > >> > > >> Hi all, > > >> > > >> As a community we have virtually come together from all over the > > >> globe, developing now our third successful open source DPDK version > > >> with DPDK > > >
[dpdk-dev] [ovs-dev] OVS-DPDK performance problem on ixgbe vector PMD
> -Original Message- > From: dev [mailto:dev-bounces at openvswitch.org] On Behalf Of Zoltan Kiss > Sent: Friday, August 21, 2015 7:05 PM > To: dev at dpdk.org; dev at openvswitch.org > Cc: Richardson, Bruce; Ananyev, Konstantin > Subject: [ovs-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 previously turned on/off vectorisation and found that for tx it makes a significant difference. For Rx it didn't make a much of a difference but rx bulk allocation which gets enabled with it did improve performance. Is there is something else also running on the current pmd core? did you try moving it to another? Also, did you compile OVS with -O3/-Ofast, they tend to give a performance boost. Are you hitting 3.2 GHz for the core with the pmd? I think that is only with turbo boost, so it may not be achievable all the time. > 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 > ___ > dev mailing list > dev at openvswitch.org > http://openvswitch.org/mailman/listinfo/dev
[dpdk-dev] vSwitch Performance Comparison for NFV Use Case
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jun Xiao > Sent: Friday, August 21, 2015 8:18 PM > To: Gray, Mark D > Cc: dev > Subject: [dpdk-dev] vSwitch Performance Comparison for NFV Use Case > > Hi Mark, > Last time we discussed methodologies for vSwitch performance comparison, and > the performance data we published is more for typical TCP based applications > in virtualized data centers.Today we shared more data for small packet size > traffic at?http://cloudnetengine.com/en/blog/2015/08/21/vswitch-performance- > comparison-nfv-use-case, and the perfomance gets much closed (around?10-20%) > between OVS-DPDK and CNE vSwitch as the tests are barely forwarding and > without any other features. > > On the other hand, it's really hard to find any public performance data for > OVS-DPDK under pNIC -> vSwitch -> VM -> vSwitch -> pNIC case. What I observed > is that OVS-DPDK can have generally less than 3 MPPS on my setup (vhost user > is used instead of IVSHMEM), don't know if the data are aligned with what you > have? That seems reasonable enough (maybe a little low) considering you are on a 2.4 GHz and are using one logical core so the pmd will be sharing a physical core. As you said you will get greater performance if you add another pmd. You will also get better performance if you set rx_mrgbuf=off. Did you core affinitize the pmd to an empty core and the pkt fwding qemu thread to make sure they get the cycles they need? > Thanks,Junwww.cloudnetengine.com
[dpdk-dev] [ovs-dev] OVS with DPDK Meetup notes
> -Original Message- > From: Flavio Leitner [mailto:fbl at sysclose.org] > Sent: Monday, November 30, 2015 11:51 PM > To: Traynor, Kevin > Cc: dev at openvswitch.org; users at dpdk.org > Subject: Re: [ovs-dev] OVS with DPDK Meetup notes > > On Thu, Nov 26, 2015 at 05:56:08PM +, Traynor, Kevin wrote: > > Hi All, > > > > Just wanted to post some summary notes on the recent OVS with DPDK Meetup > we > > had after the OVS conference. Thanks to everyone for the often lively > discussion. > > I've collated and condensed Maryam's notes (Thank you Maryam) with my own. > > Corrections and additions are welcome. > > Thanks for having organized the event and for the good notes. > > > > Usability > > == > > * Single binary for OVS/OVS with DPDK and static vs. dynamic linking > > - Discussion around deployment and what the best model is. > > - Flavio has posted a mail on this > >http://openvswitch.org/pipermail/dev/2015-November/062599.html > > Let us know if you find a performance difference between static vs > dynamic linking. We might be able to accommodate both options in > the same spec, but it seems we should go with shared linking only > to keep it simple for now. > Yes, will do. I seem to recall from when we looked at this on a previous project it was a few hundred kpps but it was a long time ago, so I'm not certain how many. > > > Features > > > > * Multiqueue vhost-user > > - Looks really promising - will help us scale out performance to the VM. > > I see that vhost PMD is moving and if it gets accepted, it would > be a nice clean up for OVS. Do you know if there is someone working > on this already? I agree, it should simplify the code a lot. Ciara reviewed it and did a quick integration to see if the api would work. The patch was churning quite a bit, so we decided to hold off doing any more work with it for the time being. > > > * dpdkr/ivshmem > > - Still useful. Check/Update documentation to ensure limitations are > clear. > > Yeah, same thing here. > > Thanks, > fbl
[dpdk-dev] ovs-vswitchd crash
> -Original Message- > From: discuss [mailto:discuss-bounces at openvswitch.org] On Behalf Of MAO > Ruoyu > Sent: Friday, December 11, 2015 2:25 AM > To: discuss at openvswitch.org > Subject: [ovs-discuss] ovs-vswitchd crash > > Hi, > We install openstack using devstack with OVS-DPDK > We use host8 as compute node, use host16 as controller node. Now we create > vms on both of them as bellow. > on host8, we create vms V7510_OVS_DPDK-SCM11 and V7510_OVS_DPDK-PIM20; > on host16, we create vms V7510_OVS_DPDK-SCM10 and V7510_OVS_DPDK-PIM19. > we create vms successfully. > But after reboot of ?V7510_OVS_DPDK-SCM11 application, the ovs-vswitchd on > host8 crashed. > We don't know whether the reboot leads the service crashed or the service > crash leads the reboot. Cross posting to dpdk-dev. What kernel version are you running in the guest? there was previously an issue with the DPDK vhost-library and 3.19 I think. It might be worth to test OVS head of master with DPDK 2.1, or DPDK 2.2-rc3. > > We try QEMU 2.3.1, QEMU 2.2.1 and QEMU 2.1.3 on host8, but no effect. > Now we use DPDK2.0, OVS2.4. > > [root at host8 ~]# coredumpctl gdb 5295 > ???PID: 5295 (ovs-vswitchd) > ?? UID: 0 (root) > ?? GID: 107 (qemu) > ??? Signal: 11 (SEGV) > Timestamp: Thu 2015-12-10 16:49:17 CST (16h ago) > ? Command Line: /usr/sbin/ovs-vswitchd --dpdk -vhost_sock_dir > /var/run/openvswitch -c 2 -n 4 --proc-type primary --huge-dir /mnt/huge -- > socket-mem 2048 2048 -- unix:/var/run/openvswitch/db.sock > ??? Executable: /usr/sbin/ovs-vswitchd > Control Group: /user.slice/user-1000.slice/session-1.scope > ? Unit: session-1.scope > Slice: user-1000.slice > ?? Session: 1 > Owner UID: 1000 (diag) > ?? Boot ID: beb01a89b99f494f858c529df3cbf6a2 > ??? Machine ID: 793afa475dbd4b84949ba36a4a0fcd13 > ? Hostname: host8 > ? Coredump: /var/lib/systemd/coredump/core.ovs- > vswitchd.0.beb01a89b99f494f858c529df3cbf6a2.5295.144973735700.xz > ?? Message: Process 5295 (ovs-vswitchd) of user 0 dumped core. > > Stack trace of thread 5601: > ??? #0? 0x00530852 rte_log_add_in_history (ovs-vswitchd) > ??? #1? 0x004c9cbe console_log_write (ovs-vswitchd) > ??? #2? 0x7fcd9c9d9501 _IO_cookie_write (libc.so.6) > ??? #3? 0x7fcd9c9e51d9 _IO_do_write@@GLIBC_2.2.5 (libc.so.6) > ??? #4? 0x7fcd9c9e35d0 _IO_file_sync@@GLIBC_2.2.5 (libc.so.6) > ??? #5? 0x7fcd9c9d8f66 _IO_fflush (libc.so.6) > ??? #6? 0x005315f7 rte_vlog (ovs-vswitchd) > ???#7? 0x0040648d rte_log (ovs-vswitchd) > ??? #8? 0x0046c930 rte_vhost_enqueue_burst (ovs-vswitchd) > ??? #9? 0x00676051 __netdev_dpdk_vhost_send (ovs- > vswitchd) > ??? #10 0x00676967 netdev_dpdk_vhost_send (ovs-vswitchd) > ??? #11 0x005bcda0 netdev_send (ovs-vswitchd) > ??? #12 0x00599d21 dp_execute_cb (ovs-vswitchd) > ??? #13 0x005c60f4 odp_execute_actions (ovs-vswitchd) > ???#14 0x00598e6c dp_netdev_input (ovs-vswitchd) > ??? #15 0x00599197 dp_netdev_process_rxq_port (ovs- > vswitchd) > ??? #16 0x0059981c pmd_thread_main (ovs-vswitchd) > ??? #17 0x0060ba34 ovsthread_wrapper (ovs-vswitchd) > ??? #18 0x7fcd9d47d52a start_thread (libpthread.so.0) > ??? #19 0x7fcd9ca6b22d __clone (libc.so.6) > > Stack trace of thread 5600: > ??? #0? 0x0046d675 rte_vhost_dequeue_burst (ovs-vswitchd) > ??? #1? 0x00672bbc netdev_dpdk_vhost_rxq_recv (ovs- > vswitchd) > ??? #2? 0x005bcca1 netdev_rxq_recv (ovs-vswitchd) > ??? #3? 0x005990b4 dp_netdev_process_rxq_port (ovs- > vswitchd) > ??? #4? 0x0059981c pmd_thread_main (ovs-vswitchd) > ??? #5? 0x0060ba34 ovsthread_wrapper (ovs-vswitchd) > ??? #6? 0x7fcd9d47d52a start_thread (libpthread.so.0) > ??? #7? 0x7fcd9ca6b22d __clone (libc.so.6) > > Stack trace of thread 6960: > ??? #0? 0x7fcd9ca5fc8d poll (libc.so.6) > ??? #1? 0x00637b9d time_poll (ovs-vswitchd) > ? ??#2? 0x0061e33c poll_block (ovs-vswitchd) > ??? #3? 0x00568c1f udpif_upcall_handler (ovs-vswitchd) > ??? #4? 0x0060ba34 ovsthread_wrapper (ovs-vswitchd) > ??? #5? 0x7fcd9d47d52a start_thread (libpthread.so.0) > ??? #6? 0x7fcd9ca6b22d __clone (libc.so.6) > > Our flavor like that: > > > Any try can we do? Thank you. > > > Best Regards > Mao Ruoyu > +86 21 38434078
[dpdk-dev] [PATCH] config: remove duplicate configuration information
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Thursday, March 3, 2016 6:38 PM > To: Wiles, Keith > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] config: remove duplicate configuration > information > > 2016-02-22 07:53, Keith Wiles: > > --- /dev/null > > +++ b/config/common_base > > +CONFIG_RTE_EAL_IGB_UIO=y > > +CONFIG_RTE_EAL_VFIO=y > > These options should be disabled in the base file > and enabled in Linux. > > > +CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y > > Idem, it should be disabled. > > > +CONFIG_RTE_LIBRTE_POWER=y > > Idem? > > > +CONFIG_RTE_LIBRTE_KNI=y > > Should be disabled. > > > +CONFIG_RTE_LIBRTE_VHOST=y > > Should be disabled. Any reason this should be disabled? It was changed to =Y in DPDK 2.1. It means updating scripts/build instructions to set =Y for OVS, no big deal but it might catch people out. Kevin. > > > --- a/config/common_bsdapp > > +++ b/config/common_bsdapp > > +# Compile Environment Abstraction Layer for linux, FreeBSD, OS X, ... > > +CONFIG_RTE_LIBRTE_EAL_BSDAPP=y > > Please keep the original comment: > Compile Environment Abstraction Layer for BSD > > > +# Compile Environment Abstraction Layer > > Why this comment before disabling UIO and VFIO? > > > --- a/config/common_linuxapp > > +++ b/config/common_linuxapp > > -## > > -## machine can define specific variables or action for a specific board > > -## RTE_MACHINE values are the directories in mk/machine/ > > -## > > -#CONFIG_RTE_MACHINE="native" > > -# > > -## > > -## define the architecture we compile for. > > -## RTE_ARCH values are the directories in mk/arch/ > > -## > > -#CONFIG_RTE_ARCH="x86_64" > > -#CONFIG_RTE_ARCH_X86_64=y > > -#CONFIG_RTE_ARCH_X86=y > > -# > > -## > > -## The compiler we use. > > -## RTE_TOOLCHAIN values are the directories in mk/toolchain/ > > -## > > -#CONFIG_RTE_TOOLCHAIN="gcc" > > -#CONFIG_RTE_TOOLCHAIN_GCC=y > > Maybe we should keep these comments in common_base? > I would remove the values and uncomment CONFIG_RTE_MACHINE, CONFIG_RTE_ARCH > and CONFIG_RTE_TOOLCHAIN. > > > --- a/config/defconfig_x86_64-native-bsdapp-clang > > +++ b/config/defconfig_x86_64-native-bsdapp-clang > > @@ -37,6 +37,7 @@ CONFIG_RTE_MACHINE="native" > > CONFIG_RTE_ARCH="x86_64" > > CONFIG_RTE_ARCH_X86_64=y > > CONFIG_RTE_ARCH_X86=y > > +CONFIG_RTE_ARCH_64=y > > > > CONFIG_RTE_TOOLCHAIN="clang" > > CONFIG_RTE_TOOLCHAIN_CLANG=y > > diff --git a/config/defconfig_x86_64-native-bsdapp-gcc > b/config/defconfig_x86_64-native-bsdapp-gcc > > index 5a6a4e8..4ea4433 100644 > > --- a/config/defconfig_x86_64-native-bsdapp-gcc > > +++ b/config/defconfig_x86_64-native-bsdapp-gcc > > @@ -37,6 +37,7 @@ CONFIG_RTE_MACHINE="native" > > CONFIG_RTE_ARCH="x86_64" > > CONFIG_RTE_ARCH_X86_64=y > > CONFIG_RTE_ARCH_X86=y > > +CONFIG_RTE_ARCH_64=y > > It should be a totally separate patch. > And there are other places where it is missing.
[dpdk-dev] [PATCH] config: remove duplicate configuration information
> -Original Message- > From: Panu Matilainen [mailto:pmatilai at redhat.com] > Sent: Friday, March 4, 2016 9:39 AM > To: Traynor, Kevin ; Thomas Monjalon > ; Wiles, Keith > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] config: remove duplicate configuration > information > > On 03/04/2016 11:28 AM, Traynor, Kevin wrote: > > > >> -Original Message- > >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > >> Sent: Thursday, March 3, 2016 6:38 PM > >> To: Wiles, Keith > >> Cc: dev at dpdk.org > >> Subject: Re: [dpdk-dev] [PATCH] config: remove duplicate configuration > >> information > >> > >> 2016-02-22 07:53, Keith Wiles: > >>> --- /dev/null > >>> +++ b/config/common_base > >>> +CONFIG_RTE_EAL_IGB_UIO=y > >>> +CONFIG_RTE_EAL_VFIO=y > >> > >> These options should be disabled in the base file > >> and enabled in Linux. > ^ > > >> > >>> +CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y > >> > >> Idem, it should be disabled. > >> > >>> +CONFIG_RTE_LIBRTE_POWER=y > >> > >> Idem? > >> > >>> +CONFIG_RTE_LIBRTE_KNI=y > >> > >> Should be disabled. > >> > >>> +CONFIG_RTE_LIBRTE_VHOST=y > >> > >> Should be disabled. > > > > Any reason this should be disabled? It was changed to =Y in DPDK 2.1. > > That's what I first thought too, but I think Thomas meant "disable in > common_base, enable in Linux config" for all these. > > - Panu - Ah, ok - got it, that makes sense. thanks.
[dpdk-dev] Packet drops during non-exhaustive flood with OVS and 1.8.0
> -Original Message-
> From: Andrey Korolyov [mailto:andrey at xdel.ru]
> Sent: Monday, February 2, 2015 10:53 AM
> To: dev at dpdk.org
> Cc: discuss at openvswitch.org; Traynor, Kevin
> Subject: Re: Packet drops during non-exhaustive flood with OVS and 1.8.0
>
> On Thu, Jan 22, 2015 at 8:11 PM, Andrey Korolyov wrote:
> > On Wed, Jan 21, 2015 at 8:02 PM, Andrey Korolyov wrote:
> >> Hello,
> >>
> >> I observed that the latest OVS with dpdk-1.8.0 and igb_uio starts to
> >> drop packets earlier than a regular Linux ixgbe 10G interface, setup
> >> follows:
> >>
> >> receiver/forwarder:
> >> - 8 core/2 head system with E5-2603v2, cores 1-3 are given to OVS
> >> exclusively
> >> - n-dpdk-rxqs=6, rx scattering is not enabled
> >> - x520 da
> >> - 3.10/3.18 host kernel
> >> - during 'legacy mode' testing, queue interrupts are scattered through all
> >> cores
> >>
> >> sender:
> >> - 16-core E52630, netmap framework for packet generation
> >> - pkt-gen -f tx -i eth2 -s 10.6.9.0-10.6.9.255 -d
> >> 10.6.10.0-10.6.10.255 -S 90:e2:ba:84:19:a0 -D 90:e2:ba:85:06:07 -R
> >> 1100, results in 11Mpps 60-byte packet flood, there are constant
> >> values during test.
> >>
> >> OVS contains only single drop rule at the moment:
> >> ovs-ofctl add-flow br0 in_port=1,actions=DROP
> >>
> >> Packet generator was launched for tens of seconds for both Linux stack
> >> and OVS+DPDK cases, resulting in zero drop/error count on the
> >> interface in first, along with same counter values on pktgen and host
> >> interface stat (means that the none of generated packets are
> >> unaccounted).
> >>
> >> I selected rate for about 11M because OVS starts to do packet drop
> >> around this value, after same short test interface stat shows
> >> following:
> >>
> >> statistics : {collisions=0, rx_bytes=22003928768,
> >> rx_crc_err=0, rx_dropped=0, rx_errors=10694693, rx_frame_err=0,
> >> rx_over_err=0, rx_packets=343811387, tx_bytes=0, tx_dropped=0,
> >> tx_errors=0, tx_packets=0}
> >>
> >> pktgen side:
> >> Sent 354506080 packets, 60 bytes each, in 32.23 seconds.
> >> Speed: 11.00 Mpps Bandwidth: 5.28 Gbps (raw 7.39 Gbps)
> >>
> >> If rate will be increased up to 13-14Mpps, the relative error/overall
> >> ratio will rise up to a one third. So far OVS on dpdk shows perfect
> >> results and I do not want to reject this solution due to exhaustive
> >> behavior like described one, so I`m open for any suggestions to
> >> improve the situation (except using 1.7 branch :) ).
> >
> > At a glance it looks like there is a problem with pmd threads, as they
> > starting to consume about five thousandth of sys% on a dedicated cores
> > during flood but in theory they should not. Any ideas for
> > debugging/improving this situation are very welcomed!
>
> Over the time from a last message I tried a couple of different
> configurations, but packet loss starting to happen as early as at
> 7-8Mpps. Looks like that the bulk processing which has been in
> OVS-DPDK distro is missing from series of patches
> (http://openvswitch.org/pipermail/dev/2014-December/049722.html,
> http://openvswitch.org/pipermail/dev/2014-December/049723.html).
> Before implementing this, I would like to know if there can be any
> obvious (not for me unfortunately) clues on this performance issue.
These patches are to enable DPDK 1.8 only. What 'bulk processing' are you
referring to?
By default there is a batch size of 192 in netdev-dpdk for rx from the NIC -
the linked
patch doesn't change this, just the DPDK version.
Main things to consider are to isocpu's, pin the pmd thread and keep everything
on 1 NUMA socket. At 11 mpps without packet loss on that processor I suspect
you are
doing those things already.
>
> Thanks!
[dpdk-dev] Packet drops during non-exhaustive flood with OVS and 1.8.0
> -Original Message- > From: Andrey Korolyov [mailto:andrey at xdel.ru] > Sent: Tuesday, February 3, 2015 5:21 PM > To: Traynor, Kevin > Cc: dev at dpdk.org; discuss at openvswitch.org > Subject: Re: Packet drops during non-exhaustive flood with OVS and 1.8.0 > > > These patches are to enable DPDK 1.8 only. What 'bulk processing' are you > > referring to? > > By default there is a batch size of 192 in netdev-dpdk for rx from the NIC > > - the linked > > patch doesn't change this, just the DPDK version. > > Sorry, I referred the wrong part there: bulk transmission, which is > clearly not involved in my case. The idea was that the conditionally > enabling prefetch for rx queues (BULK_ALLOC) may help somehow, but > it`s probably will mask issue instead of solving it directly. By my > understanding, strict drop rule should have a zero impact on a main > ovs thread (and this is true) and work just fine with a line rate > (this is not). I've set a similar drop rule and I'm seeing the first packet drops occurring at 13.9 mpps for 64 byte pkts. I'm not sure if there is a config that can be changed or if it just the cost of the emc/lookups > > > > > Main things to consider are to isocpu's, pin the pmd thread and keep > > everything > > on 1 NUMA socket. At 11 mpps without packet loss on that processor I > > suspect you are > > doing those things already. > > Yes, with all tuning improvements I was able to do this, but bare > Linux stack on same machine is able to handle 12Mpps and there are > absolutely no hints of what exactly is being congested.
[dpdk-dev] Packet drops during non-exhaustive flood with OVS and 1.8.0
> -Original Message- > From: Andrey Korolyov [mailto:andrey at xdel.ru] > Sent: Thursday, February 12, 2015 3:16 PM > To: Traynor, Kevin > Cc: dev at dpdk.org; discuss at openvswitch.org > Subject: Re: Packet drops during non-exhaustive flood with OVS and 1.8.0 > > On Thu, Feb 12, 2015 at 6:05 PM, Traynor, Kevin > wrote: > >> -Original Message- > >> From: Andrey Korolyov [mailto:andrey at xdel.ru] > >> Sent: Tuesday, February 3, 2015 5:21 PM > >> To: Traynor, Kevin > >> Cc: dev at dpdk.org; discuss at openvswitch.org > >> Subject: Re: Packet drops during non-exhaustive flood with OVS and 1.8.0 > >> > >> > These patches are to enable DPDK 1.8 only. What 'bulk processing' are > >> > you referring to? > >> > By default there is a batch size of 192 in netdev-dpdk for rx from the > >> > NIC - the linked > >> > patch doesn't change this, just the DPDK version. > >> > >> Sorry, I referred the wrong part there: bulk transmission, which is > >> clearly not involved in my case. The idea was that the conditionally > >> enabling prefetch for rx queues (BULK_ALLOC) may help somehow, but > >> it`s probably will mask issue instead of solving it directly. By my > >> understanding, strict drop rule should have a zero impact on a main > >> ovs thread (and this is true) and work just fine with a line rate > >> (this is not). > > > > I've set a similar drop rule and I'm seeing the first packet drops occurring > > at 13.9 mpps for 64 byte pkts. I'm not sure if there is a config that can be > > changed or if it just the cost of the emc/lookups > > > > Do you mind to compare this case with forward to the dummy port > (ifconfig dummy0; ovs-vsctl add-port br0 dummy0; ip link set dev > dummy0 up; flush rule table; create a single forward rule; start an > attack)? As I mentioned there are no signs of syscall congestion for a > drop or dpdk-dpdk forward case. Assuming I've understood your setup, I get a very low rate (~1.1 mpps) without packet loss as I'm sending the packets from a dpdk port to a socket for the dummy port
[dpdk-dev] Undefined reference to FUSE
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of I?akiMurillo > Sent: Friday, March 13, 2015 2:39 PM > To: De Lara Guarch, Pablo; dev at dpdk.org > Subject: Re: [dpdk-dev] Undefined reference to FUSE > > Hi Pablo, > > Thank you very much, it worked for me. > > But now I am trying to compile openvswicth after applying the next patch: > > http://openvswitch.org/pipermail/dev/2015-January/050278.html > > And it happends the same. I gues that I should ask in the ovs mail list, > but in case you know the answer I ask here. For ovs, if you use the head of master and the latest vhost patch, you shouldn't see that error http://openvswitch.org/pipermail/dev/2015-March/052061.html > > Thank you in advanced. > > Regards, > > I?aki > > > El 13/03/15 a las 13:09, De Lara Guarch, Pablo escribi?: > > Hi I?aki, > > > >> -Original Message- > >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of I?akiMurillo > >> Sent: Friday, March 13, 2015 11:50 AM > >> To: dev at dpdk.org > >> Subject: [dpdk-dev] Undefined reference to FUSE > >> > >> Hello, > >> > >> I am trying to compile the vhost example using DPDK 1.8.0. I have > >> installed fuse and libfuse-dev (as I am using Ubuntu). I have modified > >> config/common_linuxapp as follows: > >> > >> CONFIG_RTE_BUILD_COMBINE_LIBS=y > >> CONFIG_RTE_LIBRTE_VHOST=y > >> > >> Then, I compile DPDK 1.8.0 as follows: > >> > >> make config T=x86_64-native-linuxapp-gcc > >> make install T=x86_64-native-linuxapp-gcc > >> > >> And when it comes to compile vhost example I get errors about undefined > >> reference. To compile it I use theses intructions: > >> > >> export RTE_SDK=/path/to/dpdk-1.8.0 > >> export RTE_TARGET=x86_64-native-linuxapp-gcc > >> make > >> > >> The log of the error is: > >> > >> > >> CC main.o > >> LD vhost-switch > >> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp- > >> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o): > >> In function `vhost_net_ioctl': > >> vhost-net-cdev.c:(.text+0x3c): undefined reference to `fuse_req_ctx' > >> vhost-net-cdev.c:(.text+0xd5): undefined reference to > >> `fuse_reply_ioctl_retry' > >> vhost-net-cdev.c:(.text+0x185): undefined reference to `fuse_reply_ioctl' > >> vhost-net-cdev.c:(.text+0x253): undefined reference to > >> `fuse_reply_ioctl_retry' > >> vhost-net-cdev.c:(.text+0x2c2): undefined reference to `fuse_reply_ioctl' > >> vhost-net-cdev.c:(.text+0x30a): undefined reference to `fuse_reply_err' > >> vhost-net-cdev.c:(.text+0x359): undefined reference to > >> `fuse_reply_ioctl_retry' > >> vhost-net-cdev.c:(.text+0x472): undefined reference to `fuse_reply_ioctl' > >> vhost-net-cdev.c:(.text+0x49f): undefined reference to `fuse_reply_ioctl' > >> vhost-net-cdev.c:(.text+0x4ea): undefined reference to `fuse_reply_ioctl' > >> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp- > >> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o): > >> In function `vhost_net_release': > >> vhost-net-cdev.c:(.text+0x515): undefined reference to `fuse_req_ctx' > >> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp- > >> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o): > >> In function `vhost_net_open': > >> vhost-net-cdev.c:(.text+0x58d): undefined reference to `fuse_req_ctx' > >> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp- > >> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o): > >> In function `rte_vhost_driver_register': > >> vhost-net-cdev.c:(.text+0x828): undefined reference to > >> `cuse_lowlevel_setup' > >> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp- > >> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o): > >> In function `rte_vhost_driver_session_start': > >> vhost-net-cdev.c:(.text+0x86c): undefined reference to `fuse_session_loop' > >> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp- > >> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o): > >> In function `vhost_net_release': > >> vhost-net-cdev.c:(.text+0x55b): undefined reference to `fuse_reply_err' > >> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp- > >> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o): > >> In function `vhost_net_open': > >> vhost-net-cdev.c:(.text+0x5d3): undefined reference to `fuse_reply_open' > >> vhost-net-cdev.c:(.text+0x5ef): undefined reference to `fuse_reply_err' > >> collect2: ld returned 1 exit status > >> make[1]: *** [vhost-switch] Error 1 > >> make: *** [all] Error 2 > >> > >> > >> Can anyone help me? > > This was fixed after 1.8.0, on this patch: > > http://dpdk.org/dev/patchwork/patch/2603/ > > > > You can either apply it yourself or get the latest code using git. > > > > Regards, > > Pablo > >> Thank you in advanced. > >>
[dpdk-dev] Undefined reference to FUSE
> -Original Message- > From: I?akiMurillo [mailto:inaki.murilloa at ehu.eus] > Sent: Monday, March 16, 2015 9:47 AM > To: Traynor, Kevin; De Lara Guarch, Pablo; dev at dpdk.org > Subject: Re: [dpdk-dev] Undefined reference to FUSE > > Hello, > > I have done a fresh install of dpdk-1.8.0 and ovs master brunch of > github with the next patches: > > OVS: http://openvswitch.org/pipermail/dev/2015-March/052061.html > DPDK: http://dpdk.org/dev/patchwork/patch/2603/ Hi, can you try again except use tagged DPDK v1.8.0 without any patches to it. Just turn COMBINE_LIB and VHOST_LIB settings to y. It might not be the problem, but best to rule out as that's how we tested. I rebased at the time to commit id 7cc398 on OVS master. > > I still get the same error while compiling the ovs. I followed the same > instructions as I mentioned in passed emails. > > Any suggestions? > > Thank you in advanced. > > Regards, > > I?aki > > El 13/03/15 a las 15:43, Traynor, Kevin escribi?: > >> -Original Message- > >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of I?akiMurillo > >> Sent: Friday, March 13, 2015 2:39 PM > >> To: De Lara Guarch, Pablo; dev at dpdk.org > >> Subject: Re: [dpdk-dev] Undefined reference to FUSE > >> > >> Hi Pablo, > >> > >> Thank you very much, it worked for me. > >> > >> But now I am trying to compile openvswicth after applying the next patch: > >> > >> http://openvswitch.org/pipermail/dev/2015-January/050278.html > >> > >> And it happends the same. I gues that I should ask in the ovs mail list, > >> but in case you know the answer I ask here. > > For ovs, if you use the head of master and the latest vhost patch, you > > shouldn't see that error > > http://openvswitch.org/pipermail/dev/2015-March/052061.html > > > > > >> Thank you in advanced. > >> > >> Regards, > >> > >> I?aki > >> > >> > >> El 13/03/15 a las 13:09, De Lara Guarch, Pablo escribi?: > >>> Hi I?aki, > >>> > >>>> -Original Message- > >>>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of I?akiMurillo > >>>> Sent: Friday, March 13, 2015 11:50 AM > >>>> To: dev at dpdk.org > >>>> Subject: [dpdk-dev] Undefined reference to FUSE > >>>> > >>>> Hello, > >>>> > >>>> I am trying to compile the vhost example using DPDK 1.8.0. I have > >>>> installed fuse and libfuse-dev (as I am using Ubuntu). I have modified > >>>> config/common_linuxapp as follows: > >>>> > >>>> CONFIG_RTE_BUILD_COMBINE_LIBS=y > >>>> CONFIG_RTE_LIBRTE_VHOST=y > >>>> > >>>> Then, I compile DPDK 1.8.0 as follows: > >>>> > >>>> make config T=x86_64-native-linuxapp-gcc > >>>> make install T=x86_64-native-linuxapp-gcc > >>>> > >>>> And when it comes to compile vhost example I get errors about undefined > >>>> reference. To compile it I use theses intructions: > >>>> > >>>> export RTE_SDK=/path/to/dpdk-1.8.0 > >>>> export RTE_TARGET=x86_64-native-linuxapp-gcc > >>>> make > >>>> > >>>> The log of the error is: > >>>> > >>>> > >>>> CC main.o > >>>> LD vhost-switch > >>>> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp- > >>>> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o): > >>>> In function `vhost_net_ioctl': > >>>> vhost-net-cdev.c:(.text+0x3c): undefined reference to `fuse_req_ctx' > >>>> vhost-net-cdev.c:(.text+0xd5): undefined reference to > >>>> `fuse_reply_ioctl_retry' > >>>> vhost-net-cdev.c:(.text+0x185): undefined reference to > `fuse_reply_ioctl' > >>>> vhost-net-cdev.c:(.text+0x253): undefined reference to > >>>> `fuse_reply_ioctl_retry' > >>>> vhost-net-cdev.c:(.text+0x2c2): undefined reference to > `fuse_reply_ioctl' > >>>> vhost-net-cdev.c:(.text+0x30a): undefined reference to `fuse_reply_err' > >>>> vhost-net-cdev.c:(.text+0x359): undefined reference to > >>>> `fuse_reply_ioctl_retry' > >>>> vhost-net-cdev.c:(.text+0x472): undefined reference to > `fuse_reply_ioctl' > >>>> vhost-net-cdev.c:(.text+0x49f): undefin
[dpdk-dev] Undefined reference to FUSE
> -Original Message- > From: I?akiMurillo [mailto:inaki.murilloa at ehu.eus] > Sent: Monday, March 16, 2015 4:37 PM > To: Traynor, Kevin > Cc: De Lara Guarch, Pablo; dev at dpdk.org > Subject: Re: [dpdk-dev] Undefined reference to FUSE > > Hello, > > I have done what you said but it does not work. I did it in the server > I usually use and in a VM, in both of them appears the error. > To be clear, I have followed the next instructions: > > apt-get install fuse > apt-get install libfuse-dev > download dpdk-1.8.0 > modify common_linuxapp: > +CONFIG_RTE_BUILD_COMBINE_LIBS=y > +CONFIG_RTE_LIBRTE_VHOST=y > make config T=x86_64-native-linuxapp-gcc > make install T=x86_64-native-linuxapp-gcc > > git clone ovs > apply next patch: > http://openvswitch.org/pipermail/dev/2015-March/052061.html > ./boot.sh > ./configure --with-dpdk=$DPDK_BUILD > make > > Is anything wrong with it? I don't see anything obvious that's wrong. I've just checked it now on my own system with the commit I rebased against and it's compiling ok. I'm on F20 with 3.16. The part of the patch that adds the fuse library is below, so you could check to make sure it has applied ok. diff --git a/lib/automake.mk b/lib/automake.mk index 2acfe18..594dec4 100644 --- a/lib/automake.mk +++ b/lib/automake.mk @@ -346,6 +346,7 @@ lib_libopenvswitch_la_SOURCES += \ endif if DPDK_NETDEV +lib_libopenvswitch_la_LDFLAGS += -lfuse After that I'm not really sure where to go. I'll try it on the head of master when I'm back in the office on Wednesday. > > Thank you in advanced. > > Regards, > I?aki > > > > El 16/03/15 a las 14:56, Traynor, Kevin escribi?: > >> -Original Message- > >> From: I?akiMurillo [mailto:inaki.murilloa at ehu.eus] > >> Sent: Monday, March 16, 2015 9:47 AM > >> To: Traynor, Kevin; De Lara Guarch, Pablo; dev at dpdk.org > >> Subject: Re: [dpdk-dev] Undefined reference to FUSE > >> > >> Hello, > >> > >> I have done a fresh install of dpdk-1.8.0 and ovs master brunch of > >> github with the next patches: > >> > >> OVS: http://openvswitch.org/pipermail/dev/2015-March/052061.html > >> DPDK: http://dpdk.org/dev/patchwork/patch/2603/ > > Hi, can you try again except use tagged DPDK v1.8.0 without any patches to > > it. Just turn COMBINE_LIB and VHOST_LIB settings to y. It might not be the > > problem, but best to rule out as that's how we tested. > > > > I rebased at the time to commit id 7cc398 on OVS master. > > > >> I still get the same error while compiling the ovs. I followed the same > >> instructions as I mentioned in passed emails. > >> > >> Any suggestions? > >> > >> Thank you in advanced. > >> > >> Regards, > >> > >> I?aki > >> > >> El 13/03/15 a las 15:43, Traynor, Kevin escribi?: > >>>> -Original Message- > >>>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of I?akiMurillo > >>>> Sent: Friday, March 13, 2015 2:39 PM > >>>> To: De Lara Guarch, Pablo; dev at dpdk.org > >>>> Subject: Re: [dpdk-dev] Undefined reference to FUSE > >>>> > >>>> Hi Pablo, > >>>> > >>>> Thank you very much, it worked for me. > >>>> > >>>> But now I am trying to compile openvswicth after applying the next > patch: > >>>> > >>>> http://openvswitch.org/pipermail/dev/2015-January/050278.html > >>>> > >>>> And it happends the same. I gues that I should ask in the ovs mail list, > >>>> but in case you know the answer I ask here. > >>> For ovs, if you use the head of master and the latest vhost patch, you > >>> shouldn't see that error > >>> http://openvswitch.org/pipermail/dev/2015-March/052061.html > >>> > >>> > >>>> Thank you in advanced. > >>>> > >>>> Regards, > >>>> > >>>> I?aki > >>>> > >>>> > >>>> El 13/03/15 a las 13:09, De Lara Guarch, Pablo escribi?: > >>>>> Hi I?aki, > >>>>> > >>>>>> -Original Message- > >>>>>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of I?akiMurillo > >>>>>> Sent: Friday, March 13, 2015 11:50 AM > >>>>>> To: dev at dpdk.org > >>>>>> Subject: [dpdk-dev] Undefined reference to FUSE > >>>>
[dpdk-dev] Issues met while running openvswitch/dpdk/virtio inside the VM
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pravin Shelar > Sent: Friday, May 8, 2015 2:20 AM > To: Oleg Strikov > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] Issues met while running openvswitch/dpdk/virtio > inside the VM > > On Thu, May 7, 2015 at 9:22 AM, Oleg Strikov > wrote: > > Hi DPDK users and developers, > > > > Few weeks ago I came up with the idea to run openvswitch with dpdk backend > > inside qemu-kvm virtual machine. I don't have enough supported NICs yet and > > my plan was to start experimenting inside the virtualized environment, > > achieve functional state of all the components and then switch to the real > > hardware. Additional useful side-effect of doing things inside the vm is > > that issues can be easily reproduced by someone else in a different > > environment. > > > > I (fondly) hoped that running openvswitch/dpdk inside the vm would be > > simpler than running the same set of components on the real hardware. > > Unfortunately I met a bunch of issues on the way. All these issues lie on a > > borderline between dpdk and openvswitch but I think that you might be > > interested in my story. Please note that I still don't have > > openvswitch/dpdk working inside the vm. I definetely have some progress > > though. > > > Thanks for summarizing all the issues. > DPDK is testing is done on real hardware and we are planing testing it > in VM. This will certainly help in fixing issues sooner. > > > Q: Does it sound okay from functional (not performance) standpoint to run > > openvswitch/dpdk inside the vm? Do we want to be able to do this? Does > > anyone from the dpdk development team do this? > > > > ## Issue 1 ## > > > > Openvswitch requires backend pmd driver to provide N_CORES tx queues where > > N_CORES is the amount of cores available on the machine (openvswitch counts > > the amount of cpu* entries inside /sys/devices/system/node/node0/ folder). > > To my understanding it doesn't take into account the actual amount of cores > > used by dpdk and just allocates tx queue for each available core. You may > > refer to this chunk of code for details: > > https://github.com/openvswitch/ovs/blob/master/lib/dpif-netdev.c#L1067 > > > In case of OVS DPDK, there is no dpdk thread. Therefore all polling > cores are managed by OVS and there is no need to account cores for > DPDK. You can assign specific cores for OVS to limit number of cores > used by OVS. > > > This approach works fine on the real hardware but makes some issues when we > > run openvswitch/dpdk inside the virtual machine. I tried both emulated > > e1000 NIC and virtio NIC and neither of them worked just from the box. > > Emulated e1000 NIC doesn't support multiple tx queues at all (see > > http://dpdk.org/browse/dpdk/tree/lib/librte_pmd_e1000/em_ethdev.c#n884) and > > virtio NIC doesn't support multiple tx queues by default. To enable > > multiple tx queue for virtio NIC I had to add the following line to the > > interface section of my libvirt config: '' > > > Good point. We should document this. Can you send patch to update > README.DPDK? Daniele's patch http://openvswitch.org/pipermail/dev/2015-March/052344.html also allows for having a limited set of queues available. The documentation patch is a good idea too. > > > ## Issue 2 ## > > > > Openvswitch calls rte_eth_tx_queue_setup() twice for the same > > port_id/queue_id. First call takes place during device initialization (see > > call to dpdk_eth_dev_init() inside netdev_dpdk_init(): > > https://github.com/openvswitch/ovs/blob/master/lib/netdev-dpdk.c#L522). > > Second call takes place when openvswitch tries to add more tx queues to the > > device (see call to dpdk_eth_dev_init() inside netdev_dpdk_set_multiq(): > > https://github.com/openvswitch/ovs/blob/master/lib/netdev-dpdk.c#L697). > > Second call not only initialized new queues but tries to re-initialize > > existing ones. > > > > Unfortunately virtio driver can't handle second call of > > rte_eth_tx_queue_setup() and returns error here: > > http://dpdk.org/browse/dpdk/tree/lib/librte_pmd_virtio/virtio_ethdev.c#n316 > > This happens because memzone with the name portN_tvqN already exists when > > second call takes place (memzone has been created during the first call). > > To deal with this issue I had to manually add rte_memzone_lookup-based > > check for this situation and avoid allocation of a new memzone if it > > already exists. > > > This sounds like issue with virtIO driver. I think we need to fix DPDK > upstream for this to work correctly. > > > Q: Is it okay that openvswitch calls rte_eth_tx_queue_setup() twice? Right > > now I can't understand if it's the issue with the virtio pmd driver or > > incorrect API usage by openvswitch? Could someone shed some light on this > > so I can move forward and maybe propose a fix. > > > > ## Issue 3 ## > > > > This issue is also (somehow) related to the fact that openvswitch calls > > rte_eth_tx_queue_setup() twice. I
[dpdk-dev] [RFC PATCH v2] vhost: Add VHOST PMD
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tetsuya Mukawa [snip] > > Hi, > > I have submitted latest patches. > I will keep vhost library until we will have agreement to merge it to > vhost PMD. Longer term there are pros and cons to keeping the vhost library. Personally I think it would make sense to remove sometime as trying to maintain two API's has a cost, but I think adding a deprecation notice in DPDK 2.2 for removal in DPDK 2.3 is very premature. Until it's proven *in the field* that the vhost PMD is a suitable fully functioning replacement for the vhost library and users have time to migrate, then please don't remove. > > Regards, > Testuya
[dpdk-dev] [PATCH] ixgbe: change logging for ixgbe tx code path selection
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Tuesday, October 27, 2015 12:13 PM
> To: Richardson, Bruce; Traynor, Kevin
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] ixgbe: change logging for ixgbe tx code path
> selection
>
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> > Sent: Tuesday, October 27, 2015 11:50 AM
> > To: Traynor, Kevin
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] ixgbe: change logging for ixgbe tx code
> path selection
> >
> > On Tue, Oct 27, 2015 at 11:41:08AM +, Kevin Traynor wrote:
> > > Simple and vector are different tx code paths. If vector
> > > is selected, change logging from:
> > > PMD: ixgbe_set_tx_function(): Using simple tx code path
> > > PMD: ixgbe_set_tx_function(): Vector tx enabled.
> > >
> > > to:
> > > PMD: ixgbe_set_tx_function(): Using vector tx code path
> > >
> > > or, if simple selected:
> > > PMD: ixgbe_set_tx_function(): Using simple tx code path
> > >
> > > The dangling else in the #ifdef makes readability difficult,
> > > so resolving in way that seems most readable.
> > >
> > > Signed-off-by: Kevin Traynor
> > > ---
> > > drivers/net/ixgbe/ixgbe_rxtx.c |8 +---
> > > 1 files changed, 5 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c
> b/drivers/net/ixgbe/ixgbe_rxtx.c
> > > index a598a72..11d7feb 100644
> > > --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> > > +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> > > @@ -1963,16 +1963,18 @@ ixgbe_set_tx_function(struct rte_eth_dev *dev,
> struct ixgbe_tx_queue *txq)
> > > /* Use a simple Tx queue (no offloads, no multi segs) if possible */
> > > if (((txq->txq_flags & IXGBE_SIMPLE_FLAGS) == IXGBE_SIMPLE_FLAGS)
> > > && (txq->tx_rs_thresh >= RTE_PMD_IXGBE_TX_MAX_BURST)) {
> > > - PMD_INIT_LOG(DEBUG, "Using simple tx code path");
> > > #ifdef RTE_IXGBE_INC_VECTOR
> > > if (txq->tx_rs_thresh <= RTE_IXGBE_TX_MAX_FREE_BUF_SZ &&
> > > (rte_eal_process_type() != RTE_PROC_PRIMARY ||
> > > ixgbe_txq_vec_setup(txq) == 0)) {
> > > - PMD_INIT_LOG(DEBUG, "Vector tx enabled.");
> > > + PMD_INIT_LOG(DEBUG, "Using vector tx code path");
> > > dev->tx_pkt_burst = ixgbe_xmit_pkts_vec;
> > > } else
> > > #endif
> > > - dev->tx_pkt_burst = ixgbe_xmit_pkts_simple;
> > > + {
> > > + PMD_INIT_LOG(DEBUG, "Using simple tx code path");
> > > + dev->tx_pkt_burst = ixgbe_xmit_pkts_simple;
> > > + }
> > > } else {
> > > PMD_INIT_LOG(DEBUG, "Using full-featured tx code path");
> > > PMD_INIT_LOG(DEBUG,
> > > --
> > > 1.7.4.1
> > >
> > Hi Kevin,
> >
> > can I suggest a slight alternative here that might help make things easier.
> > Instead of printing the message as we pick the code path, why not have a
> "logmsg"
> > pointer variable that is assigned in the code, and then print out the log
> path
> > at the end.
> >
> > This would have a number of advantages:
> > 1. there are no issues with changing our mind, so we can assign one path
> type,
> > and then later change it to something different without cluttering up the
> debug
> > output with the history of our code's flow.
> > 2. it means that you don't have a problem with smaller else legs as you can
> > easily do multiple assignments in the one line using a comma as:
> > dev->tx_pkt_burst = ixgbe_xmit_pkts_simple, logmsg = "Using simple
> ...";
>
> While I like approach with logmsg, please avoid commas here.
> It will make this peace of code even more hard to read (at least for me).
> Konstantin
yeah, sure. I agree with changing for 1. I also agree with Konstantin re commas.
The code under the dangling else is aligned incorrectly/correctly depending on
whether the #ifdef is true or not, so I think adding multiple statements with {}
now will make it obvious for the next person who modifies.
>
> >
> > Regards,
> > /Bruce
[dpdk-dev] [PATCH v3 0/2] i40e: Enlarge the number of supported queues
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Helin Zhang > Sent: Tuesday, November 3, 2015 3:40 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v3 0/2] i40e: Enlarge the number of supported > queues > > It enlarges the number of supported queues to hardware allowed maximum. There > was a software limitation of 64 per physical port which is not reasonable. Hi Helin, Is the layout of the queues and how CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF affects them documented? I'm wondering if I increase CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF to more than 64 queue, will they be contiguous? For example, if I increase to 128 will I be able to use queues 0-127, or there will there be gaps for queues reserved for VMDQ etc. Kevin. > > v2 changes: > Fixed issues of using wrong configured number of VF queues. > > v3 changes: > Updated release notes. > > Helin Zhang (2): > i40e: adjust the number of queues for RSS > i40e: Enlarge the number of supported queues > > config/common_bsdapp | 3 +- > config/common_linuxapp | 3 +- > doc/guides/rel_notes/deprecation.rst | 5 -- > doc/guides/rel_notes/release_2_2.rst | 12 +++ > drivers/net/i40e/i40e_ethdev.c | 146 +++-- > -- > drivers/net/i40e/i40e_ethdev.h | 8 ++ > drivers/net/i40e/i40e_ethdev_vf.c| 2 +- > 7 files changed, 86 insertions(+), 93 deletions(-) > > -- > 1.9.3
[dpdk-dev] Fwd: OVS with DPDK ..Error packets
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Srikanth Akula
> Sent: Wednesday, July 29, 2015 10:32 PM
> To: dev at dpdk.org; dev at openvswitch.org
> Subject: [dpdk-dev] Fwd: OVS with DPDK ..Error packets
>
> (+DPDK dev team )
>
>
> Hello ,
>
> I am trying to test the OVS_DPDK performance and found that lot of packets
> being treated as error packets .
>
> ovs-vsctl get Interface dpdk0 statistics
> {collisions=0, rx_bytes=38915076374, rx_crc_err=0, rx_dropped=0,
> *rx_errors=3840287219
> <3840287219>, *rx_frame_err=0, rx_over_err=0, rx_packets=292972799,
> tx_bytes=38935883904, tx_dropped=0, tx_errors=0, tx_packets=293068162}
>
> I am running DPDK application inside my VM .
>
> Looks like there is a buffer issue ( 64Bytes - 10Gbps)
>
> Could somebody let me know if i have missed any configuration in DPDK/OVS ?
Errors can show here when you are sending traffic in at a rate higher than can
be handled, so it can be normal to see that in some cases.
First thing I would check is that you have your PMD(s) and qemu threads doing
the fwding core affinitised to different cores so they get the max amount of
cycles they can.
I would also check a simple phy-phy test to eliminate any test equipment/NIC
setup issues.
>
> -Srikanth
[dpdk-dev] [PATCH v2 1/5] mem: add --single-file to create single mem-backed file
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Tuesday, March 8, 2016 10:31 AM > To: dev at dpdk.org > Cc: nakajima.yoshihiro at lab.ntt.co.jp; mst at redhat.com; p.fedin at > samsung.com; > ann.zhuangyanying at huawei.com > Subject: Re: [dpdk-dev] [PATCH v2 1/5] mem: add --single-file to create > single mem-backed file > > 2016-03-08 17:04, Yuanhan Liu: > > On Tue, Mar 08, 2016 at 10:49:30AM +0200, Panu Matilainen wrote: > > > On 03/07/2016 03:13 PM, Yuanhan Liu wrote: > > > >To me, maybe you could base the SINGLE_FILE_SEGMENTS option, and add > > > >another option, say --no-sort (I confess this name sucks, but you get > > > >my point). With that, we could make sure to create as least huge page > > > >files as possible, to fit your case. > > > > > > Note that SINGLE_FILE_SEGMENTS is a nasty hack that only the IVSHMEM > config > > > uses, getting rid of it (by replacing with a runtime switch) would be > great. > > > > Can't agree more. > > +1 > > > BTW, FYI, Jianfeng and I had a private talk, and we came to agree that > > it might be better to handle it outside the normal huge page init stage, > > just like this patch does, but adding the support of multiple huge page > > sizes. Let's not add more messy code there. > > > > --yliu > > > > > OTOH IVSHMEM itself seems to have fallen out of the fashion since the > memnic > > > driver is unmaintained and broken since dpdk 2.0... CC'ing the IVSHMEM > > > maintainer in case he has thoughts on this. > > The ivshmem config was not used for memnic which was using ivshmem only for > data path. > CONFIG_RTE_LIBRTE_IVSHMEM and CONFIG_RTE_EAL_SINGLE_FILE_SEGMENTS are more > about full memory sharing. > I have the feeling it could be dropped. > It there are some users, I'd like to see a justification and a rework to > remove these build options. Just to clarify - is this suggesting the removal of the IVSHMEM library itself, or just some of the config options? The reason I ask is that although we don't currently use it in OVS with DPDK, I've seen at least one person using it in conjunction with the ring interface. There may be others, so I want to cross-post if there's a deprecation discussion. Kevin.
[dpdk-dev] [PATCH v2 1/5] mem: add --single-file to create single mem-backed file
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Monday, March 14, 2016 2:45 PM > To: Traynor, Kevin > Cc: dev at dpdk.org; nakajima.yoshihiro at lab.ntt.co.jp; mst at redhat.com; > p.fedin at samsung.com; ann.zhuangyanying at huawei.com > Subject: Re: [dpdk-dev] [PATCH v2 1/5] mem: add --single-file to create > single mem-backed file > > 2016-03-14 13:53, Traynor, Kevin: > > From: Thomas Monjalon > > > 2016-03-08 17:04, Yuanhan Liu: > > > > On Tue, Mar 08, 2016 at 10:49:30AM +0200, Panu Matilainen wrote: > > > > > On 03/07/2016 03:13 PM, Yuanhan Liu wrote: > > > > > Note that SINGLE_FILE_SEGMENTS is a nasty hack that only the IVSHMEM > > > config > > > > > uses, getting rid of it (by replacing with a runtime switch) would be > > > great. > > > > > > > > Can't agree more. > > > > > > +1 > > > > > > > > OTOH IVSHMEM itself seems to have fallen out of the fashion since the > > > memnic > > > > > driver is unmaintained and broken since dpdk 2.0... CC'ing the > IVSHMEM > > > > > maintainer in case he has thoughts on this. > > > > > > The ivshmem config was not used for memnic which was using ivshmem only > for > > > data path. > > > CONFIG_RTE_LIBRTE_IVSHMEM and CONFIG_RTE_EAL_SINGLE_FILE_SEGMENTS are > more > > > about full memory sharing. > > > I have the feeling it could be dropped. > > > It there are some users, I'd like to see a justification and a rework to > > > remove these build options. > > > > Just to clarify - is this suggesting the removal of the IVSHMEM library > itself, > > or just some of the config options? > > I have no strong opinion about the library. > About the config options, yes they should be removed. Note that they are not > documented, so we don't really know the motivation to have them. ok, thanks for clarifying. As there's no imminent plans to remove the library, I won't cross post. > > > The reason I ask is that although we don't currently use it in OVS with > DPDK, > > I've seen at least one person using it in conjunction with the ring > interface. > > There may be others, so I want to cross-post if there's a deprecation > discussion. > > Thank you for sharing.
[dpdk-dev] [ovs-dev] [PATCH v3 1/3] netdev-dpdk: Remove dpdk watchdog thread
[cross-posting to dpdk mailing list]
> -Original Message-
> From: Torgny Lindberg [mailto:torgny.lindberg at ericsson.com]
> Sent: Thursday, May 19, 2016 8:26 AM
> To: Traynor, Kevin ; Loftus, Ciara
> ; dev at openvswitch.org
> Subject: RE: [ovs-dev] [PATCH v3 1/3] netdev-dpdk: Remove dpdk
> watchdog thread
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at openvswitch.org] On Behalf Of Traynor,
> > Kevin
> > Sent: den 13 maj 2016 12:47
> > To: Loftus, Ciara; dev at openvswitch.org
> > Subject: Re: [ovs-dev] [PATCH v3 1/3] netdev-dpdk: Remove dpdk
> watchdog
> > thread
> >
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at openvswitch.org] On Behalf Of Ciara
> > > Loftus
> > > Sent: Wednesday, May 11, 2016 4:31 PM
> > > To: dev at openvswitch.org
> > > Subject: [ovs-dev] [PATCH v3 1/3] netdev-dpdk: Remove dpdk
> watchdog
> > > thread
> > >
> > > Instead of continuously polling for link status changes on 'dpdk'
> > > ports, register a callback function that will be triggered when
> DPDK
> > > detects that the link status of that port has changed.
> >
> > rte_eth_link_get_nowait() returns void, so polling it in a thread
> won't
> > indicate some kind of error in dpdk. I can't see any benefit of the
> thread
> > - using the callback means one less thread and less locking.
> >
> > Acked-by: Kevin Traynor
> >
>
>
> With this patch a 4s delay before detecting link-down would be
> introduced,
> which is from the viewpoint of many use cases an unacceptably long
> delay.
> I would like to suggest that the existing poll method is kept as it
> detects
> and acts on link failures much faster (millisecond time scale),
> alternatively that both poll and interrupt methods are supported
> and the one to use is selected by configuration.
>
> The delay occurs inside the dpdk driver.
> (See e.g. dpdk, ixgbe_ethdev.c, IXGBE_LINK_DOWN_CHECK_TIMEOUT)
>
Hi Torgny,
Thanks for pointing that out, I hadn't realized the additional delay.
Do you think the default should be changed in DPDK?
Kevin.
>
> Best regards,
> Torgny Lindberg
>
>
> > >
> > > Signed-off-by: Ciara Loftus
> > > Suggested-by: Kevin Traynor
> > > ---
> > > lib/netdev-dpdk.c | 55 ++
> ---
> > -
> > > -
> > > 1 file changed, 30 insertions(+), 25 deletions(-)
> > >
> > > diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> > > index af86d19..89d783a 100644
> > > --- a/lib/netdev-dpdk.c
> > > +++ b/lib/netdev-dpdk.c
> > > @@ -62,8 +62,6 @@
> > > VLOG_DEFINE_THIS_MODULE(dpdk);
> > > static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 20);
> > >
> > > -#define DPDK_PORT_WATCHDOG_INTERVAL 5
> > > -
> > > #define OVS_CACHE_LINE_SIZE CACHE_LINE_SIZE
> > > #define OVS_VPORT_DPDK "ovs_dpdk"
> > >
> > > @@ -386,6 +384,9 @@ static int netdev_dpdk_construct(struct netdev
> *);
> > >
> > > struct virtio_net * netdev_dpdk_get_virtio(const struct
> netdev_dpdk
> > > *dev);
> > >
> > > +void link_status_changed_callback(uint8_t port_id,
> > > +enum rte_eth_event_type type OVS_UNUSED, void *param
> > > OVS_UNUSED);
> > > +
> > > static bool
> > > is_dpdk_class(const struct netdev_class *class)
> > > {
> > > @@ -536,27 +537,6 @@ check_link_status(struct netdev_dpdk *dev)
> > > }
> > > }
> > >
> > > -static void *
> > > -dpdk_watchdog(void *dummy OVS_UNUSED)
> > > -{
> > > -struct netdev_dpdk *dev;
> > > -
> > > -pthread_detach(pthread_self());
> > > -
> > > -for (;;) {
> > > -ovs_mutex_lock(&dpdk_mutex);
> > > -LIST_FOR_EACH (dev, list_node, &dpdk_list) {
> > > -ovs_mutex_lock(&dev->mutex);
> > > -check_link_status(dev);
> > > -ovs_mutex_unlock(&dev->mutex);
> > > -}
> > > -ovs_mutex_unlock(&dpdk_mutex);
> > > -xsleep(DPDK_PORT_WATCHDOG_INTERVAL);
> > > -}
> > > -
> > > -return NULL;
> > > -}
> > > -
> > > static int
> > > dpdk_eth_dev_queue_setup(struct netdev_dpdk *dev, int n_rxq, int
> > > n_txq)
> > > {
> > > @@ -717,6
[dpdk-dev] Crashing OVS+DPDK at the host, from inside of a KVM Guest
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Christian > Ehrhardt > Sent: Wednesday, May 25, 2016 7:06 AM > To: Martinx - ? > Cc: ; dev > Subject: Re: [dpdk-dev] Crashing OVS+DPDK at the host, from inside of > a KVM Guest > > Hi, > ping ... > > Later on I want to look at it again once we upgraded to more recent > releases of the software components involved, but those have to be > made > ready to use first :-/ > > But the description is good and I wonder if anybody else could > reproduce > this and/or would have a hint on where this might come from or already > existing related fixes. > > I mean in general nothing should be able to crash the host right? Hi, I don't know if they are related to the issue that is being seen, but Yuanhan made some fixes in DPDK 16.04 regarding a malicious guest affecting the host. rte_vhost_dequeue_burst() is showing in the stack trace so it might worth testing with the latest code to see if it's the same issue and has been fixed. Kevin. > > > P.S. yeah two list cross posting, but it is yet unclear which it > belongs to > so I'll keep it > > Christian Ehrhardt > Software Engineer, Ubuntu Server > Canonical Ltd > > On Sun, May 15, 2016 at 7:08 AM, Martinx - ? > > wrote: > > > Guys, > > > > If using OVS 2.5 with DPDK 2.2, on Ubuntu Xenial, it is possible to > crash > > the OVS running at the host, from inside of a KVM Guest. > > > > Basically, what I'm trying to do, is to run OVS+DPDK at the host, > and > > also, inside of a KVM Guest, with multi-queue, but it doesn't work > and > > crashes. > > > > Soon as you enable multi-queue at the guest, it crashes the OVS of > the > > host! > > > > OVS+DPDK segfault at the host, after running "ovs-vsctl set > Open_vSwitch . > > other_config:n-dpdk-rxqs=4" within a KVM Guest: > > > > https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/1577088 > > > > Thanks! > > Thiago > >
[dpdk-dev] DPDK with Openvswitch Compatibility issue
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Sundar Ramakrishnan > Sent: Monday, June 22, 2015 7:36 PM > To: dev at dpdk.org > Subject: [dpdk-dev] DPDK with Openvswitch Compatibility issue > > Hello, > I have trying to compile and install openvswitch with dpdk. I have tried > dpdk-1.7.0 through dpdk-2.0.0 with openvswitch-2.0.0 through openvswitch- > 2.3.2. I have been following these two guides - > http://openvswitch.org/support/dist-docs/INSTALL.DPDK.md.txt Probably best to switch to the ovs-discuss mailing list for this as it doesn't look like a DPDK issue. I suggest using use the head of master for OVS with DPDK 2.0.0 and stepping through the INSTALL.DPDK.md then. > > Intel? Data Plane Development Kit for Linux*: Guide > > | ? | > | ? | | ? | ? | ? | ? | ? | > | Intel? Data Plane Development Kit for Linux*: GuideGetting Started Guide: > Describes how to install and configure the Intel? Data Plane Development Kit > for Linux*. (v.7, Jun. 2014) | > | | > | View on www.intel.com | Preview by Yahoo | > | | > | ? | > > > Currently this is what my error message says - > /bin/sh /root/openvswitch-2.0.0/build-aux/missing --run autom4te -- > language=autotest -I '.' -o tests/testsuite.tmp > tests/testsuite.attests/testsuite.at:56: error: possibly undefined macro: > dnl? ? ? If this token and others are legitimate, please use > m4_pattern_allow.? ? ? See the Autoconf > documentation.tests/testsuite.tmp:15559: error: possibly undefined macro: > AT_FAIL_IFtests/testsuite.tmp:17108: error: possibly undefined macro: > AT_SKIP_IFtests/testsuite.tmp:18411: error: possibly undefined macro: > AT_CHECK_UNQUOTEDtests/testsuite.tmp:104490: error: possibly undefined macro: > AS_VAR_COPY > > Any help or pointers will be appreciated. > I am using RHEL 6.6. > ThanksSundar
