[j-nsp] Slow RE path 20 x faster then PFE path

[Saku Ytti]

I'm not sure what you mean by 'PFE loops', this is single NPU
fabricless platform, all ports are local. The only way to delay packet
that long, is to send it to off-chip DRAM (delay buffer).

But please update list once you figure it out.


On Mon, 23 Mar 2020 at 17:28, Robert Raszuk <robert at raszuk.net> wrote:
>
> That is actual topology and during testing no other return path existed.
>
> It seems that there are PFE loops which would explain why punted to RE packets are forwarded so fast .... JTAC is debugging :)
>
> Thx,
> R.
>
> On Mon, Mar 23, 2020 at 4:17 PM Saku Ytti <saku at ytti.fi> wrote:
>>
>> Hey,
>>
>> > This is very simple setup:
>> >
>> >  linux (.206) ---- LAN---- mx104(.210) ---- p2p---- isp (.209)
>> >
>> > Pretty much 1.4 is what is expected. The only place the delay occurs is on ingress from the ISP to MX104. If I ping MX104 outbound (.210) int I get 0.5 ms.
>> >
>> > No worries anyway ... just thought anyone run into this before.
>>
>> Is this simplified topology or actual? Is it not possible that return
>> path is different? Entirely possible for SW and HW forwarded packets
>> to experience different path selection. So perhaps ISP is returning
>> packets via other path for HW packets, but other path via SW packets.
>>
>> It's very difficult to imagine failure mode where packets would wait
>> consistent ~23ms on the mx104.
>>
>> --
>>   ++ytti



-- 
  ++ytti