date:20201217

Re: [vpp-dev] AVF TX bandwidth less than RX

2020-12-17 Thread Lijian Zhang



From: Damjan Marion (damarion) 
Sent: 2020年12月17日 23:44
To: Lijian Zhang 
Cc: vpp-dev ; nd 
Subject: Re: [vpp-dev] AVF TX bandwidth less than RX




On 17.12.2020., at 14:43, Lijian Zhang 
mailto:lijian.zh...@arm.com>> wrote:



From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Damjan Marion 
via lists.fd.io
Sent: 2020年12月17日 16:22
To: Lijian Zhang mailto:lijian.zh...@arm.com>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>; nd 
mailto:n...@arm.com>>
Subject: Re: [vpp-dev] AVF TX bandwidth less than RX





On 17.12.2020., at 09:16, Lijian Zhang 
mailto:lijian.zh...@arm.com>> wrote:

Hi Damjan,
When I was benchmarking AVF PMD driver with L3fwd and L2-xconnect cases, not 
all packets received via AVF input node ‘avf-input’ are transmitted out via AVF 
output node ‘eth1-tx’.
I have tried to increase the tx-queue-size of avf interface, but it does not 
help. Have checked VNET_DEVICE_CLASS_TX_FN (avf_device_class) (), but didn’t 
find software bottle-neck there.
Is this a normal behavior for XL710 VF interface, and does it mean VF PCIe DMA 
bandwidth in RX direction is higher than that in TX direction?

--L3fwd---
avf-inputpolling   2369637   606626968  
 0  1.30e1  255.99
eth1-output  active2369637   606626968  
 0  5.56e0  255.99
eth1-tx  active2369637   442718040  
 0  2.02e1  186.83
ethernet-input   active2369637   606626968  
 0  1.26e1  255.99
ip4-input-no-checksumactive2369637   606626968  
 0  1.91e1  255.99
ip4-lookup   active2369637   606626968  
 0  2.06e1  255.99
ip4-rewrite  active2369637   606626968  
 0  1.85e1  255.99

--L2-xconnect ---
avf-inputpolling   7342184   779122436  
 0  2.39e1  106.12
eth1-output  active7342123   779122436  
 0  6.67e0  106.12
eth1-tx  active7342123   429393137  
 0  3.23e1   58.48
ethernet-input   active7342123   779122436  
 0  1.37e1  106.12
l2-input active7342123   779122436  
 0  1.14e1  106.12
l2-outputactive7342123   779122436  
 0  6.19e0  106.12

What "show error" says?

If VPP was not able to enqueue packet to tx queue, it will bunp ‘no free slots’ 
counter.

[Lijian] Yes, it reports “no free tx slots”
vpp# clear errors
vpp# show errors
   Count  Node  Reason  
 Severity
   2539792  eth1-txno free tx slots 
   error
vpp# show errors
   Count  Node  Reason  
 Severity
   5547120  eth1-txno free tx slots 
   error

Yes, so looks like software is faster than hardware…. What is your Mpps rate?

[Lijian] 20.18Mpps for “l3fwd xl710 on x86 8268 turbo-off 2.9GHz”, and 
20.10Mpps for “l2-xconnect xl710 on x86 8268 turbo-off 2.9GHz”
l3fwd xl710 on x86 8268 turbo-off ---
// 20.18Mpps
avf-inputpolling557467   142711552  
 0  1.29e1  256.00
eth1-output  active 557467   142711552  
 0  6.99e0  256.00
eth1-tx  active 557467   124816512  
 0  1.95e1  223.89
ethernet-input   active 557467   142711552  
 0  1.53e1  256.00
ip4-input-no-checksumactive 557467   142711552  
 0  2.41e1  256.00
ip4-lookup   active 557467   142711552  
 0  2.55e1  256.00
ip4-rewrite  active 557467   142711552  
 0  2.29e1  256.00
cross-connect xl710 on x86 8268 turbo-off 
---
// 20.10Mpps
avf-inputpolling   1092996   160940736  
 0  2.00e1  147.25
eth1-output  active1092996   160940736  
 0  7.46e0  147.25
eth1-tx  active1092996

Re: [vpp-dev] Core Load Calculation

2020-12-17 Thread bjeremy32

I think I was going to try and write something more acceptable to be merged, 
but if you end up getting it working, then you may want to offer that as a 
solution to the community.

