DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Polehn, Mike A" <mike.a.polehn@intel.com>
To: "Wiles, Keith" <keith.wiles@intel.com>,
	"Van Haaren, Harry" <harry.van.haaren@intel.com>,
	??? <pnk003@naver.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] How can I calculate/estimate pps(packet per seocond) and bps(bit per second) in DPDK pktg
Date: Tue, 3 Nov 2015 21:55:29 +0000	[thread overview]
Message-ID: <745DB4B8861F8E4B9849C970520ABBF149750A1C@ORSMSX102.amr.corp.intel.com> (raw)
In-Reply-To: <690C215D-DB42-4523-912D-436115E0E7DE@intel.com>

Accessing registers on the NIC has very high access latency and will often stall the CPU in waiting for response 
especially with multiple register reads and high throughput packet data also being transferred. The size value was 
derived from the NIC writing a value to the descriptor table which as then written to the packet buffer. The 
bitrate calculation included the FCS/CRC has packet overhead and the packet size was 4 bytes short. 

The inclusion or exclusion of the FCS on receive might be a programmable option. For tx, it might be a flag set
in the TX descriptor table either use FCS in packet buffer or calculate it on the fly. Where you get the numbers
and initialization may affect the calculation. 

A very important rating for CPU is it's FLOPs performance. Most all modern CPUs do single cycle floating point 
multiplies (divides are done with shifts and adds and are clock per set bit in float mantissa or in int). Conversion 
to and from floating point are often done in parallel with other operations, which makes using integer math 
not always faster. Often additional checks for edge conditions and adjustments needed with integer 
processing loses the gain but all depends on exact algorithm and end scaling.  Being able to do high 
quality integer processing is a good skill, especially when doing work like signal processing.

-----Original Message-----
From: Wiles, Keith 
Sent: Tuesday, November 3, 2015 11:01 AM
To: Polehn, Mike A; Van Haaren, Harry; ???; dev@dpdk.org
Subject: Re: [dpdk-dev] How can I calculate/estimate pps(packet per seocond) and bps(bit per second) in DPDK pktg

On 11/3/15, 9:59 AM, "Polehn, Mike A" <mike.a.polehn@intel.com> wrote:

>I used the following code snip-it with the i40e device, with 1 second sample time had very high accuracy for IPv4 UDP packets:
>
>#define FLOWD_PERF_PACKET_OVERHEAD 24  /* CRC + Preamble + SOF + Interpacket gap */
>#define FLOWD_REF_NETWORK_SPEED   10e9
>
>double Ave_Bytes_per_Packet, Data_Rate, Net_Rate; uint64_t Bits; 
>uint64_t Bytes = pFlow->flow.n_bytes - pMatch_Prev->flow.n_bytes; 
>uint64_t Packets = pFlow->flow.n_packets - pMatch_Prev->flow.n_packets; 
>uint64_t Time_us = pFlow->flow.flow_time_us - 
>pMatch_Prev->flow.flow_time_us;
>
>if (Bytes == 0)
>	Ave_Bytes_per_Packet = 0.0;
>else
>	Ave_Bytes_per_Packet = ((double)Bytes / (double)Packets) + 4.0;
>
>Bits = (Bytes + (Packets*FLOWD_PERF_PACKET_OVERHEAD)) * 8; if (Bits == 
>0)
>	Data_Rate = 0.0;
>else
>	Data_Rate = (((double)Bits) / Time_us) * 1e6;
>
>if (Data_Rate == 0.0)
>	Net_Rate = 0.0;
>else
>	Net_Rate = Data_Rate / FLOWD_REF_NETWORK_SPEED;
>
>For packet rate: double pk_rate = (((double)Packets)/ 
>((double)Time_us)) * 1e6;
>
>To calculate elapsed time in DPDK app, used CPU counter (will not work if counter is being modified):
>
>Initialization:
>double flow_time_scale_us;
>...
>flow_time_scale_us = 1e6/rte_get_tsc_hz();
>
>Elapsed time (uSec) example: 
>
>elapse_us = (rte_rdtsc() - entry->tsc_first_packet) *
>	flow_time_scale_us; /* calc total elapsed us */

Looks reasonable I assume the n_bytes does not include FCS as is not the case with the NIC counters.

Also I decided to avoid using double’s in my code and just used 64bit registers and integer math :-) 

>
>-----Original Message-----
>From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wiles, Keith
>Sent: Tuesday, November 3, 2015 6:33 AM
>To: Van Haaren, Harry; ???; dev@dpdk.org
>Subject: Re: [dpdk-dev] How can I calculate/estimate pps(packet per 
>seocond) and bps(bit per second) in DPDK pktg
>
>On 11/3/15, 8:30 AM, "Van Haaren, Harry" <harry.van.haaren@intel.com> wrote:
>
>>Hi Keith,
>>
>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wiles, Keith
>><snip>
>>> Hmm, I just noticed I did not include the FCS bytes. Does the NIC 
>>> include FCS bytes in the counters? Need to verify that one and if not then it becomes a bit more complex.
>>
>>The Intel NICs count packet sizes inclusive of CRC / FCS, from eg the ixgbe/82599 datasheet:
>>"This register includes bytes received in a packet from the <Destination Address> field through the <CRC> field, inclusively."
>
>Thanks I assumed I had known that at the time :-)
>>
>>-Harry
>>
>
>
>Regards,
>Keith
>
>
>
>
>


Regards,
Keith





  reply	other threads:[~2015-11-03 21:55 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-03  6:25 최익성
2015-11-03 14:11 ` Wiles, Keith
2015-11-03 14:30   ` Van Haaren, Harry
2015-11-03 14:33     ` Wiles, Keith
2015-11-03 15:59       ` Polehn, Mike A
2015-11-03 19:00         ` Wiles, Keith
2015-11-03 21:55           ` Polehn, Mike A [this message]
2015-11-04  1:45         ` 최익성
2015-11-04 14:21           ` Polehn, Mike A
2015-11-04 23:58             ` 최익성
2015-11-03 22:05     ` Stephen Hemminger
2015-11-03 22:18       ` Kyle Larose
2015-11-03 23:28         ` Stephen Hemminger
2015-11-04 13:13           ` Kyle Larose

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=745DB4B8861F8E4B9849C970520ABBF149750A1C@ORSMSX102.amr.corp.intel.com \
    --to=mike.a.polehn@intel.com \
    --cc=dev@dpdk.org \
    --cc=harry.van.haaren@intel.com \
    --cc=keith.wiles@intel.com \
    --cc=pnk003@naver.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).