DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] TX-packet counter increased when no packets were actually sent
@ 2015-08-06 12:46 Stefan Binna
  2015-08-10 10:28 ` Bruce Richardson
  0 siblings, 1 reply; 2+ messages in thread
From: Stefan Binna @ 2015-08-06 12:46 UTC (permalink / raw)
  To: dev

Hi,

I have created a little testbed for DPDK testing.

NIC: Intel Gigabit 82574L (1-port)

The testbed for DPDK has following structure:

1) al40-118 (10.100.40.118/24): DUT running the DPDK application
2) al40-119 (10.100.40.119/24): Used for sending traffic to al40-118
3) al40-111 (10.100.40.111/24): Used to sniff the traffic send on the 
network

All three devices are connected via a hub and use the network 
10.100.40.1/24.

*Test:* Ping the DUT and review network traffic

At al40-119 an ARP-Table-Entry was created and the device al40-118 was 
pinged:

arp -s 10.100.40.118 68:05:ca:37:51:75
ping 10.100.40.118

On al40-118 the application testpmd was started with following parameters:

./x86_64-native-linuxapp-gcc/build/app/test-pmd/testpmd -c 0xf -n 4 -- -i --portmask=0x1 --nb-cores=2 --port-topology=chained

After start of the testpmd application the ports were started and after 
a while stopped:

start #wait a while due to testduration
stop

What's interesting is, that the TX-packet counter in the output of the 
"stop" command had the same value as the RX-packet counter. But the 
actual traffic on the network sniffed with Wireshark only showed the 
ping request but never a response on any layer (not even L2).

Sample output of the "stop" command:

Telling cores to stop...
Waiting for lcores to finish...

   ---------------------- Forward statistics for port 0  ----------------------
   RX-packets: 2              RX-dropped: 0             RX-total: 2
   TX-packets: 2              TX-dropped: 0             TX-total: 2
   ----------------------------------------------------------------------------

   +++++++++++++++ Accumulated forward statistics for all ports+++++++++++++++
   RX-packets: 2              RX-dropped: 0             RX-total: 2
   TX-packets: 2              TX-dropped: 0             TX-total: 2
   ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Done.
Stopping port 0...done

Could you tell me why the TX-packet counter increased when actually no 
packets were sent out to the 10.100.40.1 network or in other words, 
where have the packets been sent out?
And is it even possible to set the same port for RX and TX?

Thanks!

Regards, Stefan.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [dpdk-dev] TX-packet counter increased when no packets were actually sent
  2015-08-06 12:46 [dpdk-dev] TX-packet counter increased when no packets were actually sent Stefan Binna
@ 2015-08-10 10:28 ` Bruce Richardson
  0 siblings, 0 replies; 2+ messages in thread
From: Bruce Richardson @ 2015-08-10 10:28 UTC (permalink / raw)
  To: Stefan Binna; +Cc: dev

On Thu, Aug 06, 2015 at 02:46:53PM +0200, Stefan Binna wrote:
> Hi,
> 
> I have created a little testbed for DPDK testing.
> 
> NIC: Intel Gigabit 82574L (1-port)
> 
> The testbed for DPDK has following structure:
> 
> 1) al40-118 (10.100.40.118/24): DUT running the DPDK application
> 2) al40-119 (10.100.40.119/24): Used for sending traffic to al40-118
> 3) al40-111 (10.100.40.111/24): Used to sniff the traffic send on the
> network
> 
> All three devices are connected via a hub and use the network
> 10.100.40.1/24.
> 
> *Test:* Ping the DUT and review network traffic
> 

The use of ping implies the presence of an IP protocol stack to respond to
that ping. Testpmd included no protocol stack support so can't respond to the
ping request.

> At al40-119 an ARP-Table-Entry was created and the device al40-118 was
> pinged:
> 
> arp -s 10.100.40.118 68:05:ca:37:51:75
> ping 10.100.40.118
> 
> On al40-118 the application testpmd was started with following parameters:
> 
> ./x86_64-native-linuxapp-gcc/build/app/test-pmd/testpmd -c 0xf -n 4 -- -i --portmask=0x1 --nb-cores=2 --port-topology=chained
> 
> After start of the testpmd application the ports were started and after a
> while stopped:
> 
> start #wait a while due to testduration
> stop
> 
> What's interesting is, that the TX-packet counter in the output of the
> "stop" command had the same value as the RX-packet counter. But the actual
> traffic on the network sniffed with Wireshark only showed the ping request
> but never a response on any layer (not even L2).
> 
> Sample output of the "stop" command:
> 
> Telling cores to stop...
> Waiting for lcores to finish...
> 
>   ---------------------- Forward statistics for port 0  ----------------------
>   RX-packets: 2              RX-dropped: 0             RX-total: 2
>   TX-packets: 2              TX-dropped: 0             TX-total: 2
>   ----------------------------------------------------------------------------
> 
>   +++++++++++++++ Accumulated forward statistics for all ports+++++++++++++++
>   RX-packets: 2              RX-dropped: 0             RX-total: 2
>   TX-packets: 2              TX-dropped: 0             TX-total: 2
>   ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> Done.
> Stopping port 0...done
> 
> Could you tell me why the TX-packet counter increased when actually no
> packets were sent out to the 10.100.40.1 network or in other words, where
> have the packets been sent out?

Packets were sent out by the DUT. However, those packets weren't ping responses,
they were the ping requests themselves being forwarded. That's why they showed
up in your wireshark track on the receiving side.

/Bruce

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-08-10 10:28 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-06 12:46 [dpdk-dev] TX-packet counter increased when no packets were actually sent Stefan Binna
2015-08-10 10:28 ` Bruce Richardson

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).