From: vpp-dev@lists.fd.io  On Behalf Of Ramkumar
Sent: Thursday, December 17, 2020 3:56 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Core Load Calculation

Thanks bjeremy32 for sharing the patch! 
As mentioned by Dave, I have implemented load calculation in a plugin. I can 
try to reevaluate my implementation with yours as reference. Will let you know 
if I get it working. 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18397): https://lists.fd.io/g/vpp-dev/message/18397
Mute This Topic: https://lists.fd.io/mt/78980301/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] VPP Vectors/Call rate #dpdk

2020-12-17 Thread Merve

Hi everyone,
When I send mixed traffic in varying sizes ( usually larger than 64 bytes ) 
packets in line rate, miss rates is low and vectors/call is low.

But when i send 64 byte udp packets (16K flow) in line rate, i has high miss 
rate and  Vector/call is high. So vpp cant prosess enough packet.
Something is wrong here? Anyone have any suggestions on this matter?
(mixed traffic in varying sizes ( usually larger than 64 bytes ) packets)

Thread 1 vpp_wk_0 (lcore 2)
Time 173.8, 10 sec internal node vector rate 0.00 loops/sec 1430309.12
 vector rates in 6.4933e5, out 6.2164e5, drop 2.8775e-2, punt 0.e0
Name State Calls  Vectors
Suspends Clocks   Vectors/Call
TenGigabitEthernet1/0/0-output   active138831859870375  
 0  9.54e1   43.12
TenGigabitEthernet1/0/0-tx   active138831755058452  
 0  2.60e2   39.66
TenGigabitEthernet1/0/1-output   active132430252957837  
 0  1.05e2   39.99
TenGigabitEthernet1/0/1-tx   active132430152957836  
 0  2.47e2   39.99
arp-inputactive  4   7  
 0  2.89e31.75
arp-replyactive  4   7  
 0  2.13e41.75
dpdk-input   polling  95342497   112828215  
 0  1.01e31.18
drop active  5   5  
 0  5.07e31.00
error-drop   active  5   5  
 0  4.61e31.00
ethernet-input   active2341216   112828215  
 0  3.22e2   48.19
interface-output active  3   4  
 0  4.19e31.33
ip4-input-no-checksumactive1598737   112828208  
 0  1.98e2   70.57
ip4-load-balance active1598737   112828208  
 0  1.69e2   70.57
ip4-lookup   active1598737   112828208  
 0  3.14e2   70.57
ip4-rewrite  active1598737   112828208  
 0  8.14e2   70.57
unix-epoll-input polling 93018   0  
 0  1.69e30.00
---
Thread 2 vpp_wk_1 (lcore 3)
Time 173.8, 10 sec internal node vector rate 0.00 loops/sec 1454623.01
 vector rates in 6.4994e5, out 6.2287e5, drop 0.e0, punt 0.e0
Name State Calls  Vectors
Suspends Clocks   Vectors/Call
TenGigabitEthernet1/0/0-output   active122764159821627  
 0  9.79e1   48.73
TenGigabitEthernet1/0/0-tx   active122764155117639  
 0  2.63e2   44.89
TenGigabitEthernet1/0/1-output   active114650253113046  
 0  1.07e2   46.33
TenGigabitEthernet1/0/1-tx   active114650253113046  
 0  2.51e2   46.33
dpdk-input   polling  94368347   112934673  
 0  9.87e21.19
ethernet-input   active2012117   112934673  
 0  2.85e2   56.13
ip4-input-no-checksumactive1435435   112934673  
 0  2.00e2   78.68
ip4-load-balance active1435435   112934673  
 0  1.73e2   78.68
ip4-lookup   active1435435   112934673  
 0  3.16e2   78.68
ip4-rewrite  active1435435   112934673  
 0  8.59e2   78.68
unix-epoll-input polling 92067   0  
 0  1.68e30.00
---
Thread 3 vpp_wk_2 (lcore 4)
Time 173.8, 10 sec internal node vector rate 0.00 loops/sec 1456729.77
 vector rates in 6.3335e5, out 6.1369e5, drop 0.e0, punt 0.e0
Name State Calls  Vectors
Suspends Clocks   Vectors/Call
TenGigabitEthernet1/0/0-output   active205908658390205  
 0  9.89e1   28.36
TenGigabitEthernet1/0/0-tx   active205908654975223  
 0  2.49e2   26.69
TenGigabitEthernet1/0/1-output   active

