[dpdk-dev] [dpdk-announce] Pktgen-DPDK updated to version 2.8.3
Hi Everyone, I have updated Pktgen to work with DPDK 2.0.0-rc1, but will require a patch to enable the correct build system changes. Please find the patch here for DPDK, until the patch has be integrated or resolved. http://patchwork.dpdk.org/dev/patchwork/patch/3799/ Pktgen-DPDK is a ASCII screen (VT100) traffic generator using DPDK. Does not require a complex setup or other packages other then DPDK. Please see the README.md file for more details or http://pktgen.readthedocs.org/en/latest/ http://patchwork.dpdk.org/browse/apps/pktgen-dpdk/refs/ Regards, ++Keith
[dpdk-dev] Error seen while compiling Pktgen-dpdk
On 2/28/15, 8:00 AM, "Neil Horman" wrote: >On Sat, Feb 28, 2015 at 01:06:32PM +0530, Shankari Vaidyalingam wrote: >> Hi, >> >> I'm facing the below error while executing make on Pktgen-dpdk source. >> I'm using 2.8 version of pktgen downloaded >> I have built DPDK binaries and then tried building pktgen-dpdk. >> RTE_TARGET is set to x86_64-pktgen-linuxapp-gcc and RTE_SDK is set to >>the >> directory where dpdk source files are present. >> DPDK version - 1.7.1 >> Please let me know how to resolve this error. >> >> controller at controller-VirtualBox:~/pktgen-2.8.0$ sudo >> RTE_SDK=/home/controller/dpdk-1.7.1 make >> make -C lib >> make[1]: Entering directory `/home/controller/pktgen-2.8.0/lib' >> == common >> == lua >> == src >> make[1]: Leaving directory `/home/controller/pktgen-2.8.0/lib' >> make -C app >> make[1]: Entering directory `/home/controller/pktgen-2.8.0/app' >> CC lpktgenlib.o >> lpktgenlib.c: In function ?getf_etheraddr?: >> lpktgenlib.c:174:9: error: passing argument 1 of >>?cmdline_parse_etheraddr? >> from incompatible pointer type [-Werror] >> >>/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_pa >>rse_etheraddr.h:75:5: >> note: expected ?struct cmdline_parse_token_hdr_t *? but argument is of >>type >> ?struct cmdline_etheraddr_t *? >> lpktgenlib.c: In function ?getf_ipaddr?: >> lpktgenlib.c:185:6: error: too many arguments to function >> ?cmdline_parse_ipaddr? >> >>/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_pa >>rse_ipaddr.h:94:5: >> note: declared here >> lpktgenlib.c: In function ?pktgen_set?: >> lpktgenlib.c:233:2: error: too many arguments to function >> ?cmdline_parse_portlist? >> >>/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_pa >>rse_portlist.h:83:5: >> note: declared here >> lpktgenlib.c: In function ?set_seq?: >> lpktgenlib.c:290:2: error: too many arguments to function >> ?cmdline_parse_portlist? >> >>/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_pa >>rse_portlist.h:83:5: >> note: declared here >> lpktgenlib.c:291:3: error: too many arguments to function >> ?cmdline_parse_etheraddr? >> >>/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_pa >>rse_etheraddr.h:75:5: >> note: declared here >> lpktgenlib.c:292:3: error: too many arguments to function >> ?cmdline_parse_etheraddr? >> >>/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_pa >>rse_etheraddr.h:75:5: >> note: declared here >> lpktgenlib.c:295:7: error: too many arguments to function >> ?cmdline_parse_ipaddr? >> >>/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_pa >>rse_ipaddr.h:94:5: >> note: declared here >> lpktgenlib.c:298:7: error: too many arguments to function >> ?cmdline_parse_ipaddr? >> >>/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_pa >>rse_ipaddr.h:94:5: >> note: declared here >> lpktgenlib.c: In function ?set_seqTable?: >> lpktgenlib.c:370:2: error: too many arguments to function >> ?cmdline_parse_portlist? >> >>/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_pa >>rse_portlist.h:83:5: >> note: declared here >> lpktgenlib.c: In function ?pktgen_icmp?: >> lpktgenlib.c:466:2: error: too many arguments to function >> ?cmdline_parse_portlist? >> >>/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_pa >>rse_portlist.h:83:5: >> note: declared here >> lpktgenlib.c: In function ?pktgen_sendARP?: >> lpktgenlib.c:494:2: error: too many arguments to function >> ?cmdline_parse_portlist? >> >>/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_pa >>rse_portlist.h:83:5: >> note: declared here >> lpktgenlib.c: In function ?pktgen_set_mac?: >> lpktgenlib.c:521:2: error: too many arguments to function >> ?cmdline_parse_portlist? >> >>/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_pa >>rse_portlist.h:83:5: >> note: declared here >> lpktgenlib.c:522:2: error: too many arguments to function >> ?cmdline_parse_etheraddr? >> >>/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_pa >>rse_etheraddr.h:75:5: >> note: declared here >> lpktgenlib.c: In function ?pktgen_prototype?: >> lpktgenlib.c:582:2: error: too many arguments to function >> ?cmdline_parse_portlist? >> >>/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_pa >>rse_portlist.h:83:5: >> note: declared here >> lpktgenlib.c: In function ?pktgen_set_ip_addr?: >> lpktgenlib.c:615:2: error: too many arguments to function >> ?cmdline_parse_portlist? >> >>/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_pa >>rse_portlist.h:83:5: >> note: declared here >> lpktgenlib.c:619:2: error: too many arguments to function >> ?cmdline_parse_ipaddr? >> >>/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_pa >>rse_ipaddr.h:94:5: >> note: declared here >> lpktgenlib.c: In function ?pktgen_set_type?: >> lpktgenlib.c:650:2:
[dpdk-dev] Error seen while compiling Pktgen-dpdk
On 2/28/15, 1:36 AM, "Shankari Vaidyalingam" wrote: >Hi, > >I'm facing the below error while executing make on Pktgen-dpdk source. >I'm using 2.8 version of pktgen downloaded >I have built DPDK binaries and then tried building pktgen-dpdk. >RTE_TARGET is set to x86_64-pktgen-linuxapp-gcc and RTE_SDK is set to the >directory where dpdk source files are present. >DPDK version - 1.7.1 >Please let me know how to resolve this error. It also appears you are using DPDK 1.7.1 and Pktgen 2.8.0 needs DPDK 1.8.x to work. I did not look at which version of Pktgen would work with DPDK 1.7.1, but please look at trying a previous version of Pktgen. I am currently working on getting a new version of Pktgen pushed to the repo and should be in sync with 2.0.0-rc1. Thanks ++Keith > >controller at controller-VirtualBox:~/pktgen-2.8.0$ sudo >RTE_SDK=/home/controller/dpdk-1.7.1 make >make -C lib >make[1]: Entering directory `/home/controller/pktgen-2.8.0/lib' >== common >== lua >== src >make[1]: Leaving directory `/home/controller/pktgen-2.8.0/lib' >make -C app >make[1]: Entering directory `/home/controller/pktgen-2.8.0/app' > CC lpktgenlib.o >lpktgenlib.c: In function ?getf_etheraddr?: >lpktgenlib.c:174:9: error: passing argument 1 of ?cmdline_parse_etheraddr? >from incompatible pointer type [-Werror] >/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_par >se_etheraddr.h:75:5: >note: expected ?struct cmdline_parse_token_hdr_t *? but argument is of >type >?struct cmdline_etheraddr_t *? >lpktgenlib.c: In function ?getf_ipaddr?: >lpktgenlib.c:185:6: error: too many arguments to function >?cmdline_parse_ipaddr? >/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_par >se_ipaddr.h:94:5: >note: declared here >lpktgenlib.c: In function ?pktgen_set?: >lpktgenlib.c:233:2: error: too many arguments to function >?cmdline_parse_portlist? >/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_par >se_portlist.h:83:5: >note: declared here >lpktgenlib.c: In function ?set_seq?: >lpktgenlib.c:290:2: error: too many arguments to function >?cmdline_parse_portlist? >/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_par >se_portlist.h:83:5: >note: declared here >lpktgenlib.c:291:3: error: too many arguments to function >?cmdline_parse_etheraddr? >/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_par >se_etheraddr.h:75:5: >note: declared here >lpktgenlib.c:292:3: error: too many arguments to function >?cmdline_parse_etheraddr? >/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_par >se_etheraddr.h:75:5: >note: declared here >lpktgenlib.c:295:7: error: too many arguments to function >?cmdline_parse_ipaddr? >/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_par >se_ipaddr.h:94:5: >note: declared here >lpktgenlib.c:298:7: error: too many arguments to function >?cmdline_parse_ipaddr? >/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_par >se_ipaddr.h:94:5: >note: declared here >lpktgenlib.c: In function ?set_seqTable?: >lpktgenlib.c:370:2: error: too many arguments to function >?cmdline_parse_portlist? >/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_par >se_portlist.h:83:5: >note: declared here >lpktgenlib.c: In function ?pktgen_icmp?: >lpktgenlib.c:466:2: error: too many arguments to function >?cmdline_parse_portlist? >/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_par >se_portlist.h:83:5: >note: declared here >lpktgenlib.c: In function ?pktgen_sendARP?: >lpktgenlib.c:494:2: error: too many arguments to function >?cmdline_parse_portlist? >/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_par >se_portlist.h:83:5: >note: declared here >lpktgenlib.c: In function ?pktgen_set_mac?: >lpktgenlib.c:521:2: error: too many arguments to function >?cmdline_parse_portlist? >/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_par >se_portlist.h:83:5: >note: declared here >lpktgenlib.c:522:2: error: too many arguments to function >?cmdline_parse_etheraddr? >/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_par >se_etheraddr.h:75:5: >note: declared here >lpktgenlib.c: In function ?pktgen_prototype?: >lpktgenlib.c:582:2: error: too many arguments to function >?cmdline_parse_portlist? >/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_par >se_portlist.h:83:5: >note: declared here >lpktgenlib.c: In function ?pktgen_set_ip_addr?: >lpktgenlib.c:615:2: error: too many arguments to function >?cmdline_parse_portlist? >/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_par >se_portlist.h:83:5: >note: declared here >lpktgenlib.c:619:2: error: too many arguments to function >?cmdline_parse_ipaddr? >/home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_par >se_ipaddr.h:94:5: >note: declared here >lpktgenlib.c: In function ?pktgen_set_type?:
[dpdk-dev] [PATCH v6 8/8] l3fwd-power: enable one-shot rx interrupt and polling/interrupt mode switch
On Fri, 27 Feb 2015 12:56:16 +0800
Cunming Liang wrote:
> +/* ethernet addresses of ports */
> +static rte_spinlock_t locks[RTE_MAX_ETHPORTS];
Comment is incorrect this is a lock array not an address array.
> static struct rte_eth_conf port_conf = {
> .rxmode = {
> - .mq_mode= ETH_MQ_RX_RSS,
> + .mq_mode = ETH_MQ_RX_RSS,
Please don't mix white space changes with code changes
[dpdk-dev] [PATCH v6 8/8] l3fwd-power: enable one-shot rx interrupt and polling/interrupt mode switch
On Fri, 27 Feb 2015 12:56:16 +0800 Cunming Liang wrote: > + /* Enable one-shot rx interrupt */ > + rte_spinlock_lock(&(locks[port_id])); > + rte_eth_dev_rx_intr_enable(port_id, queue_id); > + rte_spinlock_unlock(&(locks[port_id])); > + If always requires locks like this, then the API should do the locking internally.
[dpdk-dev] KNI with multiple kthreads per port
Howdy! First time posting; please be gentle. :-) Environment: * DPDK 1.8.0 release * Linux kernel 3.0.3x-ish * 32-bit (yes, KNI works fine, after a few tweaks hugepage init strategy) I'm trying to use the KNI example app with a configuration where multiple kthreads are created for a physical port. Per the user guide and code, the first such kthread is the "master", any the only one configurable; I'll refer to the additional kthread(s) as "slaves", although their relationship to the master kthread isn't discussed anywhere that I've looked thus far. # insmod rte_kni.ko kthread_mode=multiple # kni [] --config="(0,0,1,2,3)" # ifconfig vEth0_0 10.0.0.1 netmask 255.255.255.0 >From the above: PMD-bound physical port0. Rx/Tx on cores 0 and 1, respectively. Master thread on core 2, one slave kthread on core 3. Upon startup, KNI devices vEth0_0 (master) and vEth0_1 (slave) are created. After ifconfig, vEth0_0 works fine; by design, vEth0_1 cannot be configured. The problem I'm encountering is that the subset of packets hitting vEth0_1 are being dropped... somewhere. They're definitely getting as far as the call to netif_rx(skb). I'll try on a newer system for comparison. But before I go too much further, I'd like to establish the correct set-up and expectations. Should I be bonding vEth0_0 and vEth0_1? Because I tried doing so (via sysfs); however, attempts to add either as slaves to bond0 were ignored. Any ideas appreciated. (Though it may end up being a moot point, with the other work this past week on KNI performance.)
[dpdk-dev] [PATCH v6 0/8] Interrupt mode PMD
On Fri, 27 Feb 2015 11:38:25 +0100 David Marchand wrote: > On Fri, Feb 27, 2015 at 5:56 AM, Cunming Liang > wrote: > v6 changes > ?- split rte_intr_wait_rx_pkt into two APIs 'wait' and 'set'. > ?- rewrite rte_intr_rx_wait/rte_intr_rx_set. > ?- using vector number instead of queue_id as interrupt API params. > ?- patch reorder and split. > > > Ok, so after looking at this patchset, I would say this is the right > direction, but still this is too limited. > The ethdev part and the vfio eventfds part look acceptable to me. > But thinking about it, I could just reuse a standard event library with the > eventfds I would get from ethdev without a need for a new eal api. Also, you need to introduce a flag (in pci drv_flags?) so that application can know if poll mode interrupt will work or not on the given device before configuring it.
[dpdk-dev] Why only rx queue "0" can receive network packet by i40e NIC
Good to know that!
> -Original Message-
> From: lhffjzh [mailto:lhffjzh at 126.com]
> Sent: Saturday, February 28, 2015 12:34 PM
> To: Zhang, Helin; 'Thomas Monjalon'
> Cc: dev at dpdk.org; maintainers at dpdk.org
> Subject: RE: [dpdk-dev] Why only rx queue "0" can receive network packet by
> i40e NIC
>
> Hi Helin,
>
> Thanks a lot for your great help, all of rx queue received network packet
> after I
> update rss_hf from "ETH_RSS_IP" to " ETH_RSS_PROTO_MASK ".
>
> static struct rte_eth_conf port_conf = {
> .rxmode = {
> .mq_mode= ETH_MQ_RX_RSS,
> .max_rx_pkt_len = ETHER_MAX_LEN,
> .split_hdr_size = 0,
> .header_split = 0, /**< Header Split disabled */
> .hw_ip_checksum = 1, /**< IP checksum offload enabled */
> .hw_vlan_filter = 0, /**< VLAN filtering disabled */
> .jumbo_frame= 0, /**< Jumbo Frame Support disabled */
> .hw_strip_crc = 0, /**< CRC stripped by hardware */
> },
> .rx_adv_conf = {
> .rss_conf = {
> .rss_key = NULL,
> .rss_hf = ETH_RSS_PROTO_MASK,
> },
> },
> .txmode = {
> .mq_mode = ETH_MQ_TX_NONE,
> },
> .fdir_conf.mode = RTE_FDIR_MODE_SIGNATURE, };
>
>
> Regards,
> Haifeng
>
> -Original Message-
> From: Zhang, Helin [mailto:helin.zhang at intel.com]
> Sent: Saturday, February 28, 2015 11:18 AM
> To: lhffjzh; 'Thomas Monjalon'
> Cc: dev at dpdk.org; maintainers at dpdk.org
> Subject: RE: [dpdk-dev] Why only rx queue "0" can receive network packet by
> i40e NIC
>
> Hi Haifeng
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of lhffjzh
> > Sent: Saturday, February 28, 2015 9:48 AM
> > To: 'Thomas Monjalon'
> > Cc: dev at dpdk.org; maintainers at dpdk.org
> > Subject: Re: [dpdk-dev] Why only rx queue "0" can receive network
> > packet
> by
> > i40e NIC
> >
> > Hi Thomas,
> >
> > Thanks very much for your reminder, you give me many help in this mail
> list.
> >
> > The issue with detailed information just as below. but I don't know
> > who is
> the
> > dpdk i40e maintainers? is maintainers at dpdk.org?
> >
> > Hardware list:
> > 2 i40e 40G NICs
> > Xeon E5-2670 v2(10 cores)
> > 32G memory
> >
> > I loopback 2 i40e NICs by QSFP cable, one NIC send UDP network packet
> > by DPDK, and another for receiving. I bind 4 processor's logical cores
> > with 4
> rx
> > queue "0,1,2,3" on receiving NIC, when I start to send packet, only rx
> queue
> > "0"
> > can receive
> > the UDP packet, the others queue always receive nothing. but it is
> > work
> well on
> > ixgbe 10G NICs, I can receive network packet from all rx queues. does
> anyone
> > kindly know why?
> Could you help to list the DPDK version you are using now?
> Two possible reasons:
> 1. UDP rss is not enabled on your board correctly.
> I40e has different rss flags from ixgbe, so I am wondering if you use it
> correctly.
> In addition, this will be unified from 2.0. So I care about the DPDK
> version.
> 2. The UDP stream is occasionally hit the hash key of queue 0.
> You'd better to try to send your UDP stream with random 5-tuples, to get
> the
> hash value hit different queues randomly.
>
> Regards,
> Helin
>
> >
> >
> > Regards,
> > Haifeng
> >
> > -Original Message-
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Friday, February 27, 2015 6:55 PM
> > To: lhffjzh
> > Cc: dev at dpdk.org
> > Subject: Re: Why only rx queue "0" can receive network packet by i40e
> > NIC
> >
> > 2015-02-27 16:47, lhffjzh:
> > > Hi All,
> > >
> > > We use 4 cores loop 4 rx queues on one i40e port, but only rx queue "0"
> > can
> > > receive network packet, do anyone kindly know why? BTW, all of
> > > network packet has same destination ip address but has more than 200
> > > different source ip address.
> >
> > It's possible that you don't have any answer for 2 reasons:
> > - you replied in a thread dedicated to Cisco enic questions
> > - you didn't describe your usage enough to understand your problem
> >
> > I suggest to use the button "new email" instead of "reply all" to
> > start a new question with enough details.
> >
> > Did you noticed you put some Cisco guys in CC instead of putting the
> > Intel responsible for i40e (see MAINTAINERS file)?
> >
>
[dpdk-dev] Error seen while compiling Pktgen-dpdk
Hi, I'm facing the below error while executing make on Pktgen-dpdk source. I'm using 2.8 version of pktgen downloaded I have built DPDK binaries and then tried building pktgen-dpdk. RTE_TARGET is set to x86_64-pktgen-linuxapp-gcc and RTE_SDK is set to the directory where dpdk source files are present. DPDK version - 1.7.1 Please let me know how to resolve this error. controller at controller-VirtualBox:~/pktgen-2.8.0$ sudo RTE_SDK=/home/controller/dpdk-1.7.1 make make -C lib make[1]: Entering directory `/home/controller/pktgen-2.8.0/lib' == common == lua == src make[1]: Leaving directory `/home/controller/pktgen-2.8.0/lib' make -C app make[1]: Entering directory `/home/controller/pktgen-2.8.0/app' CC lpktgenlib.o lpktgenlib.c: In function ?getf_etheraddr?: lpktgenlib.c:174:9: error: passing argument 1 of ?cmdline_parse_etheraddr? from incompatible pointer type [-Werror] /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_etheraddr.h:75:5: note: expected ?struct cmdline_parse_token_hdr_t *? but argument is of type ?struct cmdline_etheraddr_t *? lpktgenlib.c: In function ?getf_ipaddr?: lpktgenlib.c:185:6: error: too many arguments to function ?cmdline_parse_ipaddr? /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_ipaddr.h:94:5: note: declared here lpktgenlib.c: In function ?pktgen_set?: lpktgenlib.c:233:2: error: too many arguments to function ?cmdline_parse_portlist? /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_portlist.h:83:5: note: declared here lpktgenlib.c: In function ?set_seq?: lpktgenlib.c:290:2: error: too many arguments to function ?cmdline_parse_portlist? /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_portlist.h:83:5: note: declared here lpktgenlib.c:291:3: error: too many arguments to function ?cmdline_parse_etheraddr? /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_etheraddr.h:75:5: note: declared here lpktgenlib.c:292:3: error: too many arguments to function ?cmdline_parse_etheraddr? /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_etheraddr.h:75:5: note: declared here lpktgenlib.c:295:7: error: too many arguments to function ?cmdline_parse_ipaddr? /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_ipaddr.h:94:5: note: declared here lpktgenlib.c:298:7: error: too many arguments to function ?cmdline_parse_ipaddr? /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_ipaddr.h:94:5: note: declared here lpktgenlib.c: In function ?set_seqTable?: lpktgenlib.c:370:2: error: too many arguments to function ?cmdline_parse_portlist? /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_portlist.h:83:5: note: declared here lpktgenlib.c: In function ?pktgen_icmp?: lpktgenlib.c:466:2: error: too many arguments to function ?cmdline_parse_portlist? /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_portlist.h:83:5: note: declared here lpktgenlib.c: In function ?pktgen_sendARP?: lpktgenlib.c:494:2: error: too many arguments to function ?cmdline_parse_portlist? /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_portlist.h:83:5: note: declared here lpktgenlib.c: In function ?pktgen_set_mac?: lpktgenlib.c:521:2: error: too many arguments to function ?cmdline_parse_portlist? /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_portlist.h:83:5: note: declared here lpktgenlib.c:522:2: error: too many arguments to function ?cmdline_parse_etheraddr? /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_etheraddr.h:75:5: note: declared here lpktgenlib.c: In function ?pktgen_prototype?: lpktgenlib.c:582:2: error: too many arguments to function ?cmdline_parse_portlist? /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_portlist.h:83:5: note: declared here lpktgenlib.c: In function ?pktgen_set_ip_addr?: lpktgenlib.c:615:2: error: too many arguments to function ?cmdline_parse_portlist? /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_portlist.h:83:5: note: declared here lpktgenlib.c:619:2: error: too many arguments to function ?cmdline_parse_ipaddr? /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_ipaddr.h:94:5: note: declared here lpktgenlib.c: In function ?pktgen_set_type?: lpktgenlib.c:650:2: error: too many arguments to function ?cmdline_parse_portlist? /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_portlist.h:83:5: note: declared here lpktgenlib.c: In function ?pktgen_send_ping4?: lpktgenlib.c:679:2: error: too many arguments to function ?cmdline_parse_portlist? /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_portlist.h:83:5: note: declared here lpktgenlib.c: In function ?pktgen_pcap?: lpktgenlib.c:739:2: error: too many arguments to
[dpdk-dev] Why only rx queue "0" can receive network packet by i40e NIC
Hi Helin,
Thanks a lot for your great help, all of rx queue
received network packet after I update rss_hf
from "ETH_RSS_IP" to " ETH_RSS_PROTO_MASK ".
static struct rte_eth_conf port_conf = {
.rxmode = {
.mq_mode= ETH_MQ_RX_RSS,
.max_rx_pkt_len = ETHER_MAX_LEN,
.split_hdr_size = 0,
.header_split = 0, /**< Header Split disabled */
.hw_ip_checksum = 1, /**< IP checksum offload enabled */
.hw_vlan_filter = 0, /**< VLAN filtering disabled */
.jumbo_frame= 0, /**< Jumbo Frame Support disabled */
.hw_strip_crc = 0, /**< CRC stripped by hardware */
},
.rx_adv_conf = {
.rss_conf = {
.rss_key = NULL,
.rss_hf = ETH_RSS_PROTO_MASK,
},
},
.txmode = {
.mq_mode = ETH_MQ_TX_NONE,
},
.fdir_conf.mode = RTE_FDIR_MODE_SIGNATURE,
};
Regards,
Haifeng
-Original Message-
From: Zhang, Helin [mailto:helin.zh...@intel.com]
Sent: Saturday, February 28, 2015 11:18 AM
To: lhffjzh; 'Thomas Monjalon'
Cc: dev at dpdk.org; maintainers at dpdk.org
Subject: RE: [dpdk-dev] Why only rx queue "0" can receive network packet by
i40e NIC
Hi Haifeng
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of lhffjzh
> Sent: Saturday, February 28, 2015 9:48 AM
> To: 'Thomas Monjalon'
> Cc: dev at dpdk.org; maintainers at dpdk.org
> Subject: Re: [dpdk-dev] Why only rx queue "0" can receive network packet
by
> i40e NIC
>
> Hi Thomas,
>
> Thanks very much for your reminder, you give me many help in this mail
list.
>
> The issue with detailed information just as below. but I don't know who is
the
> dpdk i40e maintainers? is maintainers at dpdk.org?
>
> Hardware list:
> 2 i40e 40G NICs
> Xeon E5-2670 v2(10 cores)
> 32G memory
>
> I loopback 2 i40e NICs by QSFP cable, one NIC send UDP network packet by
> DPDK, and another for receiving. I bind 4 processor's logical cores with 4
rx
> queue "0,1,2,3" on receiving NIC, when I start to send packet, only rx
queue
> "0"
> can receive
> the UDP packet, the others queue always receive nothing. but it is work
well on
> ixgbe 10G NICs, I can receive network packet from all rx queues. does
anyone
> kindly know why?
Could you help to list the DPDK version you are using now?
Two possible reasons:
1. UDP rss is not enabled on your board correctly.
I40e has different rss flags from ixgbe, so I am wondering if you
use it correctly.
In addition, this will be unified from 2.0. So I care about the DPDK
version.
2. The UDP stream is occasionally hit the hash key of queue 0.
You'd better to try to send your UDP stream with random 5-tuples, to
get the
hash value hit different queues randomly.
Regards,
Helin
>
>
> Regards,
> Haifeng
>
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, February 27, 2015 6:55 PM
> To: lhffjzh
> Cc: dev at dpdk.org
> Subject: Re: Why only rx queue "0" can receive network packet by i40e NIC
>
> 2015-02-27 16:47, lhffjzh:
> > Hi All,
> >
> > We use 4 cores loop 4 rx queues on one i40e port, but only rx queue "0"
> can
> > receive network packet, do anyone kindly know why? BTW, all of network
> > packet has same destination ip address but has more than 200 different
> > source ip address.
>
> It's possible that you don't have any answer for 2 reasons:
> - you replied in a thread dedicated to Cisco enic questions
> - you didn't describe your usage enough to understand your problem
>
> I suggest to use the button "new email" instead of "reply all" to
> start a new question with enough details.
>
> Did you noticed you put some Cisco guys in CC instead of putting the
> Intel responsible for i40e (see MAINTAINERS file)?
>
[dpdk-dev] [PATCH] External app builds need to locate common make fragments and includes.
When building an external application like Pktgen and using the proper
makefile fragments rte.extXYZ.mk NOT rte.XYZ.mk files as you would
use with example applications in the same RTE_SDK directory the rte.extXYZ.mk
files are missing some defines/includes.
1 - Add missing tests for RTE_SDK/RTE_TARGET not defined code.
2 - The build of external applications are forced to be verbose ouput
as the Q=@ define is not present.
3 - Missing include of target/generic/rte.vars.mk file which includes
the information to locate the rte_config.h and other DPDK include
files.
A patch like this one was submitted before and was rejected because it
seemed it was not required, because target/generic/rte.vars.mk already
included by rte.vars.mk.
This is not the cause for external applications like Pktgen which are
built outside of the RTE_SDK directory and only include the rte.extXYZ.mk
makefile fragments.
Signed-off-by: Keith Wiles
---
mk/rte.extvars.mk | 36 ++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/mk/rte.extvars.mk b/mk/rte.extvars.mk
index 3e5a990..e6c6401 100644
--- a/mk/rte.extvars.mk
+++ b/mk/rte.extvars.mk
@@ -30,8 +30,19 @@
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
-# directory where sources are located
+# To be included at the beginning of all RTE external user Makefiles. This
+# .mk will define the RTE environment variables by including the
+# config file of SDK. It also includes the config file from external
+# application if any.
#
+
+ifeq ($(RTE_SDK),)
+$(error RTE_SDK is not defined)
+endif
+ifeq ($(wildcard $(RTE_SDK)),)
+$(error RTE_SDK variable points to an invalid location)
+endif
+
ifdef S
ifeq ("$(origin S)", "command line")
RTE_SRCDIR := $(abspath $(S))
@@ -40,6 +51,16 @@ endif
RTE_SRCDIR ?= $(CURDIR)
export RTE_SRCDIR
+# define Q to '@' or not. $(Q) is used to prefix all shell commands to
+# be executed silently.
+Q=@
+ifdef V
+ifeq ("$(origin V)", "command line")
+Q=
+endif
+endif
+export Q
+
#
# Makefile to call once $(RTE_OUTPUT) is created
#
@@ -51,6 +72,13 @@ endif
RTE_EXTMK ?= $(RTE_SRCDIR)/Makefile
export RTE_EXTMK
+# RTE_TARGET is deducted from config when we are building the SDK.
+# Else, when building an external app, RTE_TARGET must be specified
+# by the user.
+ifeq ($(RTE_TARGET),)
+$(error RTE_TARGET is not defined)
+endif
+
RTE_SDK_BIN := $(RTE_SDK)/$(RTE_TARGET)
#
@@ -78,4 +106,8 @@ RTE_MACHINE := $(CONFIG_RTE_MACHINE:"%"=%)
RTE_EXEC_ENV := $(CONFIG_RTE_EXEC_ENV:"%"=%)
RTE_TOOLCHAIN := $(CONFIG_RTE_TOOLCHAIN:"%"=%)
-
+ifneq ($(wildcard $(RTE_SDK)/mk/target/$(RTE_TARGET)/rte.vars.mk),)
+include $(RTE_SDK)/mk/target/$(RTE_TARGET)/rte.vars.mk
+else
+include $(RTE_SDK)/mk/target/generic/rte.vars.mk
+endif
--
2.3.0
[dpdk-dev] Why only rx queue "0" can receive network packet by i40e NIC
Hi Thomas, Thanks very much for your reminder, you give me many help in this mail list. The issue with detailed information just as below. but I don't know who is the dpdk i40e maintainers? is maintainers at dpdk.org? Hardware list: 2 i40e 40G NICs Xeon E5-2670 v2(10 cores) 32G memory I loopback 2 i40e NICs by QSFP cable, one NIC send UDP network packet by DPDK, and another for receiving. I bind 4 processor's logical cores with 4 rx queue "0,1,2,3" on receiving NIC, when I start to send packet, only rx queue "0" can receive the UDP packet, the others queue always receive nothing. but it is work well on ixgbe 10G NICs, I can receive network packet from all rx queues. does anyone kindly know why? Regards, Haifeng -Original Message- From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] Sent: Friday, February 27, 2015 6:55 PM To: lhffjzh Cc: dev at dpdk.org Subject: Re: Why only rx queue "0" can receive network packet by i40e NIC 2015-02-27 16:47, lhffjzh: > Hi All, > > We use 4 cores loop 4 rx queues on one i40e port, but only rx queue "0" can > receive network packet, do anyone kindly know why? BTW, all of network > packet has same destination ip address but has more than 200 different > source ip address. It's possible that you don't have any answer for 2 reasons: - you replied in a thread dedicated to Cisco enic questions - you didn't describe your usage enough to understand your problem I suggest to use the button "new email" instead of "reply all" to start a new question with enough details. Did you noticed you put some Cisco guys in CC instead of putting the Intel responsible for i40e (see MAINTAINERS file)?
[dpdk-dev] [PATCH v3] af_packet: Fix some klocwork errors
Fix possible memory leak issue: free kvlist before return;
Fix possible resource lost issue: close qssockfd before return;
Signed-off-by: Changchun Ouyang
---
Change in v3:
- Also close sockets for all queues.
Change in v2:
- Make the error exit point a common path.
lib/librte_pmd_af_packet/rte_eth_af_packet.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/lib/librte_pmd_af_packet/rte_eth_af_packet.c
b/lib/librte_pmd_af_packet/rte_eth_af_packet.c
index 80e9bdf..eb2b67b 100644
--- a/lib/librte_pmd_af_packet/rte_eth_af_packet.c
+++ b/lib/librte_pmd_af_packet/rte_eth_af_packet.c
@@ -691,9 +691,14 @@ error:
rte_free((*internals)->rx_queue[q].rd);
if ((*internals)->tx_queue[q].rd)
rte_free((*internals)->tx_queue[q].rd);
+ if (((*internals)->rx_queue[q].sockfd != -1) &&
+ ((*internals)->rx_queue[q].sockfd != qsockfd))
+ close((*internals)->rx_queue[q].sockfd);
}
rte_free(*internals);
}
+ if (qsockfd != -1)
+ close(qsockfd);
return -1;
}
@@ -823,16 +828,21 @@ rte_pmd_af_packet_devinit(const char *name, const char
*params)
ret = rte_kvargs_process(kvlist, ETH_AF_PACKET_IFACE_ARG,
_packet_iface, );
if (ret < 0)
- return -1;
+ goto error;
}
ret = rte_eth_from_packet(name, , numa_node, kvlist);
close(sockfd); /* no longer needed */
if (ret < 0)
- return -1;
+ goto error;
+ rte_kvargs_free(kvlist);
return 0;
+
+error:
+ rte_kvargs_free(kvlist);
+ return -1;
}
static struct rte_driver pmd_af_packet_drv = {
--
1.8.4.2
[dpdk-dev] Error seen while compiling Pktgen-dpdk
On Sat, Feb 28, 2015 at 01:06:32PM +0530, Shankari Vaidyalingam wrote: > Hi, > > I'm facing the below error while executing make on Pktgen-dpdk source. > I'm using 2.8 version of pktgen downloaded > I have built DPDK binaries and then tried building pktgen-dpdk. > RTE_TARGET is set to x86_64-pktgen-linuxapp-gcc and RTE_SDK is set to the > directory where dpdk source files are present. > DPDK version - 1.7.1 > Please let me know how to resolve this error. > > controller at controller-VirtualBox:~/pktgen-2.8.0$ sudo > RTE_SDK=/home/controller/dpdk-1.7.1 make > make -C lib > make[1]: Entering directory `/home/controller/pktgen-2.8.0/lib' > == common > == lua > == src > make[1]: Leaving directory `/home/controller/pktgen-2.8.0/lib' > make -C app > make[1]: Entering directory `/home/controller/pktgen-2.8.0/app' > CC lpktgenlib.o > lpktgenlib.c: In function ?getf_etheraddr?: > lpktgenlib.c:174:9: error: passing argument 1 of ?cmdline_parse_etheraddr? > from incompatible pointer type [-Werror] > /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_etheraddr.h:75:5: > note: expected ?struct cmdline_parse_token_hdr_t *? but argument is of type > ?struct cmdline_etheraddr_t *? > lpktgenlib.c: In function ?getf_ipaddr?: > lpktgenlib.c:185:6: error: too many arguments to function > ?cmdline_parse_ipaddr? > /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_ipaddr.h:94:5: > note: declared here > lpktgenlib.c: In function ?pktgen_set?: > lpktgenlib.c:233:2: error: too many arguments to function > ?cmdline_parse_portlist? > /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_portlist.h:83:5: > note: declared here > lpktgenlib.c: In function ?set_seq?: > lpktgenlib.c:290:2: error: too many arguments to function > ?cmdline_parse_portlist? > /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_portlist.h:83:5: > note: declared here > lpktgenlib.c:291:3: error: too many arguments to function > ?cmdline_parse_etheraddr? > /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_etheraddr.h:75:5: > note: declared here > lpktgenlib.c:292:3: error: too many arguments to function > ?cmdline_parse_etheraddr? > /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_etheraddr.h:75:5: > note: declared here > lpktgenlib.c:295:7: error: too many arguments to function > ?cmdline_parse_ipaddr? > /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_ipaddr.h:94:5: > note: declared here > lpktgenlib.c:298:7: error: too many arguments to function > ?cmdline_parse_ipaddr? > /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_ipaddr.h:94:5: > note: declared here > lpktgenlib.c: In function ?set_seqTable?: > lpktgenlib.c:370:2: error: too many arguments to function > ?cmdline_parse_portlist? > /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_portlist.h:83:5: > note: declared here > lpktgenlib.c: In function ?pktgen_icmp?: > lpktgenlib.c:466:2: error: too many arguments to function > ?cmdline_parse_portlist? > /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_portlist.h:83:5: > note: declared here > lpktgenlib.c: In function ?pktgen_sendARP?: > lpktgenlib.c:494:2: error: too many arguments to function > ?cmdline_parse_portlist? > /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_portlist.h:83:5: > note: declared here > lpktgenlib.c: In function ?pktgen_set_mac?: > lpktgenlib.c:521:2: error: too many arguments to function > ?cmdline_parse_portlist? > /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_portlist.h:83:5: > note: declared here > lpktgenlib.c:522:2: error: too many arguments to function > ?cmdline_parse_etheraddr? > /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_etheraddr.h:75:5: > note: declared here > lpktgenlib.c: In function ?pktgen_prototype?: > lpktgenlib.c:582:2: error: too many arguments to function > ?cmdline_parse_portlist? > /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_portlist.h:83:5: > note: declared here > lpktgenlib.c: In function ?pktgen_set_ip_addr?: > lpktgenlib.c:615:2: error: too many arguments to function > ?cmdline_parse_portlist? > /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_portlist.h:83:5: > note: declared here > lpktgenlib.c:619:2: error: too many arguments to function > ?cmdline_parse_ipaddr? > /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_ipaddr.h:94:5: > note: declared here > lpktgenlib.c: In function ?pktgen_set_type?: > lpktgenlib.c:650:2: error: too many arguments to function > ?cmdline_parse_portlist? > /home/controller/dpdk-1.7.1/x86_64-native-linuxapp-gcc/include/cmdline_parse_portlist.h:83:5: > note: declared here > lpktgenlib.c: In function ?pktgen_send_ping4?: >
[dpdk-dev] [PATCH] testpmd: Fix segmentation fault when portmask is specified
Tested-by: Jingguo Fu
- Tested Commit: 8a6f6d45d290a27ef923d10925c4893380697b31
- OS: Fedora20 3.11.10-301.fc20.x86_64
- GCC: gcc version 4.8.3 20140911
- CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
- NIC: Intel Corporation Device [8086:1563]
- Default x86_64-native-linuxapp-gcc configuration
- Total 1 case, 1 passed, 0 failed
- Case: test_checksum_checking
Description: Check testpmd can be startup with cmdline for checksum
Command / instruction:
Start testpmd with command line as:
./x86_64-native-linuxapp-gcc/app/testpmd -c 0x1f -n 4 -- -i
--coremask=0x400 --portmask=0x3 --nb-cores=2 --enable-rx-cksum
--disable-hw-vlan --disable-rss --rxd=1024 --txd=1024 --rxfreet=0
Start ports:
set fwd cusm
start
Expected test result:
Testpmd can startup.
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Tetsuya Mukawa
Sent: Friday, February 27, 2015 15:16
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH] testpmd: Fix segmentation fault when portmask is
specified
If testpmd is invoked with portmask option like below, segmentation
fault will be occured. This patch fixes the issue.
Reported-by: De Lara Guarch, Pablo
Signed-off-by: Tetsuya Mukawa
---
app/test-pmd/testpmd.c | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 43329ed..61291be 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -579,20 +579,6 @@ init_config(void)
socket_num);
}
- /* Configuration of Ethernet ports. */
- ports = rte_zmalloc("testpmd: ports",
- sizeof(struct rte_port) * RTE_MAX_ETHPORTS,
- RTE_CACHE_LINE_SIZE);
- if (ports == NULL) {
- rte_exit(EXIT_FAILURE,
- "rte_zmalloc(%d struct rte_port) failed\n",
- RTE_MAX_ETHPORTS);
- }
-
- /* enabled allocated ports */
- for (pid = 0; pid < nb_ports; pid++)
- ports[pid].enabled = 1;
-
FOREACH_PORT(pid, ports) {
port = [pid];
rte_eth_dev_info_get(pid, >dev_info);
@@ -1999,6 +1985,26 @@ init_port_dcb_config(portid_t pid,struct dcb_config
*dcb_conf)
return 0;
}
+static void
+init_port(void)
+{
+ portid_t pid;
+
+ /* Configuration of Ethernet ports. */
+ ports = rte_zmalloc("testpmd: ports",
+ sizeof(struct rte_port) * RTE_MAX_ETHPORTS,
+ RTE_CACHE_LINE_SIZE);
+ if (ports == NULL) {
+ rte_exit(EXIT_FAILURE,
+ "rte_zmalloc(%d struct rte_port) failed\n",
+ RTE_MAX_ETHPORTS);
+ }
+
+ /* enabled allocated ports */
+ for (pid = 0; pid < nb_ports; pid++)
+ ports[pid].enabled = 1;
+}
+
int
main(int argc, char** argv)
{
@@ -2013,6 +2019,9 @@ main(int argc, char** argv)
if (nb_ports == 0)
RTE_LOG(WARNING, EAL, "No probed ethernet devices\n");
+ /* allocate port structures, and init them */
+ init_port();
+
set_def_fwd_config();
if (nb_lcores == 0)
rte_panic("Empty set of forwarding logical cores - check the "
--
1.9.1
[dpdk-dev] ixgbe vector mode not working.
Hi Stephen, The root cause is about the rx descriptor number. As we use below code to quick process the rx_tail wrap, it require rxd value is a 2^n. "rxq->rx_tail = (uint16_t)(rxq->rx_tail & (rxq->nb_rx_desc - 1));" We should add more checking on the input rxd, if checking fail, then tend to use scalar pmd. Thanks for the report, I'll send fix patch soon. -Cunming > -Original Message- > From: Stephen Hemminger [mailto:stephen at networkplumber.org] > Sent: Thursday, February 26, 2015 9:07 AM > To: Liang, Cunming > Cc: Nemeth, Balazs; Richardson, Bruce; Neil Horman; dev at dpdk.org > Subject: Re: ixgbe vector mode not working. > > On Wed, 25 Feb 2015 08:49:48 + > "Liang, Cunming" wrote: > > > Hi Stephen, > > > > Thanks for the info, with rxd=4000, I can reproduce it. > > On that time, it runs out of mbuf. > > I'll follow up this issue. > > The first time I ran it, the code was configure rx/tx conf > which was leftover from older versions. > > Second time I ran it and the same hang happened. > Looking at mbuf pool statistics I see that it gets exhausted, > even when extra mbuf's are added to the pool. > > Looks like a memory leak.
[dpdk-dev] Why only rx queue "0" can receive network packet by i40e NIC
Hi Haifeng > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of lhffjzh > Sent: Saturday, February 28, 2015 9:48 AM > To: 'Thomas Monjalon' > Cc: dev at dpdk.org; maintainers at dpdk.org > Subject: Re: [dpdk-dev] Why only rx queue "0" can receive network packet by > i40e NIC > > Hi Thomas, > > Thanks very much for your reminder, you give me many help in this mail list. > > The issue with detailed information just as below. but I don't know who is the > dpdk i40e maintainers? is maintainers at dpdk.org? > > Hardware list: > 2 i40e 40G NICs > Xeon E5-2670 v2(10 cores) > 32G memory > > I loopback 2 i40e NICs by QSFP cable, one NIC send UDP network packet by > DPDK, and another for receiving. I bind 4 processor's logical cores with 4 rx > queue "0,1,2,3" on receiving NIC, when I start to send packet, only rx queue > "0" > can receive > the UDP packet, the others queue always receive nothing. but it is work well > on > ixgbe 10G NICs, I can receive network packet from all rx queues. does anyone > kindly know why? Could you help to list the DPDK version you are using now? Two possible reasons: 1. UDP rss is not enabled on your board correctly. I40e has different rss flags from ixgbe, so I am wondering if you use it correctly. In addition, this will be unified from 2.0. So I care about the DPDK version. 2. The UDP stream is occasionally hit the hash key of queue 0. You'd better to try to send your UDP stream with random 5-tuples, to get the hash value hit different queues randomly. Regards, Helin > > > Regards, > Haifeng > > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, February 27, 2015 6:55 PM > To: lhffjzh > Cc: dev at dpdk.org > Subject: Re: Why only rx queue "0" can receive network packet by i40e NIC > > 2015-02-27 16:47, lhffjzh: > > Hi All, > > > > We use 4 cores loop 4 rx queues on one i40e port, but only rx queue "0" > can > > receive network packet, do anyone kindly know why? BTW, all of network > > packet has same destination ip address but has more than 200 different > > source ip address. > > It's possible that you don't have any answer for 2 reasons: > - you replied in a thread dedicated to Cisco enic questions > - you didn't describe your usage enough to understand your problem > > I suggest to use the button "new email" instead of "reply all" to > start a new question with enough details. > > Did you noticed you put some Cisco guys in CC instead of putting the > Intel responsible for i40e (see MAINTAINERS file)? >
[dpdk-dev] [PATCH v3 0/3] support TSO on i40e
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu > Sent: Thursday, February 26, 2015 11:37 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v3 0/3] support TSO on i40e > > This patch set enables i40e TSO feature for both non-tunneling packet and > tunneling packet. > > Change logs: > v2 change: rework based on Olivier's patch set [PATCH v2 00/20] enhance > Tx checksum offload API > http://dpdk.org/ml/archives/dev/2015-February/012375.html > v3 change: > 1. split 'enable i40e TSO' patch in v2 into two patches. > One patch is for moving tx offloads parameters of i40e to > separate > structure. > And other patch is for enabling i40e TSO feature for both > non-tunneling packet and tunneling packet > 2. patch order change > > Jijiang Liu (3): > Move Tx offloads parameters of i40e to separate structure > Enable i40e TSO feature for both non-tunneling packet and tunneling packet > Advertise the DEV_TX_OFFLOAD_TCP_TSO flag in the PMD features > > lib/librte_pmd_i40e/i40e_ethdev.c |3 +- > lib/librte_pmd_i40e/i40e_rxtx.c | 99 > +++-- > lib/librte_pmd_i40e/i40e_rxtx.h | 13 + > 3 files changed, 87 insertions(+), 28 deletions(-) Acked-by: Helin Zhang > > -- > 1.7.7.6
[dpdk-dev] [PATCH v3] eal: Clean up export of per_lcore__socket_id
Hi,
> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Friday, February 27, 2015 8:33 PM
> To: dev at dpdk.org
> Cc: thomas.monjalon at 6wind.com; Liang, Cunming; Neil Horman
> Subject: [PATCH v3] eal: Clean up export of per_lcore__socket_id
>
> Theres no need to export this variable. Its set and queried from an API call
> that doesn't exist in the hot path. Instead just export the rte_socket_id
> symbol and make the variable private to protect it from type changes. We
> should
> do this with the other exported variables too, but I think its too late in the
> release cycle to do that.
>
> tested using distributor_autotest (which uses rte_socket_id), successfully.
> Only tested on linux, as I don't currently have a bsd system spun up, but the
> changes are symmetric, and should be fine
>
> Signed-off-by: Neil Horman
>
> ---
> Change Notes:
>
> v2) Moved rte_socket_id to be a common function
>
> v3) replaced some previously removed spaces
> ---
> lib/librte_eal/bsdapp/eal/rte_eal_version.map | 2 +-
> lib/librte_eal/common/eal_common_thread.c | 7 +++
> lib/librte_eal/common/include/rte_lcore.h | 7 +--
> lib/librte_eal/linuxapp/eal/rte_eal_version.map | 2 +-
> 4 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> index 17515a9..d83524d 100644
> --- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> +++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> @@ -10,7 +10,6 @@ DPDK_2.0 {
> pci_driver_list;
> per_lcore__lcore_id;
> per_lcore__rte_errno;
> - per_lcore__socket_id;
> rte_cpu_check_supported;
> rte_cpu_get_flag_enabled;
> rte_cycles_vmware_tsc_map;
> @@ -82,6 +81,7 @@ DPDK_2.0 {
> rte_set_log_level;
> rte_set_log_type;
> rte_snprintf;
> + rte_socket_id;
> rte_strerror;
> rte_strsplit;
> rte_sys_gettid;
> diff --git a/lib/librte_eal/common/eal_common_thread.c
> b/lib/librte_eal/common/eal_common_thread.c
> index f4d9892..2405e93 100644
> --- a/lib/librte_eal/common/eal_common_thread.c
> +++ b/lib/librte_eal/common/eal_common_thread.c
> @@ -46,6 +46,13 @@
>
> #include "eal_thread.h"
>
> +RTE_DECLARE_PER_LCORE(unsigned , _socket_id);
> +
> +unsigned rte_socket_id(void)
> +{
> + return RTE_PER_LCORE(_socket_id);
> +}
> +
> int eal_cpuset_socket_id(rte_cpuset_t *cpusetp)
> {
> unsigned cpu = 0;
> diff --git a/lib/librte_eal/common/include/rte_lcore.h
> b/lib/librte_eal/common/include/rte_lcore.h
> index 20a58eb..e03264e 100644
> --- a/lib/librte_eal/common/include/rte_lcore.h
> +++ b/lib/librte_eal/common/include/rte_lcore.h
> @@ -81,7 +81,6 @@ struct lcore_config {
> extern struct lcore_config lcore_config[RTE_MAX_LCORE];
>
> RTE_DECLARE_PER_LCORE(unsigned, _lcore_id); /**< Per thread "lcore id". */
> -RTE_DECLARE_PER_LCORE(unsigned, _socket_id); /**< Per thread "socket id".
> */
> RTE_DECLARE_PER_LCORE(rte_cpuset_t, _cpuset); /**< Per thread "cpuset". */
>
> /**
> @@ -145,11 +144,7 @@ rte_lcore_index(int lcore_id)
> * @return
> * the ID of current lcoreid's physical socket
> */
> -static inline unsigned
> -rte_socket_id(void)
> -{
> - return RTE_PER_LCORE(_socket_id);
> -}
> +unsigned rte_socket_id(void);
>
> /**
> * Get the ID of the physical socket of the specified lcore
> diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
> b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
> index 17515a9..d83524d 100644
> --- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
> +++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
> @@ -10,7 +10,6 @@ DPDK_2.0 {
> pci_driver_list;
> per_lcore__lcore_id;
> per_lcore__rte_errno;
> - per_lcore__socket_id;
> rte_cpu_check_supported;
> rte_cpu_get_flag_enabled;
> rte_cycles_vmware_tsc_map;
> @@ -82,6 +81,7 @@ DPDK_2.0 {
> rte_set_log_level;
> rte_set_log_type;
> rte_snprintf;
> + rte_socket_id;
> rte_strerror;
> rte_strsplit;
> rte_sys_gettid;
> --
> 2.1.0
Acked-by: Cunming Liang
[dpdk-dev] [PATCH v6 4/8] eal/linux: add per rx queue interrupt handling based on VFIO
Thanks Thomas.
It's my fault that directly reply David's mail, haven't notice his mail isn't
in a plain text mode.
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, February 27, 2015 10:13 PM
> To: Liang, Cunming
> Cc: David Marchand; dev at dpdk.org; Stephen Hemminger; Zhou, Danny
> Subject: Re: [PATCH v6 4/8] eal/linux: add per rx queue interrupt handling
> based
> on VFIO
>
> Hi Cunming,
>
> First, sorry to have to say that, but it is not easy to read discussions
> where quote marks are not used. I re-insert them for clarity.
>
> Comments below.
>
> 2015-02-27 12:22, Liang, Cunming:
> > From: David Marchand [mailto:david.marchand at 6wind.com]
> > Sent: Friday, February 27, 2015 6:34 PM
> >
> > > I am not really comfortable with this api.
> > >
> > > This is just creating something on top of the standard epoll api with
> > > limitations. In the end, we could just use an external lib that does this
> > > already.
> >
> > [Liang, Cunming] Not really, I think. We try to protect the data inside
> > ?rte_intr_handle?, it doesn?t expect user to understand the things defined
> > inside ?rte_intr_handle?.
> > It?s better typedef ?rte_intr_handle? as a raw integer ID, having a function
> > to get it from a ethdev. Then all the interrupt api is around it.
> > It provides the common pci NIC devices rxtx interrupt processing approach.
> > For the limitations, we can fix it step by step.
> >
> > > So ok, this will work for your limited use case, but this will not be
> > > really useful for anything else.
> > > Not sure it has its place in eal, this is more an example to me.
> >
> > [Liang, Cunming] ?limited use case? do you means only for rxtx ?
> > It don?t expect to provide a generic event mechanism (like libev/libevent
> > does), but a simple way to allow PMD work with DMA interrupt. It mainly
> > abstract for rx interrupt purpose. I appreciate if you could help to list
> > more useful cases.
>
> You don't expect to provide a generic event mechanism but application
> developpers could need to wait for many events at once, not only Rx ones.
> That's why it's better to provide only the needed parts to use something
> generic like libevent.
> And we should avoid reinventing the wheel.
[LCM] Ok, I get you. I have a simple proposal to allow either RX event or other
events can be handled in rte_intr_wait().
For the input data 'epoll_data', instead of using 'u32', let's keep use 'int
fd'.
If the most significant bit is 0, event[n] stands for a fd. If it's 1,
event[0]&0x stands for a vector number.
So during 'rte_intr_set', it get 16bit vector number and encode it as a 32bit
int with the most significant bit 1.
Then on 'rte_intr_wait', only process the data.fd with the most significant bit
1. And bypass the user fd.
'rte_intr_wait(struct rte_intr_handle *intr_handle, int epfd, int *event,
uint16_t num)'.
As user already can assign an epfd, so they can add any normal event fd into
the epfd. Make sense ?
>
> > > > +static void
> > > > +eal_intr_process_rxtx_interrupts(struct rte_intr_handle *intr_handle,
> > > > +struct epoll_event *events,
> > > > +uint32_t *vec, int nfds)
> > > > +{
> > > > + int i, bytes_read;
> > > > + union rte_intr_read_buffer buf;
> > > > + int fd;
> > > > +
> > > > + for (i = 0; i < nfds; i++) {
> > > > + /* set the length to be read for different handle type
> > > > */
> > > > + switch (intr_handle->type) {
> > > > + case RTE_INTR_HANDLE_UIO:
> > > > + bytes_read = sizeof(buf.uio_intr_count);
> > > > + break;
> > > > + case RTE_INTR_HANDLE_ALARM:
> > > > + bytes_read = sizeof(buf.timerfd_num);
> > > > + break;
> > > > +#ifdef VFIO_PRESENT
> > > > + case RTE_INTR_HANDLE_VFIO_MSIX:
> > > > + case RTE_INTR_HANDLE_VFIO_MSI:
> > > > + case RTE_INTR_HANDLE_VFIO_LEGACY:
> > > > + bytes_read = sizeof(buf.vfio_intr_count);
> > > > + break;
> > > > +#endif
> > > > + default:
> > > > + bytes_read = 1;
> > > > + break;
> > > > + }
> > > > +
> > > > + /**
> > > > + * read out to clear the ready-to-be-read flag
> > > > + * for epoll_wait.
> > > > + */
> > > > + vec[i] = events[i].data.u32;
> > > > + assert(vec[i] < VFIO_MAX_RXTX_INTR_ID);
> > > > +
> > > > + fd = intr_handle->efds[vec[i]];
> > > > + bytes_read = read(fd, , bytes_read);
> > > > + if (bytes_read < 0)
> > > > + RTE_LOG(ERR, EAL, "Error reading from file "
> > > > + "descriptor %d: %s\n", fd,
> > > >
[dpdk-dev] [PATCH v2] af_packet: Fix some klocwork errors
> -Original Message- > From: Neil Horman [mailto:nhorman at tuxdriver.com] > Sent: Friday, February 27, 2015 10:05 PM > To: Ouyang, Changchun > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2] af_packet: Fix some klocwork errors > > On Fri, Feb 27, 2015 at 08:49:13AM +0800, Ouyang Changchun wrote: > > Fix possible memory leak issue: free kvlist before return; Fix > > possible resource lost issue: close qssockfd before return; > > > > Signed-off-by: Changchun Ouyang > > --- > > change in v2: > > - Make the error exit point a common path. > > > > lib/librte_pmd_af_packet/rte_eth_af_packet.c | 11 +-- > > 1 file changed, 9 insertions(+), 2 deletions(-) > > > > diff --git a/lib/librte_pmd_af_packet/rte_eth_af_packet.c > > b/lib/librte_pmd_af_packet/rte_eth_af_packet.c > > index 80e9bdf..c675724 100644 > > --- a/lib/librte_pmd_af_packet/rte_eth_af_packet.c > > +++ b/lib/librte_pmd_af_packet/rte_eth_af_packet.c > > @@ -694,6 +694,8 @@ error: > > } > > rte_free(*internals); > > } > > + if (qsockfd != -1) > > + close(qsockfd); > This is insufficient. qsockfd is a loop index that is reassigned for each tx > queue we have. In the error path you need to do this, and loop through the > tx queues, closing each tx_queue->sockfd. > Thanks, will have a v3 to resolve it. Changchun
[dpdk-dev] [PATCH v6 3/8] eal/bsd: dummy for new intr definition
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, February 27, 2015 10:22 PM
> To: Liang, Cunming
> Cc: David Marchand; dev at dpdk.org; Stephen Hemminger
> Subject: Re: [PATCH v6 3/8] eal/bsd: dummy for new intr definition
>
> 2015-02-27 11:21, Liang, Cunming:
> > From: David Marchand [mailto:david.marchand at 6wind.com]
> > > On Fri, Feb 27, 2015 at 5:56 AM, Cunming Liang wrote:
> > > > @@ -49,6 +51,8 @@ enum rte_intr_handle_type {
> > > >
> > > > struct rte_intr_handle {
> > > >
> > > > int fd; /**< file descriptor */
> > > > enum rte_intr_handle_type type; /**< handle type */
> > > >
> > > > + int max_intr;/**< max interrupt requested */
> > > > + uint32_t vec_num[VFIO_MAX_QUEUE_ID]; /**< rxtx intr vector
> number */
> > > > };
> > >
> > > No need to add those since this is not supported for bsd.
> >
> > [Liang, Cunming] max_intr is used in dev_init for pci_dev->intr_handle init.
> > Vec_num is used in ethdev API rx_intr_vec_get. Without it, BSD macro will
> > used for each of the reference place.
> > As they?re quite generic, even bsd will require either max_intr or vec
> > mapping table.
>
> Is it needed to build and run DPDK on FreeBSD?
[LCM] As it's the EAL change, so I try to make sure FreeBSD can build and run
as normal.
[dpdk-dev] [PATCH v6 2/8] eal/linux: add rx queue interrupt FDs to intr handle struct
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, February 27, 2015 10:52 PM > To: Liang, Cunming > Cc: David Marchand; dev at dpdk.org; Stephen Hemminger; Zhou, Danny > Subject: Re: [PATCH v6 2/8] eal/linux: add rx queue interrupt FDs to intr > handle > struct > > 2015-02-27 11:28, Liang, Cunming: > > From: David Marchand [mailto:david.marchand at 6wind.com] > > Sent: Friday, February 27, 2015 6:33 PM > > > On Fri, Feb 27, 2015 at 5:56 AM, Cunming Liang wrote: > > > > --- a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_interrupts.h > > > > +++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_interrupts.h > > > > @@ -38,6 +38,9 @@ > > > > > > > > #ifndef _RTE_LINUXAPP_INTERRUPTS_H_ > > > > #define _RTE_LINUXAPP_INTERRUPTS_H_ > > > > > > > > +#define VFIO_MAX_RXTX_INTR_ID32 > > > > +#define VFIO_MAX_QUEUE_IDVFIO_MAX_RXTX_INTR_ID > > > > > > This is a little weird to talk about vfio here. > > > This file is "generic". > > > > > > Ok, you will store vfio eventfds here, but vfio is an implementation, > > > not the abstraction. > > > > [Liang, Cunming] If looking at the rte_intr_hanle_type, it includes > UIO/VFIO_LEGACY/VFIO_MSI/VFIO_MSIX. > > I agree, VFIO is an implementation, but the different type combination is a > > kind > of ?abstraction?. > > So in rte_intr_handle (like a multiplexing), some specified field for vfio > interrupter mapping, I feel it?s reasonable. > > Not sure to understand. Are we trying to mask the different kernel drivers > from an application point of view, and provide a generic interrupt mechanism? > If yes, why some VFIO constants are needed? > I'm not saying that the current implementation is perfect, but we should try > to improve it. [LCM] VFIO_MAX_RXTX_INTR_ID is easy to fix, it can move to a private interrupt header file, as only be used inside EAL. VFIO_MAX_QUEUE_ID can be removed, so vec_num[] dynamic creation by the device driver. Sounds good ? > > Thanks
[dpdk-dev] [PATCH v15] testpmd: Add port hotplug support
2015-02-27 15:14, Tetsuya Mukawa:
> On 2015/02/27 3:49, De Lara Guarch, Pablo wrote:
> >
> >> -Original Message-
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tetsuya Mukawa
> >> Sent: Wednesday, February 25, 2015 7:32 PM
> >> To: dev at dpdk.org
> >> Subject: [dpdk-dev] [PATCH v15] testpmd: Add port hotplug support
> >>
> >> The patch introduces following commands.
> >> - port attach [ident]
> >> - port detach [port_id]
> >> - attach: attaching a port
> >> - detach: detaching a port
> >> - ident: pci address of physical device.
> >> Or device name and parameters of virtual device.
> >> (ex. :02:00.0, eth_pcap0,iface=eth0)
> >> - port_id: port identifier
> >>
> >> v15:
> >> - Replace rte_eal_dev_attach() by rte_eth_dev_attach()
> >> - Replace rte_eal_dev_detach() by rte_eth_dev_detach()
> >>
> >> v7:
> >> - Fix doc.
> >> (Thanks to Iremonger, Bernard)
> >> - Fix port checking implementation of star_port();
> >> (Thanks to Qiu, Michael)
> >> v5:
> >> - Add testpmd documentation.
> >> (Thanks to Iremonger, Bernard)
> >> v4:
> >> - Fix strings of command help.
> >>
> >> Signed-off-by: Tetsuya Mukawa
> >> ---
> >> app/test-pmd/cmdline.c | 137 +++
> >> app/test-pmd/config.c | 102 --
> >> app/test-pmd/parameters.c | 22 ++-
> >> app/test-pmd/testpmd.c | 199
> >> +---
> >> app/test-pmd/testpmd.h | 18 ++-
> >> doc/guides/testpmd_app_ug/testpmd_funcs.rst | 57
> >> 6 files changed, 409 insertions(+), 126 deletions(-)
> >>
> > [...]
> >
> >> @@ -1423,12 +1443,8 @@ set_fwd_ports_list(unsigned int *portlist,
> >> unsigned int nb_pt)
> >> again:
> >>for (i = 0; i < nb_pt; i++) {
> >>port_id = (portid_t) portlist[i];
> >> - if (port_id >= nb_ports) {
> >> - printf("Invalid port id %u >= %u\n",
> >> - (unsigned int) port_id,
> >> - (unsigned int) nb_ports);
> >> + if (port_id_is_invalid(port_id, ENABLED_WARN))
> > Sorry for catching this late, but there is a segmentation fault when this
> > function gets called
> > when parsing "portmask" at testpmd initialization, since port_id_is_invalid
> > function needs to have array "ports" initialized.
> > I would revert the change, but not sure if this is need for other reasons.
>
> Hi Pablo,
>
> I appreciate for your reporting.
> I could reproduce the issue with portmask option like below
> $ sudo ./testpmd -c f -n 1 -- --portmask 0x1 -i
>
> As a result of investigation, when 'launch_args_parse()' is called, port
> structure hasn't been allocated yet.
> As you said, this causes the issue.
>
> I guess we can have 2 options to fix the issue.
>
> Option1:
> Fix 'set_fwd_ports_list()' to work even when port structure hasn't been
> initialized yet.
> I guess this implementation is much complex for readers of test-pmd code.
>
> Option2:
> Move initialization code of ports like below.
>
> int main () {
>
> init_port(); /* only initialize port structure here*/
> launch_args_parse();
> init_config(); /* So far, port initialization code is
> implemented in init_config() */
>
> }
>
> I guess 2nd option may be better.
> How do you think?
> I will send a patch to implement 2nd option.
> if you are ok to fix like above, could you please check and acked it?
For the record, Tetsuya chose the second option:
http://dpdk.org/browse/dpdk/commit/?id=ffc468ff3cfe768
[dpdk-dev] [PATCH v11 2/2] librte_pmd_null: Support port hotplug function
2015-02-26 12:21, Mcnamara, John: > Hi, > > The HEAD doesn't compile with gcc 4.7.2: > > $ git clone http://dpdk.org/git/dpdk > $ cd dpdk > $ make T=x86_64-native-linuxapp-gcc -j install > > ... > == Build lib/librte_pipeline > SYMLINK-FILE include/rte_pipeline.h > CC rte_pipeline.o > /tmp/dpdk/lib/librte_pmd_null/rte_eth_null.c: In function 'eth_stats_get': > > /tmp/dpdk/lib/librte_pmd_null/rte_eth_null.c:302:28: > error: array subscript is above array bounds [-Werror=array-bounds] > /tmp/dpdk/lib/librte_pmd_null/rte_eth_null.c:302:28: > error: array subscript is above array bounds [-Werror=array-bounds] > /tmp/dpdk/lib/librte_pmd_null/rte_eth_null.c:302:28: > error: array subscript is above array bounds [-Werror=array-bounds] > ... > > cc1: all warnings being treated as errors > make[5]: *** [rte_eth_null.o] Error 1 > make[4]: *** [librte_pmd_null] Error 2 > > > The following commit introduced this issue: > > $ git bisect good > c743e50c475f73edf78e5ba26445d7c6ea217f40 is the first bad commit > commit c743e50c475f73edf78e5ba26445d7c6ea217f40 > Author: Tetsuya Mukawa > Date: Mon Feb 23 14:12:34 2015 +0900 > > null: new poll mode driver > > > I don't see the issue with gcc 4.9. Fixed: http://dpdk.org/browse/dpdk/commit/?id=e34550c8b97826
[dpdk-dev] [PATCH] testpmd: Fix segmentation fault when portmask is specified
> > If testpmd is invoked with portmask option like below, segmentation > > fault will be occured. This patch fixes the issue. > > > > Reported-by: De Lara Guarch, Pablo > > Signed-off-by: Tetsuya Mukawa > > Acked-by: Pablo de Lara Applied, thanks
[dpdk-dev] [PATCH] librte_pmd_null: Fix build issue with icc
> > This patch fixes following errors with icc. > > > Confirmed that this fixes the issue with ICC 13.1.1. > > Acked-by: John McNamara Applied, thanks
[dpdk-dev] [PATCH] librte_pmd_null: Fix build issue with gcc-4.7
> > This patch fixes following errors with gcc-4.7. > > > Confirmed that this fixes the issue with 4.7.2. > > Acked-by: John McNamara Applied, thanks
[dpdk-dev] [PATCH] eal: Fix build issue of hotplug with icc
> > This patch fixes following errors with icc. > > > > error #188: enumerated type mixed with another type > > return -1; > > > Confirmed that this fixes the issue with ICC 13.1.1. > > Acked-by: John McNamara Applied, thanks
[dpdk-dev] [PATCH] virtio: Fix compilation issue on freebsd
> > This patch fixes the compilation issue on freebsd: > > > > /root/qwan/tmp/dpdk_org/lib/librte_pmd_virtio/virtio_ethdev.c: In function > > 'virtio_resource_init': > > /root/qwan/tmp/dpdk_org/lib/librte_pmd_virtio/virtio_ethdev.c:1071:56: > > error: > > unused parameter 'pci_dev' [-Werror=unused-parameter] static int > > virtio_resource_init(struct rte_pci_device *pci_dev) > > ^ > > cc1: all warnings being treated as errors > > > > Signed-off-by: Changchun Ouyang > > Acked-by: Cunming Liang Applied, thanks
