DPDK patches and discussions
 help / color / mirror / Atom feed
From: Newman Poborsky <newman555p@gmail.com>
To: dev@dpdk.org
Subject: Re: [dpdk-dev] issues with packets bigger than 1500 bytes
Date: Tue, 31 Mar 2015 15:33:49 +0200	[thread overview]
Message-ID: <20150331133348.GA11375@fedex> (raw)
In-Reply-To: <20150330094416.GA22583@fedex>

Hi again,

I tried setting MTU to larger value and I get really weird behaviour - statistics now show that there are no more errors, but after just a few minutes I get a segfault while calling rte_pktmbuf_free():
#0  0x00000000004202fc in rte_atomic16_add_return (v=0xffffffffffffff94, inc=-1) at /opt/dpdk-1.8.0/build/include/generic/rte_atomic.h:247
247             return __sync_add_and_fetch(&v->cnt, inc);
(gdb) bt
#0  0x00000000004202fc in rte_atomic16_add_return (v=0xffffffffffffff94, inc=-1) at /opt/dpdk-1.8.0/build/include/generic/rte_atomic.h:247
#1  0x0000000000420414 in rte_mbuf_refcnt_update (m=0xffffffffffffff80, value=-1) at /opt/dpdk-1.8.0/build/include/rte_mbuf.h:371
#2  0x00000000004205e4 in __rte_pktmbuf_prefree_seg (m=0x7f773ff1ce80) at /opt/dpdk-1.8.0/build/include/rte_mbuf.h:770
#3  rte_pktmbuf_free_seg (m=0x7f773ff1ce80) at /opt/dpdk-1.8.0/build/include/rte_mbuf.h:793
#4  rte_pktmbuf_free (m=0x7f773ff1ce80) at /opt/dpdk-1.8.0/build/include/rte_mbuf.h:816

Is there any reason why changing MTU would cause this?  

With packets smaller than 1500 bytes and standard MTU, application is stable and there are no problems with calls to rte_pktmbuf_free(). Application is also stable with packets larger than 1500 bytes and standard MTU, but as I said, there are a lot of received errors. 

BR,
Newman

On Mon, Mar 30, 2015 at 12:52:22PM +0200, Newman Poborsky wrote:
> Hi,
> 
> I'm having some problems with dpdk on links that have packets bigger
> than 1500bytes. Some packets that are receieved are around 4K, and
> some are 9k jumbo frames.
> 
> When using testpmd app, I can see a lot of RX-errors (both RX-missed and RX-badlen). When I set max packet length to 9000, RX-badlen counter stops increasing, but RX-missed still keeps growing.
> 
> What is the proper way to deal with jumbo frames?
> 
> I tried setting MTU to 9k, but this fails. From what I can see, you have to pass additional parameter to mp_init callback in rte_mempool_create(). Is this right?
> 
> I'm not sure should I just set max packet length (like in testpmd example app), or should I (also) set MTU? Is this actually related to the original problem of having a lot of RX-missed packets?
> 
> If I missed some documentation related to jumbo frames and MTU, I apologize, please point me to it.
> 
> Any help is appreciated.
> 
> Thank you,
> 
> Newman P.

      reply	other threads:[~2015-03-31 13:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-30 10:52 Newman Poborsky
2015-03-31 13:33 ` Newman Poborsky [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150331133348.GA11375@fedex \
    --to=newman555p@gmail.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).