Re: [vpp-dev] Core Load Calculation

2020-12-17 Thread Ramkumar

Thanks bjeremy32 for sharing the patch!
As mentioned by Dave, I have implemented load calculation in a plugin. I can 
try to reevaluate my implementation with yours as reference. Will let you know 
if I get it working.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18395): https://lists.fd.io/g/vpp-dev/message/18395
Mute This Topic: https://lists.fd.io/mt/78980301/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Core Load Calculation

2020-12-17 Thread bjeremy32

If you want to refactor it in a way to fit the code architecture better, feel 
free.

From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach
Sent: Thursday, December 17, 2020 1:43 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Core Load Calculation

As the sole remaining original vpp author and the area maintainer, I have 
abundant experience dealing with src/vlib/{main.c, threads.c}. 

In every case to date, we’ve been able to leverage existing callback hooks, or 
to add callback hooks so that folks can do what they need to do (e.g. from 
plugins) without modifying the core engine.

Might we manage to take that approach here? It’s in everyone’s interest to do 
so...

Thanks... Dave

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18394): https://lists.fd.io/g/vpp-dev/message/18394
Mute This Topic: https://lists.fd.io/mt/78980301/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Core Load Calculation

2020-12-17 Thread Dave Barach

As the sole remaining original vpp author and the area maintainer, I have 
abundant experience dealing with src/vlib/{main.c, threads.c}.

In every case to date, we’ve been able to leverage existing callback hooks, or 
to add callback hooks so that folks can do what they need to do (e.g. from 
plugins) without modifying the core engine.

Might we manage to take that approach here? It’s in everyone’s interest to do 
so...

Thanks... Dave

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18393): https://lists.fd.io/g/vpp-dev/message/18393
Mute This Topic: https://lists.fd.io/mt/78980301/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] move to clang-format

2020-12-17 Thread Dave Barach

+1. Wholesale reformatting of existing files is to be avoided. 

 

Support for per-file or per-directory automated code formatting would be great! 

 

Religious debates about coding style will be resolved one day after there’s 
peace in Palestine. Let’s not go there. OK?

 

Thanks... Dave

 

 

From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
lists.fd.io
Sent: Thursday, December 17, 2020 1:29 PM
To: Jon Loeliger via lists.fd.io 
Cc: vpp-dev 
Subject: Re: [vpp-dev] move to clang-format

 

 


On 17.12.2020., at 19:06, Jon Loeliger via lists.fd.io 
mailto:jdl=netgate@lists.fd.io> > wrote:



 

 

On Sun, Dec 13, 2020 at 6:15 AM Damjan Marion via lists.fd.io 
  mailto:me@lists.fd.io> > 
wrote:


Hi,

I was playing a bit with clang-format as replacement to gnu indent which we use 
today[1].

While it is impossible to render exact same result like gnu indent, good thing 
is that clang-format can be used only on lines which are changed in the diff so 
no major reformat is needed. My patch deos exactly that.

 

I would welcome any change away from the absolutely horrendous Gnu coding style!

 

 

And what would be good alternative in your view?

 

I doubt we want to reformat whole codebase, eventually allow alternative for 
new files in the repo...

 

— 

Damjan

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18392): https://lists.fd.io/g/vpp-dev/message/18392
Mute This Topic: https://lists.fd.io/mt/78925374/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] move to clang-format

2020-12-17 Thread Damjan Marion via lists.fd.io



> 
> On 17.12.2020., at 19:06, Jon Loeliger via lists.fd.io 
>  wrote:
> 
> 
> 
> 
>> On Sun, Dec 13, 2020 at 6:15 AM Damjan Marion via lists.fd.io 
>>  wrote:
>> 
>> Hi,
>> 
>> I was playing a bit with clang-format as replacement to gnu indent which we 
>> use today[1].
>> 
>> While it is impossible to render exact same result like gnu indent, good 
>> thing is that clang-format can be used only on lines which are changed in 
>> the diff so no major reformat is needed. My patch deos exactly that.
> 
> I would welcome any change away from the absolutely horrendous Gnu coding 
> style!


And what would be good alternative in your view?

I doubt we want to reformat whole codebase, eventually allow alternative for 
new files in the repo...

— 
Damjan


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18391): https://lists.fd.io/g/vpp-dev/message/18391
Mute This Topic: https://lists.fd.io/mt/78925374/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Multicast packets sent via memif when rule says to forward through another interface

