[CC +willy, toke, dave, netdev] Hi Pascal On Thu, Sep 26, 2019 at 12:19 PM Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx> wrote: > Actually, that assumption is factually wrong. I don't know if anything > is *publicly* available, but I can assure you the silicon is running in > labs already. And something will be publicly available early next year > at the latest. Which could nicely coincide with having Wireguard support > in the kernel (which I would also like to see happen BTW) ... > > Not "at some point". It will. Very soon. Maybe not in consumer or server > CPUs, but definitely in the embedded (networking) space. > And it *will* be much faster than the embedded CPU next to it, so it will > be worth using it for something like bulk packet encryption. Super! I was wondering if you could speak a bit more about the interface. My biggest questions surround latency. Will it be synchronous or asynchronous? If the latter, why? What will its latencies be? How deep will its buffers be? The reason I ask is that a lot of crypto acceleration hardware of the past has been fast and having very deep buffers, but at great expense of latency. In the networking context, keeping latency low is pretty important. Already WireGuard is multi-threaded which isn't super great all the time for latency (improvements are a work in progress). If you're involved with the design of the hardware, perhaps this is something you can help ensure winds up working well? For example, AES-NI is straightforward and good, but Intel can do that because they are the CPU. It sounds like your silicon will be adjacent. How do you envision this working in a low latency environment? Jason
