test suite reviews and discussions
 help / color / mirror / Atom feed
From: Masoud Moshref Javadi <masood.moshref.j@gmail.com>
To: "Liu, Yong" <yong.liu@intel.com>, "dts@dpdk.org" <dts@dpdk.org>
Subject: Re: [dts] Packets reorder in the second pass on mempool
Date: Mon, 27 Jul 2015 10:59:20 -0700	[thread overview]
Message-ID: <55B67178.1060805@gmail.com> (raw)
In-Reply-To: <86228AFD5BCD8E4EBFD2B90117B5E81E10EAD7ED@SHSMSX103.ccr.corp.intel.com>

The NIC is E10G42BT X520-T2 and the rx queue has 256 and tx queue has 
512 entries.

I found out the problem was that the memory pool become empty. I thought 
based on the description of rte_eth_tx_burst, after the sending, the 
rte_mbufs should be freed and returned into the mempool.

Now I use rte_mempool_put_bulk() just after draining the batch of 
packets to get back mbufs into the pool and it works.

Thanks

On 7/27/2015 1:06 AM, Liu, Yong wrote:
> Hi Javadi,
> I think it's fine to send out issue to dev mailing list.
> Maybe there's no reply from people in community is just because of can't reproduce your issue.
> We need the NIC type and related rx/tx queue settings for reproduce your problem.
>
>> -----Original Message-----
>> From: dts [mailto:dts-bounces@dpdk.org] On Behalf Of Masoud Moshref Javadi
>> Sent: Saturday, July 25, 2015 6:04 AM
>> To: dts@dpdk.org
>> Subject: [dts] Packets reorder in the second pass on mempool
>>
>> Hi
>>
>> I'm new to dpdk and I hope you can solve my weird problem (I think I
>> sent this message to dev list by mistake. sorry)
>>
>> I see packet reordering correlated with the batchsize and mempool size.
>>
>> I have a very simple setting of a sender and a receiver connected with a
>> simple 10G switch.
>> The sender sends udp packets at 14.88MPPS and just puts a 32bit sequence
>> number in the udp packets.
>> The receiver reads packets and expects the packets to be in order.
>> However, the receiver sees packets in a reordered way like this (note
>> that it starts from 7808 in different runs):
>>
>> expected, seen , seen-expected
>> 7808, 7936 = 128
>> 7978, 8106 = 128
>> 8145, 8273 = 128
>> 8308, 8436 = 128
>> 8448, 8320 = -128
>> 8391, 8519 = 128
>> 8576, 8448 = -128
>> 8518, 8646 = 128
>> 8704, 8576 = -128
>> ....
>>
>> The batchsize at sender is 128.
>> The configuration of ports and mempools are similar to basicfwd.c in
>> basic forwarding example of dpdk.
>> Interestingly if I change the size of mempool, the beginning of packet
>> reordering changes from 7808.
>>
>> #define NUM_MBUFS 8192
>> #define MBUF_SIZE (1600 + sizeof(struct rte_mbuf) + RTE_PKTMBUF_HEADROOM)
>> #define MBUF_CACHE_SIZE 250
>> #define BURST_SIZE 128
>>
>> mbuf_pool = rte_mempool_create("MBUF_POOL",
>>                                           NUM_MBUFS * nb_ports,
>>                                           MBUF_SIZE,
>>                                           MBUF_CACHE_SIZE,
>>                                           sizeof(struct
>> rte_pktmbuf_pool_private),
>>                                           rte_pktmbuf_pool_init, NULL,
>>                                           rte_pktmbuf_init,      NULL,
>>                                           1,
>>                                           0);
>>
>> The main sender loop is as follows:
>>
>>     for (;pkts_num<target;) {
>>                            /* Get burst of RX packets, from first port of
>> pair. */
>>                            rte_mempool_sc_get_bulk(mbuf_pool,
>> (void**)&bufs, BURST_SIZE);
>>                            /* Send burst of TX packets, to second port of
>> pair. */
>>                            for (i=0; i< BURST_SIZE; i++){
>>                                    m = bufs[i];
>>                                    m->data_len = 60;
>>                                    m->pkt_len  = 60;
>>                                    rte_memcpy((uint8_t *)m->buf_addr +
>> m->data_off,bufpkt, 60);
>>                                    uint32_t * data = (uint32_t
>> *)(rte_ctrlmbuf_data(m) + data_offset);
>>                                    *data = pkts_num+i;
>>                            }
>>
>>                            uint16_t nb_tx = 0;
>>                            while (nb_tx < BURST_SIZE){
>>                                    nb_tx+= rte_eth_tx_burst(port, 0, bufs
>> + nb_tx, BURST_SIZE - nb_tx);
>>                            }
>>                            pkts_num += nb_tx;
>> }
>>
>> Regards

      reply	other threads:[~2015-07-27 17:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-24 22:03 Masoud Moshref Javadi
2015-07-27  8:06 ` Liu, Yong
2015-07-27 17:59   ` Masoud Moshref Javadi [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=55B67178.1060805@gmail.com \
    --to=masood.moshref.j@gmail.com \
    --cc=dts@dpdk.org \
    --cc=yong.liu@intel.com \
    /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).