2020-12-17 Thread steven luong via lists.fd.io

show interface displays the interface’s admin state.
show hardware displays the interface’s operational link state.
The link down is likely caused by memif configuration error. Please check your 
configuration on both sides to make sure they match. Some tips to debug,
show memif
set logging class memif plugin level debug
show log

As to why traffic is forwarded to the memif interface, who knows what you got 
in the mfib table. You need to look into the mfib table and check.

Steven

From:  on behalf of "tahir.a.sangli...@gmail.com" 

Date: Wednesday, December 16, 2020 at 1:27 PM
To: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] Multicast packets sent via memif when rule says to 
forward through another interface

Thank you for your reply!
yes the memif interface is down, in $sh hardware, it shows up in $sh int. what 
could be the reason for this discrepancy?
still not clear why its choosing memif when mfib rule says forward on 
HundredGigabitEthernet12/0/0.501

ip mroute add ff38:23:2001:5b0:2000::8000/128 via tuntap-0 Accept

ip mroute add ff38:23:2001:5b0:2000::8000/128 via 
HundredGigabitEthernet12/0/0.501 Forward
vpp#sh hardware
memif81/0 21down  memif81/0
  Link speed: unknown
  memif-ip
  MEMIF interface
 instance 15
vpp#sh int
memif81/0 23 up  9000/0/0/0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18390): https://lists.fd.io/g/vpp-dev/message/18390
Mute This Topic: https://lists.fd.io/mt/79043315/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] move to clang-format

2020-12-17 Thread Jon Loeliger via lists.fd.io

On Sun, Dec 13, 2020 at 6:15 AM Damjan Marion via lists.fd.io  wrote:

>
> Hi,
>
> I was playing a bit with clang-format as replacement to gnu indent which
> we use today[1].
>
> While it is impossible to render exact same result like gnu indent, good
> thing is that clang-format can be used only on lines which are changed in
> the diff so no major reformat is needed. My patch deos exactly that.
>

I would welcome any change away from the absolutely horrendous Gnu coding
style!

jdl

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18389): https://lists.fd.io/g/vpp-dev/message/18389
Mute This Topic: https://lists.fd.io/mt/78925374/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Core Load Calculation

2020-12-17 Thread bjeremy32

Ramkumar,

 

Attached are the patches to 20.05 to implement the cpu usage… I think this was 
all that was changed. You may want to hand merge them instead of applying the 
patches though, It may be ok… but im not 100% other lines were not touched.

 

You will be able to view cpu usage with:  ‘watch vppctl show threads’. 

 

As I said, it seems to work rather well for us. We run in various 
configurations. But your particular case may be different and require some 
other tweaking, but this just illustrates the idea… 

 

1.  Grouped no handoff - all rcv queues handled by a single core, no handoff
2.  Grouped with handoff
3.  Separated cores with handoff – each separate core handles a rcv queue, 
handoffs work to a separate thread
4.  Separated cores no handoff

 

In all cases, it seems the cpu usage metric is fairly accurate. We notice as 
pps increases for us packet start dropping at about 90%. And for worker threads 
(not in poll mode) we could compare the cpu usage using htop with our patch… it 
was within 1-2% which was good enough…

 

 

From: vpp-dev@lists.fd.io  On Behalf Of bjeremy32 via 
lists.fd.io
Sent: Wednesday, December 16, 2020 11:14 AM
To: 'Ramkumar B' 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Core Load Calculation

 

If it will help, I will share my patch as soon as I get authorization from my 
corporate overlords.

 

From: Ramkumar B mailto:ramukmar1...@gmail.com> > 
Sent: Wednesday, December 16, 2020 11:08 AM
To: bjerem...@gmail.com  
Cc: vpp-dev@lists.fd.io  
Subject: Re: [vpp-dev] Core Load Calculation

 




I got your idea. Thanks for taking time to clarify. I kind of tried the same 
but in vain. I think I will look into this solution again.

 

On Wed, Dec 16, 2020 at 10:21 PM mailto:bjerem...@gmail.com> > wrote:

In dispatch_node, before we call node->function any accumulated clock cycles 
are counted toward idle, after the node->function returns if ( 
(VLIB_NODE_TYPE_PRE_INPUT || VLIB_NODE_TYPE_INPUT) && number of packets 
processed == 0) then we count it as idle, else we count it as busy.

 

 

