Re: [mpls] Concerns about ISD

[Tony Li <[e-mail]>]

Hi Haoyu,


> First off, network processors and switches are ASICs.  It’s all just silicon. How you get there may vary, but at the end of the day, the performance that you get out given a specific process technology corresponds directly to the effort that you put into optimizing it.
>  
> Yes, you’re correct, every cycle is precious.  Memory reads are also precious. And in most every modern architecture, a memory read is far more expensive than an ALU operation. For example, in my history, memory reads took around 12ns and operations took 1ns.  Thus, spending a memory read to save a compute operation was a bad trade-off.
>  
> As a result, memorizing the memory reads is far more important that worrying about operations.
>  
> [HS2] You are talking about accessing DRAM perhaps. The embedded SRAM today can be read in 1ns, and such header processing operations would use SRAM exclusively if memory is needed.


No, DRAM is up around 70ns. My process technology may well be dated, but even so, if we ignore process differences, a read still takes time.

A bit of web surfing shows that current SRAM access times are around 10ns. If you have relevant public citations that can improve on this, that would be most welcome.


> [HS2] The chip keeps the header buffer in SRAM/register, so the access to it is at the same speed of the system clock.


I will believe that it’s in SRAM.  Legacy nodes may not support that as they may not have enough SRAM and may be forced to DRAM accesses to reach PSD. SRAM typically doesn’t run at processor cycle times as there is time for the address to propagate and for the result to come back.

I have a very hard time believing that anything has 1000s of bytes of registers per packet.

If you have public references, again, please post them.

> Well, I prefer proposals where there is more flexibility.
>  
> [HS] Header chain is more flexible and extensible. It’s used for all the headers AFAIK.
>  
>  
> Except that now you’ve decided that SOME operations get taken out of a fixed number of bits, not out of the header chain.  And once we’ve used that number of bits, we’re stuck, back having this same argument again in 10 years.  No thank you.
>  
> [HS2] An 8-bit field can support up to 256 extension headers. I think it’s more than enough for data plane functions.


You’re talking at cross purposes.  We were discussing where you would hide one bit for implementing NFFRR. You proposed hiding it in the EHI. AFAICT, there are at most 11 bits available there.

If you want to put NFFRR in its own extension header, then that would be an additional memory read and 4 octets more of packet overhead.

Tony