Scott Fluhrer \(sfluhrer\) writes: > As for the idea of moving the integrity check value before the > encapsulated packet, well, that idea might help on your platform; > however it strikes me that the advantage would likely be fairly > platform dependent.
Yes. In several kernel implementations the packets are formed as mbufs which are linked list of pieces of packets, and in that kind of environments there is easy ways to add/remove bytes to/from start or to/from the end without needing to copy anything. In case you have single big buffer for the whole packet then removing stuff from the end or adding stuff to the end is possible without any copying provided you have enough space in your buffer. Adding stuff to the beginning of the packet might require you to copy the whole packet... Also the need to read (while receiving packet) the ICV is only after you have already decrypted the whole packet (if using AEAD), and want to verify that the value matches. When the ICV is at the end of packet that means it might already be in the cpu cache, as cpu read the last bytes of the packet and the cache line might be big enough to include ICV. If we need to go back to the beginning to read the ICV it might not be in the cache anymore. Anyways I do not think we should be doing to much optimizatin based on the one specific operating system, cpu, or architecture. If we would be doing this from the scratch, then it might be worth of investigating different operating systems, different cpus and see if we can find out what kind of optimizations we can do and how do they affect, but I do not think we want to make too much changes this late for just very small gains (my guess is that moving ICV optimization is not really visible in tests that include actual network). -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
