2017-01-09 05:29, Wang, Zhihong: > From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] > > 2016-06-07 11:09, Wang, Zhihong: > > > From: Ravi Kerur [mailto:rke...@gmail.com] > > > > Zhilong, Thomas, > > > > > > > > If there is enough interest within DPDK community I can work on adding > > support > > > > for 'unaligned access' and 'test cases' for it. Please let me know > > > > either > > way. > > > > > > Hi Ravi, > > > > > > This rte_memcmp is proved with better performance than glibc's in aligned > > > cases, I think it has good value to DPDK lib. > > > > > > Though we don't have memcmp in critical pmd data path, it offers a better > > > choice for applications who do. > > > > Re-thinking about this series, could it be some values to have a rte_memcmp > > implementation? > > I think this series (rte_memcmp included) could help: > > 1. Potentially better performance in hot paths. > > 2. Agile for tuning. > > 3. Avoid performance complications -- unusual but possible, > like the glibc memset issue I met while working on vhost > enqueue. > > > What is the value compared to glibc one? Why not working on glibc? > > As to working on glibc, wider design consideration and test > coverage might be needed, and we'll face different release > cycles, can we have the same agility? Also working with old > glibc could be a problem.
Probably we need both: add the optimized version in DPDK while working on a glibc optimization. This strategy could be applicable to memcpy, memcmp and memset.
