Re: [dpdk-dev] phantom old packets received in new mbuf

[Helmut Sim <simhelmut@gmail.com>]

The CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG and CONFIG_RTE_LIBRTE_MBUF_DEBUG didn't
provide any input, so I also added the CONFIG_RTE_LIBRTE_ETHDEV_DEBUG and
CONFIG_RTE_LIBRTE_IGB_PMD.

below is a sample log showing the problem, though I don't see any clue in
the logs.
in this case pkt 58509 is placed at the place of pkt 58637...
I also noted that the diff between the two packets is 128, and this is the
case in most of the cases where it happens...
the rx_id of the phantom pkt (58509) is 141 (port_id=0 queue_id=0 rx_id=141
staterr=0x3 pkt_len=146)

.....still digging

port_id=0 queue_id=0 rx_id=264 staterr=0x3 pkt_len=146


PMD: eth_igb_recv_pkts():

port_id=0 queue_id=0 rx_id=265 staterr=0x3 pkt_len=146


PMD: eth_igb_recv_pkts():

port_id=0 queue_id=0 rx_id=266 staterr=0x3 pkt_len=146


PMD: eth_igb_recv_pkts():

port_id=0 queue_id=0 rx_id=267 staterr=0x3 pkt_len=146


PMD: eth_igb_recv_pkts(): port_id=0 queue_id=0 rx_tail=268 nb_hold=4 nb_rx=4


IM_LOG_VFLOWCOM: input: START_10 58632

IM_LOG_VFLOWCOM: input: START_10 58633

IM_LOG_VFLOWCOM: input: START_10 58634

IM_LOG_VFLOWCOM: input: START_10 58635

PMD: eth_igb_recv_pkts():

port_id=0 queue_id=0 rx_id=268 staterr=0x3 pkt_len=146


PMD: eth_igb_recv_pkts():

port_id=0 queue_id=0 rx_id=269 staterr=0x3 pkt_len=146


PMD: eth_igb_recv_pkts():

port_id=0 queue_id=0 rx_id=270 staterr=0x3 pkt_len=146


PMD: eth_igb_recv_pkts():

port_id=0 queue_id=0 rx_id=271 staterr=0x3 pkt_len=146


PMD: eth_igb_recv_pkts(): port_id=0 queue_id=0 rx_tail=272 nb_hold=4 nb_rx=4


IM_LOG_VFLOWCOM: input: START_10 58636

IM_LOG_VFLOWCOM: input: START_10 58509

IM_LOG_VFLOWCOM: wrong pkt number arrived from burst 4, expected 58637 but
got 58509

IM_LOG_VFLOWCOM: input: START_10 58638

IM_LOG_VFLOWCOM: input: START_10 58639

PMD: eth_igb_recv_pkts():

port_id=0 queue_id=0 rx_id=272 staterr=0x3 pkt_len=146


PMD: eth_igb_recv_pkts():

port_id=0 queue_id=0 rx_id=273 staterr=0x3 pkt_len=146


PMD: eth_igb_recv_pkts():

port_id=0 queue_id=0 rx_id=274 staterr=0x3 pkt_len=146


PMD: eth_igb_recv_pkts():

port_id=0 queue_id=0 rx_id=275 staterr=0x3 pkt_len=146


PMD: eth_igb_recv_pkts(): port_id=0 queue_id=0 rx_tail=276 nb_hold=4 nb_rx=4


IM_LOG_VFLOWCOM: input: START_10 58640

IM_LOG_VFLOWCOM: input: START_10 58641

IM_LOG_VFLOWCOM: input: START_10 58642

IM_LOG_VFLOWCOM: input: START_10 58643



On Wed, Jul 16, 2014 at 3:36 PM, Helmut Sim <simhelmut@gmail.com> wrote:

> I will try it though I hope the amount of logs won't affect the result.
> while analyzing the wireshark captures I noted that the packet i supposed
> to capture arrives in a short time after the one before.
> for example, here is a time between the consecutive transmitted packets:
> 0.000050000 PKT 12201
> 0.000050000 PKT 12202
> 0.000050000 PKT 12203
> 0.000050000 PKT 12204
> 0.000050000 PKT 12205
> 0.000050000 PKT 12206
> 0.000020000 PKT 12207 ==> though this one was received at the app as "PKT
> 12202"
> 0.000050000 PKT 12208
>
> note that the problematic case was transmitted in a very short time after
> its previous one. this is also the case in other problematic cases.
>
> is there any way to configure ethernet IFG (Interf Frame Gap)?
>
> Thanks,
>
>
> On Wed, Jul 16, 2014 at 3:18 PM, Olivier MATZ <olivier.matz@6wind.com>
> wrote:
>
>> Hello Helmut,
>>
>>
>> 2014-07-16 13:56, Helmut Sim:
>>
>>> then i see that from time to time i get a packet that was already
>>>> received
>>>> earlier instead of receiving the expected packet.
>>>> the output is:
>>>> PKT 12201
>>>> PKT 12202
>>>> PKT 12203
>>>> PKT 12204
>>>> PKT 12205
>>>> PKT 12206
>>>> PKT 12202
>>>> PKT 12208
>>>>
>>>> total received pkts is identical to the total delivered pkts, but part
>>>> of
>>>> the pkts are being received twice...
>>>>
>>>
>> Enabling CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG and
>> CONFIG_RTE_LIBRTE_MBUF_DEBUG could help you to track
>> double free or corruptions.
>>
>> Regards,
>> Olivier
>>
>>
>