Den fre 14 juni 2019 kl 15:47 skrev Sean Redmond <sean.redmond1@xxxxxxxxx>:
Hi James,Thanks for your comments.I think the CPU burn is more of a concern to soft iron here as they are using low power ARM64 CPU's to keep the power draw low compared to using Intel CPU's where like you say the problem maybe less of a concern.
Using less power by using ARM64 and providing EC using an FPGA does sound interesting as I often run into power constrains when deploying. I am just concerned that this FPGA functionally seems limited to a single vendor, who I assume is packing their own EC plugin to get this to work (hopefully a soft iron employee can explain to us how that is implemented). as I like the flexibility we have with ceph to change or use multiple vendor over time
Just getting slightly the same vibes as the old "crypto accelerator cards" that was once sold to enhance your single/3DES performance which could show very impressive numbers of encrypted bytes/s and whatnot, but in those cases, if you did ipsec for instance, unless you could also checksum and re-package the packets on the card, it became almost a net loss to take packets in, ship over buses to accelerator card and back, then loop over the packets once more for checksums after decrypt, and quite possibly copy them once again in memory before sending the decapsulated packets inwards from your ipsec box, so even if the crypto takes 0 time, it becomes a rather small part of the whole operation and of course these days the packet fits quite well inside L1 caches of almost all CPUs, so looping over it once for decrypt and once for checksum isn't going to take a huge amount more time than only once + two trips over the buses.
I get that this design is slightly different, but the vibes are there.
May the most significant bit of your life be positive.
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
