DPDK patches and discussions
 help / color / mirror / Atom feed
* [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).