From: Ramkumar B mailto:ramukmar1...@gmail.com> > 
Sent: Wednesday, December 16, 2020 10:27 AM
To: bjerem...@gmail.com  
Cc: vpp-dev@lists.fd.io  
Subject: Re: [vpp-dev] Core Load Calculation

 

The processing of the rx queue is counted toward IDLE

Please explain what kind of processing. We are not doing any such rx processing 
separately. For us, the ring_dequeue_burst's cycles is negligible compared to 
processing cycles.

 

On Wed, Dec 16, 2020 at 8:54 PM mailto:bjerem...@gmail.com> > wrote:

Nope… the math works out… nothing goes to 0… we are incrementing both IDLE and 
BUSY. The processing of the rx queue is counted toward IDLE… In a completely 
idle system, the cpu usage falls to 0… as traffic ramps up it will go further 
positive based on pps, and as it goes to idle again it will go down to 0…

 

 

From: Damjan Marion mailto:dmar...@me.com> > 
Sent: Wednesday, December 16, 2020 3:00 AM
To: bjerem...@gmail.com  
Cc: Nick Zavaritsky mailto:nick.zavarit...@emnify.com> >; ramukmar1...@gmail.com 
 ; vpp-dev@lists.fd.io 
 
Subject: Re: [vpp-dev] Core Load Calculation

 

 

 

On 16.12.2020., at 05:45, bjerem...@gmail.com   
wrote:

 

What we did was to count clock cycles (timestamps) spent processing the nodes, 
call this busy, and count the clock cycles spent elsewhere, call this idle. And 
then simply output (busy/(busy + idle). We did this per thread and stored the 
calculations globally. We then outputted the calculations on the ‘vppctl show 
thread’ cli.

 

This doesnt make lot of sense. Each input node is spending cycles to process rx 
queue, and out of that processing there may be zero or non-zero packets. So in 
completelly idle system according to your math result will be far away from 0.

 

 

 

This created a nice cpu usage metric that seems pretty accurate for io and 
worker threads…

 

What do you mean by io threads?

 

We compared this to something like htop for the worker threads and its within 
~1%, the io cores seem the same as we can see the usage go to about 80-90% when 
we start dropping packets. We are able to calculate the approx. PPS for a given 
system configuration.

 

It actually wasn’t a lot of effort. I think only three files were touched. 1. A 
new header file o create the global data structure to hold the clock cycle 
counts and associated macros to init and update the structures. 2. Vlib/main.c 
to instrument the main loop and collect the busy/idle clock cycles 3. Vlib 
threads_cli.c as show threads fn was used to output the cpu usage per thread.

 

From: vpp-dev@lists.fd.io   mailto:vpp-dev@lists.fd.io> > On Behalf Of Nick Zavaritsky
Sent: Tuesday, December 15,

Re: [vpp-dev] AVF TX bandwidth less than RX

2020-12-17 Thread Damjan Marion via lists.fd.io



On 17.12.2020., at 14:43, Lijian Zhang 
mailto:lijian.zh...@arm.com>> wrote:



From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Damjan Marion 
via lists.fd.io
Sent: 2020年12月17日 16:22
To: Lijian Zhang mailto:lijian.zh...@arm.com>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>; nd 
mailto:n...@arm.com>>
Subject: Re: [vpp-dev] AVF TX bandwidth less than RX




On 17.12.2020., at 09:16, Lijian Zhang 
mailto:lijian.zh...@arm.com>> wrote:

Hi Damjan,
When I was benchmarking AVF PMD driver with L3fwd and L2-xconnect cases, not 
all packets received via AVF input node ‘avf-input’ are transmitted out via AVF 
output node ‘eth1-tx’.
I have tried to increase the tx-queue-size of avf interface, but it does not 
help. Have checked VNET_DEVICE_CLASS_TX_FN (avf_device_class) (), but didn’t 
find software bottle-neck there.
Is this a normal behavior for XL710 VF interface, and does it mean VF PCIe DMA 
bandwidth in RX direction is higher than that in TX direction?

--L3fwd---
avf-inputpolling   2369637   606626968  
 0  1.30e1  255.99
eth1-output  active2369637   606626968  
 0  5.56e0  255.99
eth1-tx  active2369637   442718040  
 0  2.02e1  186.83
ethernet-input   active2369637   606626968  
 0  1.26e1  255.99
ip4-input-no-checksumactive2369637   606626968  
 0  1.91e1  255.99
ip4-lookup   active2369637   606626968  
 0  2.06e1  255.99
ip4-rewrite  active2369637   606626968  
 0  1.85e1  255.99

--L2-xconnect ---
avf-inputpolling   7342184   779122436  
 0  2.39e1  106.12
eth1-output  active7342123   779122436  
 0  6.67e0  106.12
eth1-tx  active7342123   429393137  
 0  3.23e1   58.48
ethernet-input   active7342123   779122436  
 0  1.37e1  106.12
l2-input active7342123   779122436  
 0  1.14e1  106.12
l2-outputactive7342123   779122436  
 0  6.19e0  106.12

What "show error" says?

If VPP was not able to enqueue packet to tx queue, it will bunp ‘no free slots’ 
counter.

[Lijian] Yes, it reports “no free tx slots”
vpp# clear errors
vpp# show errors
   Count  Node  Reason  
 Severity
   2539792  eth1-txno free tx slots 
   error
vpp# show errors
   Count  Node  Reason  
 Severity
   5547120  eth1-txno free tx slots 
   error

Yes, so looks like software is faster than hardware…. What is your Mpps rate?

—
Damjan




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18387): https://lists.fd.io/g/vpp-dev/message/18387
Mute This Topic: https://lists.fd.io/mt/79032447/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] AVF TX bandwidth less than RX

