Re: [dpdk-users] Query on handling packets
Hello, It would be really helpful if you can provide us a link (for both Tx and Rx) to the project you mentioned earlier where you worked on a similar problem, if possible. Thanks and Regards, Harsh & Hrishikesh. On Mon, 12 Nov 2018 at 01:15, Harsh Patel wrote: > Thanks a lot for all the support. We are looking into our work as of now > and will contact you once we are done checking it completely from our side. > Thanks for the help. > > Regards, > Harsh and Hrishikesh > > On Sat, 10 Nov 2018 at 11:47, Wiles, Keith wrote: > >> Please make sure to send your emails in plain text format. The Mac mail >> program loves to use rich-text format is the original email use it and I >> have told it not only send plain text :-( >> >> > On Nov 9, 2018, at 4:09 AM, Harsh Patel >> wrote: >> > >> > We have implemented the logic for Tx/Rx as you suggested. We compared >> the obtained throughput with another version of same application that uses >> Linux raw sockets. >> > Unfortunately, the throughput we receive in our DPDK application is >> less by a good margin. Is this any way we can optimize our implementation >> or anything that we are missing? >> > >> >> The PoC code I was developing for DAPI I did not have any performance of >> issues it run just as fast with my limited testing. I converted the l3fwd >> code and I saw 10G 64byte wire rate as I remember using pktgen to generate >> the traffic. >> >> Not sure why you would see a big performance drop, but I do not know your >> application or code. >> >> > Thanks and regards >> > Harsh & Hrishikesh >> > >> > On Thu, 8 Nov 2018 at 23:14, Wiles, Keith >> wrote: >> > >> > >> >> On Nov 8, 2018, at 4:58 PM, Harsh Patel >> wrote: >> >> >> >> Thanks >> >> for your insight on the topic. Transmission is working with the >> functions you mentioned. We tried to search for some similar functions for >> handling incoming packets but could not find anything. Can you help us on >> that as well? >> >> >> > >> > I do not know if a DPDK API set for RX side. But in the DAPI (DPDK API) >> PoC I was working on and presented at the DPDK Summit last Sept. In the PoC >> I did create a RX side version. The issues it has a bit of tangled up in >> the DAPI PoC. >> > >> > The basic concept is a call to RX a single packet does a rx_burst of N >> number of packets keeping then in a mbuf list. The code would spin waiting >> for mbufs to arrive or return quickly if a flag was set. When it did find >> RX mbufs it would just return the single mbuf and keep the list of mbufs >> for later requests until the list is empty then do another rx_burst call. >> > >> > Sorry this is a really quick note on how it works. If you need more >> details we can talk more later. >> >> >> >> Regards, >> >> Harsh >> >> and Hrishikesh. >> >> >> >> >> >> On Thu, 8 Nov 2018 at 14:26, Wiles, Keith >> wrote: >> >> >> >> >> >> > On Nov 8, 2018, at 8:24 AM, Harsh Patel >> wrote: >> >> > >> >> > Hi, >> >> > We are working on a project where we are trying to integrate DPDK >> with >> >> > another software. We are able to obtain packets from the other >> environment >> >> > to DPDK environment in one-by-one fashion. On the other hand DPDK >> allows to >> >> > send/receive burst of data packets. We want to know if there is any >> >> > functionality in DPDK to achieve this conversion of single incoming >> packet >> >> > to a burst of packets sent on NIC and similarly, conversion of burst >> read >> >> > packets from NIC to send it to other environment sequentially? >> >> >> >> >> >> Search in the docs or lib/librte_ethdev directory on >> rte_eth_tx_buffer_init, rte_eth_tx_buffer, ... >> >> >> >> >> >> >> >> > Thanks and regards >> >> > Harsh Patel, Hrishikesh Hiraskar >> >> > NITK Surathkal >> >> >> >> Regards, >> >> Keith >> >> >> > >> > Regards, >> > Keith >> > >> >> Regards, >> Keith >> >>
[dpdk-users] Cannot initialize tailq: RTE_DISTRIBUTOR
Hi, I'm trying to get a cooperative multi-process application working, but running into an error that searching isn't helping on. I'm starting the primary with the following parameters: -c 3 -n 4 --proc-type=auto and it's correctly recognized as primary: EAL: Auto-detected process type: PRIMARY The secondary is started with: -l 2,3,10,11,21,22,23,24,31,32,33 -n 4 --proc-type=auto and it too detects properly: EAL: Auto-detected process type: SECONDARY However, rte_eal_init panics with the following: EAL: Auto-detected process type: SECONDARY EAL: Multi-process socket /var/run/dpdk/rte/mp_socket_16884_c35d72ba8fc EAL: Probing VFIO support... EAL: VFIO support initialized EAL: Cannot initialize tailq: RTE_DISTRIBUTOR Tailq 0: qname:, tqh_first:(nil), tqh_last:0x7f0d8d20407c Tailq 1: qname:, tqh_first:(nil), tqh_last:0x7f0d8d2040ac Tailq 2: qname:, tqh_first:(nil), tqh_last:0x7f0d8d2040dc Tailq 3: qname:, tqh_first:(nil), tqh_last:0x7f0d8d20410c Tailq 4: qname:, tqh_first:(nil), tqh_last:0x7f0d8d20413c Tailq 5: qname:, tqh_first:(nil), tqh_last:0x7f0d8d20416c Tailq 6: qname:, tqh_first:(nil), tqh_last:0x7f0d8d20419c Tailq 7: qname:, tqh_first:0x7f057ffa8cc0, tqh_last:0x7f0542a02b00 Tailq 8: qname:, tqh_first:0x7f057fe26b00, tqh_last:0x7f0542a02a80 Tailq 9: qname:, tqh_first:(nil), tqh_last:0x7f0d8d20422c Tailq 10: qname:, tqh_first:(nil), tqh_last:0x7f0d8d20425c Tailq 11: qname:, tqh_first:(nil), tqh_last:0x7f0d8d20428c Tailq 12: qname:, tqh_first:(nil), tqh_last:0x7f0d8d2042bc Tailq 13: qname:<>, tqh_first:(nil), tqh_last:(nil) Tailq 14: qname:<>, tqh_first:(nil), tqh_last:(nil) Tailq 15: qname:<>, tqh_first:(nil), tqh_last:(nil) Tailq 16: qname:<>, tqh_first:(nil), tqh_last:(nil) Tailq 17: qname:<>, tqh_first:(nil), tqh_last:(nil) Tailq 18: qname:<>, tqh_first:(nil), tqh_last:(nil) Tailq 19: qname:<>, tqh_first:(nil), tqh_last:(nil) Tailq 20: qname:<>, tqh_first:(nil), tqh_last:(nil) Tailq 21: qname:<>, tqh_first:(nil), tqh_last:(nil) Tailq 22: qname:<>, tqh_first:(nil), tqh_last:(nil) Tailq 23: qname:<>, tqh_first:(nil), tqh_last:(nil) Tailq 24: qname:<>, tqh_first:(nil), tqh_last:(nil) Tailq 25: qname:<>, tqh_first:(nil), tqh_last:(nil) Tailq 26: qname:<>, tqh_first:(nil), tqh_last:(nil) Tailq 27: qname:<>, tqh_first:(nil), tqh_last:(nil) Tailq 28: qname:<>, tqh_first:(nil), tqh_last:(nil) Tailq 29: qname:<>, tqh_first:(nil), tqh_last:(nil) Tailq 30: qname:<>, tqh_first:(nil), tqh_last:(nil) Tailq 31: qname:<>, tqh_first:(nil), tqh_last:(nil) EAL: FATAL: Cannot init tail queues for objects EAL: Cannot init tail queues for objects EAL: Error - exiting with code: 1 Cause: Error with EAL initialization I've tried running with ASLR on and off since I'd seen things related to that, but it doesn't seem to improve things unless I run it with --base-virtaddr, but I don't know what to set in that case. The MP example code seems fine, and I can send messages back and forth using that. Has anyone seen this?
[dpdk-users] dpdk rte_eth_tx_burst can't send chain mbuf
dpdk:17.02 intel 82599 es dual port i want send pkt by rte_eth_tx_burst , so, i build two rte_mbuf, such as: rte_mbuf *buf1,*buf2; buf1 = rte_pktmbuf_alloc(...) buf2=rte_pktmbuf_alloc(...) buf1->next = buf2; buf2->next = NULL; buf1->nb_segs = 2; buf1->data_len = 64; buf2->data_len = 64; buf1->pkt_len = 128; buf2_pkt_len = 64; rte_eth_tx_burst(portid,queueid,(rte_mbuf**),1); can't send this pkt where is wrong ? thank you
Re: [dpdk-users] pktgen-dpdk runts when start size is 64
Hi, I try to add --crc-strip parameter in pktgen , and will work success now. Follow is command and result: By the way, it seems there is no conditional expressions to check whether support crc-strip or not, when set pktgen size? Will you add after? Because --crc-strip only check Pkts receive, it seems mismatch. ./pktgen -l 0-4 -n 3 -- -P --crc-strip -m "[1:3].0,[2:4].1" Pktgen:/> start all \ Ports 0-1 of 2 Copyright (c) <2010-2018>, Intel Corporation Flags:Port : P--:0 P--:1 Link State: TotalRate Pkts/s Max/Rx : 1487850/1487850 1491605/1491605 2979455/2979455 Max/Tx : 1491605/1491605 1487850/1487850 2979455/2979455 MBits/s Rx/Tx :999/10021002/999 2002/2002 Broadcast : 0 0 Multicast : 0 0 64 Bytes: 3117320 3126509 65-127 : 0 0 128-255 : 0 0 256-511 : 0 0 512-1023: 0 0 1024-1518 : 0 0 Runts/Jumbos : 0/0 0/0 Errors Rx/Tx : 0/0 0/0 ..< shown parts of pktgen >. Best regards, Bichan.Lu -Original Message- From: Wiles, Keith [mailto:keith.wi...@intel.com] Sent: Thursday, November 08, 2018 9:49 PM To: Bichan.Lu Cc: users@dpdk.org Subject: Re: [dpdk-users] pktgen-dpdk runts when start size is 64 > On Nov 8, 2018, at 2:12 AM, Bichan.Lu wrote: > > Hi, > > OS: CentOS 7.5.1804 > Pktgen version: pktgen-3.5.8 > DPDK verison: dpdk-18.08 > > I use the pktgen in follows command. When I start pktgen, default PktSize is > 64, in the command I sad: > > ./pktgen -l 0-4 -n 3 -- -P -m "[1:3].0,[2:4].1" > Pktgen:/> start all > > Link State: > TotalRate > Pkts/s Max/Rx : 1487853/1487844 1491609/1491602 > 2979462/2979446 > Max/Tx : 1491607/1491606 1487855/1487841 > 2979459/2979447 > MBits/s Rx/Tx :999/10021002/999 > 2002/2002 > Broadcast : 0 0 > Multicast : 0 0 > 64 Bytes: 0 0 > 65-127 : 0 0 > 128-255 : 0 0 > 256-511 : 0 0 > 512-1023: 0 0 > 1024-1518 : 0 0 > Runts/Jumbos : 8889515/0 8913610/0 > Errors Rx/Tx : 0/0 0/0 > ..< shown parts of pktgen >. > > Then will be get Runts. > I tried when size is 68, range will be in [64 Bytes], and no runts. > Pktgen:/> set 0 size 68 > Pktgen:/> set 1 size 68 > Pktgen:/> start all > What is the hardware NIC as most of the hardware appends the FCS? Pktgen expects the NIC to append the FCS and there is a flag to disable that feature? > I guess it may related about range, could help to check? > Thanks. > > Best regards, > Bichan.Lu Regards, Keith
