On Fri, Oct 30, 2015 at 04:28:25PM +0000, Hunt, David wrote: > On 30/10/2015 16:11, Jan Viktorin wrote: > >Hmm, I see. It's good to fix this in the generated e-mails between > >format-patch > > and send-email calls. I always review those to be sure they meet my > expectations ;). > >Anyway, it is not clear, what has changed in the v3. Just the rte_cycles? > >You should explain that at least in the 0000 patch. Better to keep some > >history > >in each single commit (are there any rules in dpdk for this? Just look how > >they do in kernel). > --snip-- > > Sure, I'll keep that in mind for the next time. A list of changes for each > revision, and also changes in each patch in the patch set. As Thomas says - > whatever helps the reviewer :) > > For the moment there probably isn't a need to release a new patch set for > these comments, so I'll just list them here: > 1. v3 has just the additional comment in one of the patches to say that the > armv8 header files are in the 'arm' include directory. > 2. The rte_cycles is unchanged, the CONFIG_ is not needed. > > If there is a need to post another patch set I'll include the change notes. > Otherwise do we all think that the patch is there (or there abouts)? :)
Hi Jan and Dave, I have reviewed your patches for arm[64] support. Please check the review comments. Cavium would like to contribute on armv8 port and remaining libraries (ACL, LPM, HASH) implementation for armv8. Currently i am re-basing our ACL,HASH libraries implementation based on existing patches. Happy to work with you guys to have full fledged armv8 support for DPDK. Jerin other query on rte_cpu_get_flag_enabled for armv8, I have tried to run the existing patches on armv8-thunderX platform. But there application start failure due to mismatch in rte_cpu_get_flag_enabled() encoding. In my platform rte_cpu_get_flag_enabled() works based on AT_HWCAP with following values[1] which different from existing lib/librte_eal/common/include/arch/arm/rte_cpuflags.h [1]http://lxr.free-electrons.com/source/arch/arm64/include/uapi/asm/hwcap.h In order to debug this, Could provide the following values in tested armv8 platform. Look like its running 32bit compatible mode in your environment root at arm64:/export/dpdk-arm64# LD_SHOW_AUXV=1 sleep 1000 AT_SYSINFO_EHDR: 0x3ff859f0000 AT_??? (0x26): 0x430f0a10 AT_HWCAP: fb AT_PAGESZ: 65536 AT_CLKTCK: 100 AT_PHDR: 0x400040 AT_PHENT: 56 AT_PHNUM: 7 AT_BASE: 0x3ff85a00000 AT_FLAGS: 0x0 AT_ENTRY: 0x401900 AT_UID: 0 AT_EUID: 0 AT_GID: 0 AT_EGID: 0 AT_SECURE: 0 AT_RANDOM: 0x3ffef1c7988 AT_EXECFN: /bin/sleep AT_PLATFORM: aarch64 root at arm64:/export/dpdk-arm64# zcat /proc/config.gz | grep CONFIG_COMPAT # CONFIG_COMPAT_BRK is not set CONFIG_COMPAT_BINFMT_ELF=y CONFIG_COMPAT=y CONFIG_COMPAT_NETLINK_MESSAGES=y root at arm64:/export/dpdk-arm64# cat /proc/cpuinfo Processor : AArch64 Processor rev 0 (aarch64) processor : 0 processor : 1 processor : 2 processor : 3 processor : 4 processor : 5 processor : 6 processor : 7 processor : 8 processor : 9 processor : 10 processor : 11 processor : 12 processor : 13 processor : 14 processor : 15 processor : 16 processor : 17 processor : 18 processor : 19 processor : 20 processor : 21 processor : 22 processor : 23 processor : 24 processor : 25 processor : 26 processor : 27 processor : 28 processor : 29 processor : 30 processor : 31 processor : 32 processor : 33 processor : 34 processor : 35 processor : 36 processor : 37 processor : 38 processor : 39 processor : 40 processor : 41 processor : 42 processor : 43 processor : 44 processor : 45 processor : 46 processor : 47 Features : fp asimd aes pmull sha1 sha2 crc32 CPU implementer : 0x43 CPU architecture: AArch64 CPU variant : 0x0 CPU part : 0x0a1 CPU revision : 0 > > Regards, > Dave. >