[j-nsp] Finding drops

[Saku Ytti]

On Thu, 24 Jan 2019 at 12:52, <adamv0025 at netconsultings.com> wrote:

> If it shows info cell drops then that means the PFE can't cope with the PPS rate.

It can't drop cells, as packets are never cellified, as platform does
not have FAB side at all. There is only WAN side, so all is local
switched.

> Since as Saku confirmed both interfaces et-0/0/2 and et-0/0/0 on mx1 are on the same PFE then the packet processing computational load for ingress and egress processing is not spread across two PFEs but rather executed on a single PFE which has to handle 200Gbps (100in+100out) worth of traffic @ 64bps, can't be bothered to calculate the pps rate there, but my guess is that the PFE can't handle the resulting PPS rate (as it is most likely above the PFE's overall (in+out) PPS budget) which is not that high on Gen3 (applies to most NPUs out there with 100g ports).
> If the chip is rated for 800G(400in+400out) extrapolating from my notes on MPC7 testing the 204PFE then should cope with ~200in+~200out @64bit (if your traffic is bidirectional you'd be at the limit.

EAChip (mqss) on fabric platforms has 400Gbps WAN + 400Gbps FAB, MX204
is fabless, so it's 800Gbps WAN. This test should pass with modest
luss load.

> -is the flow-control disabled on all interfaces involved with this test please? (we don't want the mx2 to send pause frames to et-0/0/0  on mx1 when it can't cope with the ingress PPS rate, skewing the results)

This is really good proposal, flow-control is on by default.

-- 
  ++ytti