2020-12-17 Thread Lijian Zhang

From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
lists.fd.io
Sent: 2020年12月17日 16:22
To: Lijian Zhang 
Cc: vpp-dev ; nd 
Subject: Re: [vpp-dev] AVF TX bandwidth less than RX

On 17.12.2020., at 09:16, Lijian Zhang 
mailto:lijian.zh...@arm.com>> wrote:

Hi Damjan,
When I was benchmarking AVF PMD driver with L3fwd and L2-xconnect cases, not 
all packets received via AVF input node ‘avf-input’ are transmitted out via AVF 
output node ‘eth1-tx’.
I have tried to increase the tx-queue-size of avf interface, but it does not 
help. Have checked VNET_DEVICE_CLASS_TX_FN (avf_device_class) (), but didn’t 
find software bottle-neck there.
Is this a normal behavior for XL710 VF interface, and does it mean VF PCIe DMA 
bandwidth in RX direction is higher than that in TX direction?

--L3fwd---
avf-inputpolling   2369637   606626968  
 0  1.30e1  255.99
eth1-output  active2369637   606626968  
 0  5.56e0  255.99
eth1-tx  active2369637   442718040  
 0  2.02e1  186.83
ethernet-input   active2369637   606626968  
 0  1.26e1  255.99
ip4-input-no-checksumactive2369637   606626968  
 0  1.91e1  255.99
ip4-lookup   active2369637   606626968  
 0  2.06e1  255.99
ip4-rewrite  active2369637   606626968  
 0  1.85e1  255.99

--L2-xconnect ---
avf-inputpolling   7342184   779122436  
 0  2.39e1  106.12
eth1-output  active7342123   779122436  
 0  6.67e0  106.12
eth1-tx  active7342123   429393137  
 0  3.23e1   58.48
ethernet-input   active7342123   779122436  
 0  1.37e1  106.12
l2-input active7342123   779122436  
 0  1.14e1  106.12
l2-outputactive7342123   779122436  
 0  6.19e0  106.12

What "show error" says?

If VPP was not able to enqueue packet to tx queue, it will bunp ‘no free slots’ 
counter.

[Lijian] Yes, it reports “no free tx slots”
vpp# clear errors
vpp# show errors
   Count  Node  Reason  
 Severity
   2539792  eth1-txno free tx slots 
   error
vpp# show errors
   Count  Node  Reason  
 Severity
   5547120  eth1-txno free tx slots 
   error
—
Damjan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18386): https://lists.fd.io/g/vpp-dev/message/18386
Mute This Topic: https://lists.fd.io/mt/79032447/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] AVF TX bandwidth less than RX

2020-12-17 Thread Damjan Marion via lists.fd.io



On 17.12.2020., at 09:16, Lijian Zhang 
mailto:lijian.zh...@arm.com>> wrote:

