* [dpdk-dev] rte_pktmbuf_alloc fails @ 2014-04-01 11:08 Meir Tseitlin 2014-04-01 11:53 ` Meir Tseitlin 0 siblings, 1 reply; 7+ messages in thread From: Meir Tseitlin @ 2014-04-01 11:08 UTC (permalink / raw) To: dev Hi, I modified l2fwd example to "inject" additional Ethernet packets into the flow by allocating them with rte_pktmbuf_alloc. I do succeed to call rte_pktmbuf_alloc when none (or almost none) packets where forwarded since application start, but it fails when application is busy handling traffic (even light traffic). Following Intel developers guide suggestion about thread safety, I am calling this function within the same CPU core I am about to send the packet. Any ideas? Thanks Meir Tseitlin ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] rte_pktmbuf_alloc fails 2014-04-01 11:08 [dpdk-dev] rte_pktmbuf_alloc fails Meir Tseitlin @ 2014-04-01 11:53 ` Meir Tseitlin 2014-04-07 7:26 ` Olivier MATZ 0 siblings, 1 reply; 7+ messages in thread From: Meir Tseitlin @ 2014-04-01 11:53 UTC (permalink / raw) To: dev I think I found the problem - it was solved by manually calling rte_pktmbuf_free for each packet. It seems that rte_pktmbuf_free is not automatically called from within rte_eth_tx_burst if packets are sent to pcap device. Is it possible? On Tue, Apr 1, 2014 at 2:08 PM, Meir Tseitlin <mirots@gmail.com> wrote: > Hi, > > I modified l2fwd example to "inject" additional Ethernet packets into the > flow by allocating them with rte_pktmbuf_alloc. > > I do succeed to call rte_pktmbuf_alloc when none (or almost none) packets > where forwarded since application start, but it fails when application is > busy handling traffic (even light traffic). > > Following Intel developers guide suggestion about thread safety, I am > calling this function within the same CPU core I am about to send the > packet. > > Any ideas? > > Thanks > Meir Tseitlin > -- Kind regards, *Meir Tseitlin* Software architect*Mobile:* +972.54.7647417 *Fax:* +972.72.2812365 *Email:* meir.tech@gmail.com *http://il.linkedin.com/in/meirts <http://il.linkedin.com/in/meirts>* *Independent consultant* <http://maps.google.com/maps?q=&hl=en> See who we know in common<http://www.linkedin.com/e/wwk/6408776/?hs=false&tok=2g4qg82N8Sb5U1>Want a signature like this?<http://www.linkedin.com/e/sig/6408776/?hs=false&tok=20mz9jA_USb5U1> ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] rte_pktmbuf_alloc fails 2014-04-01 11:53 ` Meir Tseitlin @ 2014-04-07 7:26 ` Olivier MATZ 2014-04-07 8:53 ` Ananyev, Konstantin 0 siblings, 1 reply; 7+ messages in thread From: Olivier MATZ @ 2014-04-07 7:26 UTC (permalink / raw) To: dev; +Cc: Meir Tseitlin Hi Meir, On Tuesday, April 01, 2014 02:53:47 PM Meir Tseitlin wrote: > I think I found the problem - it was solved by manually calling > rte_pktmbuf_free for each packet. > It seems that rte_pktmbuf_free is not automatically called from > within rte_eth_tx_burst if packets are sent to pcap device. By looking at the eth_pcap_tx(pkts, nb_pkts) function, I think it may not work properly. I think it should return nb_pkts instead of num_tx. Indeed, if pcap_sendpacket() fails -- I don't know in which case it can occur -- the function will return a number lower than nb_pkts, causing a caller like l2fwd_send_burst() to free some mbufs. But all mbufs are already freed by eth_pcap_tx(). I don't know if it's related to your problem but it may help. Regards, Olivier ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] rte_pktmbuf_alloc fails 2014-04-07 7:26 ` Olivier MATZ @ 2014-04-07 8:53 ` Ananyev, Konstantin 2014-04-17 15:00 ` Thomas Monjalon 0 siblings, 1 reply; 7+ messages in thread From: Ananyev, Konstantin @ 2014-04-07 8:53 UTC (permalink / raw) To: dev Hi, Yep indeed, there is a bug in eth_pcap_tx() that can cause mbuf corruption. I think it should be something like that instead: --- a/lib/librte_pmd_pcap/rte_eth_pcap.c +++ b/lib/librte_pmd_pcap/rte_eth_pcap.c @@ -205,8 +205,9 @@ eth_pcap_tx(void *queue, mbuf = bufs[i]; ret = pcap_sendpacket(tx_queue->pcap, (u_char*) mbuf->pkt.data, mbuf->pkt.data_len); - if(likely(!ret)) - num_tx++; + if(unlikely(ret != 0)) + break; + num_tx++; rte_pktmbuf_free(mbuf); } Thanks Konstantin -----Original Message----- From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier MATZ Sent: Monday, April 07, 2014 8:27 AM To: dev@dpdk.org Cc: Meir Tseitlin Subject: Re: [dpdk-dev] rte_pktmbuf_alloc fails Hi Meir, On Tuesday, April 01, 2014 02:53:47 PM Meir Tseitlin wrote: > I think I found the problem - it was solved by manually calling > rte_pktmbuf_free for each packet. > It seems that rte_pktmbuf_free is not automatically called from within > rte_eth_tx_burst if packets are sent to pcap device. By looking at the eth_pcap_tx(pkts, nb_pkts) function, I think it may not work properly. I think it should return nb_pkts instead of num_tx. Indeed, if pcap_sendpacket() fails -- I don't know in which case it can occur -- the function will return a number lower than nb_pkts, causing a caller like l2fwd_send_burst() to free some mbufs. But all mbufs are already freed by eth_pcap_tx(). I don't know if it's related to your problem but it may help. Regards, Olivier ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] rte_pktmbuf_alloc fails 2014-04-07 8:53 ` Ananyev, Konstantin @ 2014-04-17 15:00 ` Thomas Monjalon 2014-05-22 15:47 ` Thomas Monjalon 0 siblings, 1 reply; 7+ messages in thread From: Thomas Monjalon @ 2014-04-17 15:00 UTC (permalink / raw) To: Ananyev, Konstantin; +Cc: dev Hi Konstantin, 2014-04-07 08:53, Ananyev, Konstantin: > Yep indeed, there is a bug in eth_pcap_tx() that can cause mbuf corruption. > I think it should be something like that instead: > > --- a/lib/librte_pmd_pcap/rte_eth_pcap.c > +++ b/lib/librte_pmd_pcap/rte_eth_pcap.c > @@ -205,8 +205,9 @@ eth_pcap_tx(void *queue, > mbuf = bufs[i]; > ret = pcap_sendpacket(tx_queue->pcap, (u_char*) > mbuf->pkt.data, mbuf->pkt.data_len); > - if(likely(!ret)) > - num_tx++; > + if(unlikely(ret != 0)) > + break; > + num_tx++; > rte_pktmbuf_free(mbuf); > } Please could you send a patch with a commit log as described in http://dpdk.org/dev#send ? Thanks -- Thomas ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] rte_pktmbuf_alloc fails 2014-04-17 15:00 ` Thomas Monjalon @ 2014-05-22 15:47 ` Thomas Monjalon 2014-05-22 15:51 ` Ananyev, Konstantin 0 siblings, 1 reply; 7+ messages in thread From: Thomas Monjalon @ 2014-05-22 15:47 UTC (permalink / raw) To: Ananyev, Konstantin; +Cc: dev 2014-04-17 17:00, Thomas Monjalon: > Hi Konstantin, > > 2014-04-07 08:53, Ananyev, Konstantin: > > Yep indeed, there is a bug in eth_pcap_tx() that can cause mbuf > > corruption. > > I think it should be something like that instead: > > > > --- a/lib/librte_pmd_pcap/rte_eth_pcap.c > > +++ b/lib/librte_pmd_pcap/rte_eth_pcap.c > > @@ -205,8 +205,9 @@ eth_pcap_tx(void *queue, > > > > mbuf = bufs[i]; > > ret = pcap_sendpacket(tx_queue->pcap, (u_char*) > > > > mbuf->pkt.data, mbuf->pkt.data_len); > > - if(likely(!ret)) > > - num_tx++; > > + if(unlikely(ret != 0)) > > + break; > > + num_tx++; > > > > rte_pktmbuf_free(mbuf); > > > > } > > Please could you send a patch with a commit log as described in > http://dpdk.org/dev#send ? I think you haven't sent patch for this bug. Do you plan to do so? Thanks -- Thomas ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dpdk-dev] rte_pktmbuf_alloc fails 2014-05-22 15:47 ` Thomas Monjalon @ 2014-05-22 15:51 ` Ananyev, Konstantin 0 siblings, 0 replies; 7+ messages in thread From: Ananyev, Konstantin @ 2014-05-22 15:51 UTC (permalink / raw) To: Thomas Monjalon; +Cc: dev Hi Thomas, I planned to, but very unlikely that it would happen that week. Thanks Konstantin -----Original Message----- From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] Sent: Thursday, May 22, 2014 4:47 PM To: Ananyev, Konstantin Cc: dev@dpdk.org Subject: Re: [dpdk-dev] rte_pktmbuf_alloc fails 2014-04-17 17:00, Thomas Monjalon: > Hi Konstantin, > > 2014-04-07 08:53, Ananyev, Konstantin: > > Yep indeed, there is a bug in eth_pcap_tx() that can cause mbuf > > corruption. > > I think it should be something like that instead: > > > > --- a/lib/librte_pmd_pcap/rte_eth_pcap.c > > +++ b/lib/librte_pmd_pcap/rte_eth_pcap.c > > @@ -205,8 +205,9 @@ eth_pcap_tx(void *queue, > > > > mbuf = bufs[i]; > > ret = pcap_sendpacket(tx_queue->pcap, (u_char*) > > > > mbuf->pkt.data, mbuf->pkt.data_len); > > - if(likely(!ret)) > > - num_tx++; > > + if(unlikely(ret != 0)) > > + break; > > + num_tx++; > > > > rte_pktmbuf_free(mbuf); > > > > } > > Please could you send a patch with a commit log as described in > http://dpdk.org/dev#send ? I think you haven't sent patch for this bug. Do you plan to do so? Thanks -- Thomas ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-05-22 15:51 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-04-01 11:08 [dpdk-dev] rte_pktmbuf_alloc fails Meir Tseitlin 2014-04-01 11:53 ` Meir Tseitlin 2014-04-07 7:26 ` Olivier MATZ 2014-04-07 8:53 ` Ananyev, Konstantin 2014-04-17 15:00 ` Thomas Monjalon 2014-05-22 15:47 ` Thomas Monjalon 2014-05-22 15:51 ` Ananyev, Konstantin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).