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 at 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 at 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 at dpdk.org] On Behalf Of Wiles, Keith >Sent: Tuesday, November 3, 2015 6:33 AM >To: Van Haaren, Harry; ???; dev at 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 at intel.com> wrote: > >>Hi Keith, >> >>> From: dev [mailto:dev-bounces at 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