Hi Damjan,
When I was benchmarking AVF PMD driver with L3fwd and L2-xconnect cases, not 
all packets received via AVF input node ‘avf-input’ are transmitted out via AVF 
output node ‘eth1-tx’.
I have tried to increase the tx-queue-size of avf interface, but it does not 
help. Have checked VNET_DEVICE_CLASS_TX_FN (avf_device_class) (), but didn’t 
find software bottle-neck there.
Is this a normal behavior for XL710 VF interface, and does it mean VF PCIe DMA 
bandwidth in RX direction is higher than that in TX direction?

--L3fwd---
avf-inputpolling   2369637   606626968  
 0  1.30e1  255.99
eth1-output  active2369637   606626968  
 0  5.56e0  255.99
eth1-tx  active2369637   442718040  
 0  2.02e1  186.83
ethernet-input   active2369637   606626968  
 0  1.26e1  255.99
ip4-input-no-checksumactive2369637   606626968  
 0  1.91e1  255.99
ip4-lookup   active2369637   606626968  
 0  2.06e1  255.99
ip4-rewrite  active2369637   606626968  
 0  1.85e1  255.99

--L2-xconnect ---
avf-inputpolling   7342184   779122436  
 0  2.39e1  106.12
eth1-output  active7342123   779122436  
 0  6.67e0  106.12
eth1-tx  active7342123   429393137  
 0  3.23e1   58.48
ethernet-input   active7342123   779122436  
 0  1.37e1  106.12
l2-input active7342123   779122436  
 0  1.14e1  106.12
l2-outputactive7342123   779122436  
 0  6.19e0  106.12

What "show error" says?

If VPP was not able to enqueue packet to tx queue, it will bunp ‘no free slots’ 
counter.

—
Damjan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18385): https://lists.fd.io/g/vpp-dev/message/18385
Mute This Topic: https://lists.fd.io/mt/79032447/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] AVF TX bandwidth less than RX

2020-12-17 Thread Lijian Zhang

Hi Damjan,
When I was benchmarking AVF PMD driver with L3fwd and L2-xconnect cases, not 
all packets received via AVF input node 'avf-input' are transmitted out via AVF 
output node 'eth1-tx'.
I have tried to increase the tx-queue-size of avf interface, but it does not 
help. Have checked VNET_DEVICE_CLASS_TX_FN (avf_device_class) (), but didn't 
find software bottle-neck there.
Is this a normal behavior for XL710 VF interface, and does it mean VF PCIe DMA 
bandwidth in RX direction is higher than that in TX direction?

--L3fwd---
avf-inputpolling   2369637   606626968  
 0  1.30e1  255.99
eth1-output  active2369637   606626968  
 0  5.56e0  255.99
eth1-tx  active2369637   442718040  
 0  2.02e1  186.83
ethernet-input   active2369637   606626968  
 0  1.26e1  255.99
ip4-input-no-checksumactive2369637   606626968  
 0  1.91e1  255.99
ip4-lookup   active2369637   606626968  
 0  2.06e1  255.99
ip4-rewrite  active2369637   606626968  
 0  1.85e1  255.99

--L2-xconnect ---
avf-inputpolling   7342184   779122436  
 0  2.39e1  106.12
eth1-output  active7342123   779122436  
 0  6.67e0  106.12
eth1-tx  active7342123   429393137  
 0  3.23e1   58.48
ethernet-input   active7342123   779122436  
 0  1.37e1  106.12
l2-input active7342123   779122436  
 0  1.14e1  106.12
l2-outputactive7342123   779122436  
 0  6.19e0  106.12

Thanks.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18384): https://lists.fd.io/g/vpp-dev/message/18384
Mute This Topic: https://lists.fd.io/mt/79032447/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] AVF TX bandwidth less than RX

Re: [vpp-dev] Core Load Calculation

[vpp-dev] VPP Vectors/Call rate #dpdk

Re: [vpp-dev] Core Load Calculation

Re: [vpp-dev] Core Load Calculation

Re: [vpp-dev] Core Load Calculation

Re: [vpp-dev] move to clang-format

Re: [vpp-dev] move to clang-format

Re: [vpp-dev] Multicast packets sent via memif when rule says to forward through another interface

Re: [vpp-dev] move to clang-format

Re: [vpp-dev] Core Load Calculation

Re: [vpp-dev] AVF TX bandwidth less than RX

Re: [vpp-dev] AVF TX bandwidth less than RX

Re: [vpp-dev] AVF TX bandwidth less than RX

[vpp-dev] AVF TX bandwidth less than RX

15 matches

Site Navigation

Mail list logo

Footer information