6 arch ? Does it work automatically on say PPC or OCTEON ?
--
Sincerely,
Yerden Zhumabekov
STS, ACI
Astana, KZ
nction?
--
Sincerely,
Yerden Zhumabekov
STS, ACI
Astana, KZ
cated commit.
>
> Acked-by: Thomas Monjalon
>
> Applied for version 1.7.1
>
> What are the news about your uio work for kernel.org?
>
> Thanks
--
Sincerely,
Yerden Zhumabekov
STS, ACI
Astana, KZ
-- next part --
== Installing x86_64-native-li
Since PCI config lock/unlock functions were renamed in linux kernel,
wrappers are introduced to reflect this change.
Fixed a few typos.
Yerden Zhumabekov (3):
igb_uio: fixed typos
igb_uio: pci_config_lock/pci_config_unlock wrappers
igb_uio: renaming pci config lock/unlock functions
lib
Signed-off-by: Yerden Zhumabekov
---
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index 05cbe8e..02545d9 100644
Since PCI config lock/unlock functions were renamed in linux kernel,
these wrappers are introduced to reflect this change.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 20
1 file changed, 20 insertions(+)
diff --git a/lib/librte_eal
renaming pci config lock/unlock functions using wrappers introduced
in commit f57049874f61046641a8eb1e9832810cc33befe5
Signed-off-by: Yerden Zhumabekov
---
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/lib
Since PCI config lock/unlock functions were renamed in linux kernel,
wrappers are introduced to reflect this change.
Fixed a few typos.
Patches attached, not inlined. :)
Yerden Zhumabekov (3):
igb_uio: fixed typos
igb_uio: pci_config_lock/pci_config_unlock wrappers
igb_uio: renaming pci
Signed-off-by: Yerden Zhumabekov
---
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
Since PCI config lock/unlock functions were renamed in linux kernel,
these wrappers are introduced to reflect this change.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 20
1 file changed, 20 insertions(+)
renaming pci config lock/unlock functions using wrappers introduced
in commit f57049874f61046641a8eb1e9832810cc33befe5
Signed-off-by: Yerden Zhumabekov
---
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
makes
VMware e1000 unbindable to igb_uio driver and throwing -EIO error.
What I suggest is to throw a kernel warning but make the work with this kind of
NIC possible.
Yerden Zhumabekov (1):
igb_uio: fall back to enable/disable irq mode
lib/librte_eal/linuxapp/igb_uio/igb_uio.c |6
Rewritten IRQ mode handling code introduced in commit 399a3f0d
(igb_uio: fix IRQ mode handling) renders some faulty NICs (VMware
e1000, for example) unusable if INTX mode is not supported.
This patch gets these NICs up and running, but throwing a kernel
warning.
Signed-off-by: Yerden Zhumabekov
these NICs up and running, but throwing a kernel
>> warning.
>>
>> Signed-off-by: Yerden Zhumabekov
> That is because the VMWare PCI INTX is broken.
> The masking logic doesn't work.
>
> Rather than applying this patch a deeper fix in E1000 and DPDK handling
> of li
8ba55
Chunk size: 30
rte_hash_crc:0.505 sec, hash: 0x35f07dbb
rte_hash_crc_new:0.337 sec, hash: 0x35f07dbb
Chunk size: 31
rte_hash_crc:0.505 sec, hash: 0x1bf2ee8c
rte_hash_crc_new:0.337 sec, hash: 0x1bf2ee8c
Yerden Zhumabekov (2):
hash: ad
SSE4.2 provides _mm_crc32_u64 intrinsic with 8-byte operand.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 16
1 file changed, 16 insertions(+)
diff --git a/lib/librte_hash/rte_hash_crc.h b/lib/librte_hash/rte_hash_crc.h
index b48b0db..102b2a0 100644
Calculating hash for data of variable length is more efficient
when that data is sliced into 8-byte pieces. The rest part of data
is hashed using either 8 and 4-byte CRC32 intrinsics.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 31 +++
1
TX.
>
> Signed-off-by: Bruce Richardson
--
Sincerely,
Yerden Zhumabekov
STS, ACI
Astana, KZ
tion: would you consider the ip fragmentation and reassembly example apps
> in the Intel DPDK releases good examples to test to see the impacts of this
> change, or is there some other test you would prefer that I look to do?
> Can you perhaps test out the patch sets for the mbuf that I'
uint16_t data_len; /**< Amount of data in segment buffer. */
>> uint32_t pkt_len; /**< Total pkt len: sum of all segments. */
>> uint16_t l3_len:9; /**< L3 (IP) Header Length. */
>>
> This patch adds a new fields that nobody uses. So why should we add it ?
--
Sincerely,
Yerden Zhumabekov
State Technical Service
Astana, KZ
yone know the issue and the corresponding fix? Thanks.
>
> Best,
> Xin
--
Sincerely,
Yerden Zhumabekov
State Technical Service
Astana, KZ
And I
see no point in checking for ring flags when creating abstraction
because it really does not affect the operation of this abstraction
anyway. Is this behaviour anyhow justified?
--
Yerden Zhumabekov
is in fact
public, will it continue to be?
I'd like to use it (and some code in librte_eal/common) for region-based
allocation in a secondary process for easy memory reclamation in case of
failure. Is it safe to reuse malloc_heap struct?
--
Yerden Zhumabekov
On 06.06.2017 19:19, Ananyev, Konstantin wrote:
Maybe there is some deeper reason for the >= 128-byte alignment logic in
rte_ring.h?
Might be, would be good to hear opinion the author of that change.
It gives improved performance for core-2-core transfer.
You mean empty cache-line(s) after
01.02.2015 20:13, Neil Horman ?:
> On Thu, Jan 29, 2015 at 02:48:11PM +0600, Yerden Zhumabekov wrote:
>> This is a rework of my previous patches improving performance of
>> rte_hash_crc.
>>
>> Summary of changes:
>> * software implementation of CRC3
so the build would fail.
See previous suggestion from Neil:
http://dpdk.org/ml/archives/dev/2014-November/008353.html
--
Sincerely,
Yerden Zhumabekov
State Technical Service
Astana, KZ
02.02.2015 9:31, Neil Horman ?:
> On Mon, Feb 02, 2015 at 09:07:45AM +0600, Yerden Zhumabekov wrote:
>
>> I think so, I've just successfully built it against latest snapshot with
>> RTE_TARGET
>> equal to 'x86_64-native-linuxapp-gcc'.
>>
>
.2 is
intentionally disabled.
Initial version (v1) changes:
* added rte_hash_crc_8byte() function to calculate CRC32 on 8-byte operand;
* reworked rte_hash_crc() function which leverages both versions of CRC32 hash
calculation functions with 4 and 8-byte operands.
Yerden Zhumabekov (7):
hash
Add lookup tables for CRC32 algorithm, crc32c_1word() and
crc32c_2words() functions returning hash of 32-bit and 64-bit
operand.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 316
1 file changed, 316 insertions(+)
diff --git a
Added:
- crc32c_sse42_u32() emits 'crc32l' asm instruction;
- crc32c_sse42_u64() emits 'crc32q' asm instruction;
- crc32c_sse42_u64_mimic(), wrapper in case of run on 32-bit platform.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/r
Give up using built-in intrinsics and use our own assembly
implementation. Remove #include entry as well.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lib/librte_hash/rte_hash_crc.h b/lib/librte_hash
SSE4.2 provides CRC32 intrinsic with 8-byte operand.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 16
1 file changed, 16 insertions(+)
diff --git a/lib/librte_hash/rte_hash_crc.h b/lib/librte_hash/rte_hash_crc.h
index 45b0dce..6cc67cd 100644
--- a
.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 61 ++--
1 file changed, 59 insertions(+), 2 deletions(-)
diff --git a/lib/librte_hash/rte_hash_crc.h b/lib/librte_hash/rte_hash_crc.h
index 6cc67cd..435048e 100644
--- a/lib/librte_hash
Calculating hash for data of variable length is more efficient
when that data is sliced into 8-byte pieces. The rest part of data
is hashed using CRC32 functions with either 8 and 4 byte operands.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 33
Since rte_hash_crc() can now be run regardless of SSE4.2 support,
we can safely remove compile checks for RTE_MACHINE_CPUFLAG_SSE4_2
in test utilities.
Signed-off-by: Yerden Zhumabekov
---
app/test/test_hash.c |7 ---
app/test/test_hash_perf.c | 11 ---
2 files changed
Hello everybody,
DPDK already got a number of PMDs for various eth devices, it even has
PMD emulations for backends such as pcap, sw rings etc.
I've been thinking about the idea of having PMD which would generate
mbufs on the fly in some randomized fashion. This would serve goals
like, for exa
On 15.06.2016 15:49, Bruce Richardson wrote:
> On Wed, Jun 15, 2016 at 03:43:56PM +0600, Yerden Zhumabekov wrote:
>> Hello everybody,
>>
>> DPDK already got a number of PMDs for various eth devices, it even has PMD
>> emulations for backends such as pcap, sw rings et
On 15.06.2016 16:43, Dumitrescu, Cristian wrote:
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yerden
>> Zhumabekov
>> Sent: Wednesday, June 15, 2016 10:44 AM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] random
On 15.06.2016 17:50, Jay Rolette wrote:
> On Wed, Jun 15, 2016 at 4:43 AM, Yerden Zhumabekov
> wrote:
>
>> Hello everybody,
>>
>> DPDK already got a number of PMDs for various eth devices, it even has PMD
>> emulations for backends such as pcap, sw rings etc.
&
On 15.06.2016 17:25, Panu Matilainen wrote:
> On 06/15/2016 02:10 PM, Yerden Zhumabekov wrote:
>>
>>
>> On 15.06.2016 16:43, Dumitrescu, Cristian wrote:
>>>
>>>>
>>>> Hello everybody,
>>>>
>>>> DPDK already got
On 15.06.2016 18:33, Jay Rolette wrote:
> On Wed, Jun 15, 2016 at 7:11 AM, Yerden Zhumabekov
> wrote:
>>
>> On 15.06.2016 17:50, Jay Rolette wrote:
>>
>>> On Wed, Jun 15, 2016 at 4:43 AM, Yerden Zhumabekov
>>> wrote:
>>>
>>> Hello e
On 15.06.2016 18:25, Dumitrescu, Cristian wrote:
So add a loop-mode to pcap pmd?
>>> It would be nice to have an option like "...,rewind=1,...".
>> As Cristian points out in
>> http://dpdk.org/ml/archives/dev/2016-June/041589.html, the current pmd
>> behavior of stopping is the odd man out
On 15.06.2016 19:02, Neil Horman wrote:
> On Wed, Jun 15, 2016 at 03:43:56PM +0600, Yerden Zhumabekov wrote:
>> Hello everybody,
>>
>> DPDK already got a number of PMDs for various eth devices, it even has PMD
>> emulations for backends such as pcap, sw rings etc.
>
ut I haven't come up with anything else.
On 15.06.2016 16:07, Bruce Richardson wrote:
> On Wed, Jun 15, 2016 at 04:03:59PM +0600, Yerden Zhumabekov wrote:
>>
>> Right, but development of various features regarding L3/L4 etc requires more
>> subtle approach, like live packets,
, Thomas.
As for yielding the same hash value, I made a test which runs every
CRC32 implementation across a number of randomly generated data sets.
Results are equal on my trial run.
I can post a patch for test_hash.c a bit later if this kind of check
suffices.
--
Sincerely,
Yerden Zhumabekov
State Technical Service
Astana, KZ
New function test_crc32_hash_alg_equiv() checks whether software,
4-byte operand and 8-byte operand versions of CRC32 hash function
implementations return the same result value.
Signed-off-by: Yerden Zhumabekov
---
app/test/test_hash.c | 53
tly it failed.
> Also, rather than setting res to -1, you can just do a print and break, and
> change "return res" below to "return i == CRC32_ITERATIONS ? 0 : -1", making
> use of the fact that you can check i to detect early termination on error.
Noted; then I suggest I'll print out test data which caused the break as
well. It might be handy for further investigation.
--
Sincerely,
Yerden Zhumabekov
State Technical Service
Astana, KZ
New function test_crc32_hash_alg_equiv() checks whether software,
4-byte operand and 8-byte operand versions of CRC32 hash function
implementations return the same result value.
Signed-off-by: Yerden Zhumabekov
---
app/test/test_hash.c | 63
New function test_crc32_hash_alg_equiv() checks whether software,
4-byte operand and 8-byte operand versions of CRC32 hash function
implementations return the same result value.
Signed-off-by: Yerden Zhumabekov
---
app/test/test_hash.c | 60
All notes taken into account. v3 posted.
25.02.2015 17:34, Bruce Richardson ?:
> On Wed, Feb 25, 2015 at 10:08:32AM +0600, Yerden Zhumabekov wrote:
>> New function test_crc32_hash_alg_equiv() checks whether software,
>> 4-byte operand and 8-byte operand versions of CRC3
32_t
> rte_hash_crc_8byte(uint64_t data, uint32_t init_val)
> {
> +#ifdef RTE_ARCH_X86_64
> if (likely(crc32_alg == CRC32_SSE42_x64))
> return crc32c_sse42_u64(data, init_val);
> +#endif
>
> if (likely(crc32_alg & CRC32_SSE42))
> return crc32c_sse42_u64_mimic(data, init_val);
--
Sincerely,
Yerden Zhumabekov
State Technical Service
Astana, KZ
Acked-by: Yerden Zhumabekov
05.03.2015 22:55, Michael Qiu ?:
> CC rte_hash.o
> Error: unsupported instruction `crc32'
>
> The root cause is that i686 platform does not support 'crc32q'
> Need make it only available in x86_64 platform
>
> Signed-of
because they are protected by the cpuflag
> condition.
That would be a bad surprise if one tries to launch that pre-built
binary on SSE4.2-capable arch :) It's fine though, if binary portability
is out of scope here.
--
Sincerely,
Yerden Zhumabekov
State Technical Service
Astana, KZ
-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/lib/librte_hash/rte_hash_crc.h b/lib/librte_hash/rte_hash_crc.h
index 3dcd362..e81920f 100644
--- a/lib/librte_hash/rte_hash_crc.h
f:8b:a1
> inet addr:192.168.56.101 Bcast:192.168.56.255 Mask:255.255.255.0
> inet6 addr: fe80::a00:27ff:feef:8ba1/64 Scope:Link
> UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
> RX packets:2 errors:0 dropped:0 overruns:0 frame:0
> TX packets:90 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:1180 (1.1 KB) TX bytes:17162 (17.1 KB)aff
>
>
> After this when I send traffic with this MAC >>> 080027b73a25
> traffic does not flow to this interface
>
> Regards
> Shankari.V
--
Sincerely,
Yerden Zhumabekov
State Technical Service
Astana, KZ
Hi Bruce,
Answers below.
19.03.2015 22:25, Bruce Richardson ?:
> On Wed, Mar 18, 2015 at 10:51:12PM +0600, Yerden Zhumabekov wrote:
>> Fix rte_hash_crc() function. Casting uint64_t pointer to uin32_t
>> may trigger a compiler warning about breaking strict-aliasing rules.
&
Fix rte_hash_crc() function by making use of uintptr_t variable
to hold a pointer to data being hashed. In this way, casting uint64_t
pointer to uint32_t avoided.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 21 +++--
1 file changed, 11 insertions
14.11.2014 6:52, Neil Horman ?:
> On Thu, Nov 13, 2014 at 06:33:14PM +0100, Thomas Monjalon wrote:
>> Any comment on these patches?
>>
>> 2014-09-03 12:05, Yerden Zhumabekov:
>>> As SSE4.2 provides CRC32 instructions with either 32 and 64 bit operands,
>
14.11.2014 17:33, Neil Horman ?:
> On Fri, Nov 14, 2014 at 01:15:12PM +0600, Yerden Zhumabekov wrote:
>>
>> Hello,
>>
>> A quick grep on dpdk source shows that rte_hash_crc() is used in
>> librte_hash in following context:
>>
>> In rte_hash.c:
rovide better balancing then using just one byte value,
> plus should be a bit faster, as in that case your balancer code don't need to
> touch packet's data.
>
> Konstantin
--
Sincerely,
Yerden Zhumabekov
State Technical Service
Astana, KZ
14.11.2014 19:53, Neil Horman ?:
> On Fri, Nov 14, 2014 at 05:57:51PM +0600, Yerden Zhumabekov wrote:
>> 14.11.2014 17:33, Neil Horman ?:
>>> Not really. That covers the case of applications selecting the hash
>>> function
>>> using the DEFUALT_HASH
14.11.2014 22:50, Ananyev, Konstantin ?:
>> -Original Message-
>> From: Yerden Zhumabekov [mailto:e_zhumabekov at sts.kz]
>> Sent: Friday, November 14, 2014 4:23 PM
>> To: Ananyev, Konstantin; Kamraan Nasim; dev at dpdk.org
>> Cc: Yuanzhang Hu
>> Su
ks ago. For Niantic you can use symmetrical rss key
> recommended by Konstantin.
>
> Regards,
> Andrey
>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ananyev, Konstantin
> Sent: Friday, November 14, 2014 4:50 PM
> To: Yerden
dev-bounces at dpdk.org>] On Behalf Of Ananyev, Konstantin
> Sent: Friday, November 14, 2014 4:50 PM
> To: Yerden Zhumabekov; Kamraan Nasim; dev at dpdk.org
> <mailto:dev at dpdk.org>
> Cc: Yuanzhang Hu
> Subject: Re: [dpdk-dev] Load-balancing position field i
15.11.2014 0:41, Neil Horman ?:
> On Fri, Nov 14, 2014 at 10:43:39PM +0600, Yerden Zhumabekov wrote:
>> 14.11.2014 19:53, Neil Horman ?:
>>>
>>> Well, its possible you'll get lucky. crc is such a common operation, its
>>> entirely possible that t
Calculating hash for data of variable length is more efficient
when that data is sliced into 8-byte pieces. The rest part of data
is hashed using CRC32 functions with either 8 and 4 byte operands.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 33
Initially, SSE4.2 support is detected via CPUID instruction.
Added rte_hash_crc_set_alg() function to detect and set CRC32
implementation if necessary. SSE4.2 is allowed by default. If it's
not available, fall back to sw implementation.
Signed-off-by: Yerden Zhumabekov
---
lib/librte
leverages both versions of CRC32 hash
calculation functions with 4 and 8-byte operands.
Patches were tested on machines either with and without SSE4.2 support.
Software implementation seems to be about 15 times slower than SSE4.2-enabled
one. Of course, they return identical results.
Yerden
SSE4.2 provides _mm_crc32_u64 intrinsic with 8-byte operand.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 16
1 file changed, 16 insertions(+)
diff --git a/lib/librte_hash/rte_hash_crc.h b/lib/librte_hash/rte_hash_crc.h
index 3c368c5..74e2d92 100644
Add lookup table for CRC32 algorithm, crc32c_1word() and
crc32c_2words() functions returning hash of 32-bit and
64-bit operand.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 105
1 file changed, 105 insertions(+)
diff --git a
17.11.2014 17:31, Neil Horman ?:
> On Sun, Nov 16, 2014 at 11:59:16PM +0600, Yerden Zhumabekov wrote:
>> This is a rework of my previous patches improving performance of
>> rte_hash_crc. In addition, this revision brings a fallback mechanism to
>> ensure that CRC
an remove CRC32_AUTODETECT, and remove:
> if (unlikely(crc32_alg == CRC32_AUTODETECT))
>rte_hash_crc_set_alg(CRC32_SSE42);
> from rte_hash_crc_*byte().
Nice feature I was unfamiliar with :)
Since I'm going to revise the patch series anyway, I'll apply it and
test. Thank you.
--
Sincerely,
Yerden Zhumabekov
State Technical Service
Astana, KZ
SSE4.2 provides _mm_crc32_u64 intrinsic with 8-byte operand.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 16
1 file changed, 16 insertions(+)
diff --git a/lib/librte_hash/rte_hash_crc.h b/lib/librte_hash/rte_hash_crc.h
index 4d7532a..15f687a 100644
startup.
Patches were tested on machines either with and without SSE4.2 support.
Software implementation seems to be about 4-5 times slower than SSE4.2-enabled
one. Of course, they return identical results.
Yerden Zhumabekov (5):
hash: add software CRC32 implementation
hash: add new
Add lookup tables for CRC32 algorithm, crc32c_1word() and
crc32c_2words() functions returning hash of 32-bit and
64-bit operand.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 316
1 file changed, 316 insertions(+)
diff --git a
lable algorithm
may be detected upon application startup.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 64 ++--
1 file changed, 62 insertions(+), 2 deletions(-)
diff --git a/lib/librte_hash/rte_hash_crc.h b/lib/librte_hash/rte_hash_
Calculating hash for data of variable length is more efficient
when that data is sliced into 8-byte pieces. The rest part of data
is hashed using CRC32 functions with either 8 and 4 byte operands.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 33
Since rte_hash_crc() can now be run regardless of SSE4.2 support,
we can safely remove compile checks for RTE_MACHINE_CPUFLAG_SSE4_2
in test utilities.
Signed-off-by: Yerden Zhumabekov
---
app/test/test_hash.c |7 ---
app/test/test_hash_perf.c | 11 ---
2 files changed
Sorry, maybe I made a mistake here.
Accoring to lib/librte_eal/common/eal_common_cpuflags.c code, it seemed
to me that constructor attribute is not supported by intel compiler. So
in that case here I decided to leave the code for autodetection. Am I
correct?
18.11.2014 9:21, Yerden Zhumabekov
18.11.2014 19:33, Neil Horman ?:
> On Tue, Nov 18, 2014 at 10:56:24AM +0600, Yerden Zhumabekov wrote:
>> Sorry, maybe I made a mistake here.
>>
>> Accoring to lib/librte_eal/common/eal_common_cpuflags.c code, it seemed
>> to me that constructor attribute is not supp
startup.
* compared to v3, icc-specific code was removed
Patches were tested on machines either with and without SSE4.2 support.
Software implementation seems to be about 4-5 times slower than SSE4.2-enabled
one. Of course, they return identical results.
Yerden Zhumabekov (5):
hash: add software
Add lookup tables for CRC32 algorithm, crc32c_1word() and
crc32c_2words() functions returning hash of 32-bit and
64-bit operand.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 316
1 file changed, 316 insertions(+)
diff --git a
SSE4.2 provides _mm_crc32_u64 intrinsic with 8-byte operand.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 16
1 file changed, 16 insertions(+)
diff --git a/lib/librte_hash/rte_hash_crc.h b/lib/librte_hash/rte_hash_crc.h
index 4d7532a..15f687a 100644
ation startup
through the constructor function rte_hash_crc_try_sse442().
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 53 ++--
1 file changed, 51 insertions(+), 2 deletions(-)
diff --git a/lib/librte_hash/rte_hash_crc.h b/lib/librte
Calculating hash for data of variable length is more efficient
when that data is sliced into 8-byte pieces. The rest part of data
is hashed using CRC32 functions with either 8 and 4 byte operands.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 33
Since rte_hash_crc() can now be run regardless of SSE4.2 support,
we can safely remove compile checks for RTE_MACHINE_CPUFLAG_SSE4_2
in test utilities.
Signed-off-by: Yerden Zhumabekov
---
app/test/test_hash.c |7 ---
app/test/test_hash_perf.c | 11 ---
2 files changed
18.11.2014 20:41, Neil Horman ?:
> On Tue, Nov 18, 2014 at 08:03:40PM +0600, Yerden Zhumabekov wrote:
>> Initially, SSE4.2 support is detected via CPUID instruction.
>>
>> Added rte_hash_crc_set_alg() function to detect and set CRC32
>> implementation if nece
18.11.2014 22:00, Neil Horman ?:
> On Tue, Nov 18, 2014 at 09:06:35PM +0600, Yerden Zhumabekov wrote:
>> 18.11.2014 20:41, Neil Horman ?:
>>> On Tue, Nov 18, 2014 at 08:03:40PM +0600, Yerden Zhumabekov wrote:
>>>> /**
>>>> * Use single crc32
18.11.2014 23:46, Neil Horman ?:
> On Tue, Nov 18, 2014 at 11:13:17PM +0600, Yerden Zhumabekov wrote:
>> 18.11.2014 22:00, Neil Horman ?:
>>>
>>> You need to edit the makefile so that the compiler gets passed the option
>>> -msse42. That way it will
19.11.2014 3:36, Neil Horman ?:
> On Tue, Nov 18, 2014 at 05:52:27PM +, Bruce Richardson wrote:
>> On Tue, Nov 18, 2014 at 12:46:19PM -0500, Neil Horman wrote:
>>> On Tue, Nov 18, 2014 at 11:13:17PM +0600, Yerden Zhumabekov wrote:
>>>> Everyb
X2 instructions since that version.
Use -mavx2 or -march=core-avx2. The latter seems to be supported by ICC
as well, according to Google :)
--
Sincerely,
Yerden Zhumabekov
State Technical Service
Astana, KZ
2_crc32di
functions do the trick? ICC has them?
What about prototyping functions and extracting their bodies to separate
module? Does it break anything?
--
Sincerely,
Yerden Zhumabekov
State Technical Service
Astana, KZ
Nios II targets only. The options supported are specific to each target.
>
> On the 386, the following options are allowed:
> ...
> ?sse4.2?
> ?no-sse4.2?"
>
> Wouldn't that suit your purposes?
> Probably you can even keep your function inline with that approach.
Very nice. Thank you. I will test it.
--
Sincerely,
Yerden Zhumabekov
State Technical Service
Astana, KZ
19.11.2014 21:07, Neil Horman ?:
> On Wed, Nov 19, 2014 at 05:35:51PM +0600, Yerden Zhumabekov wrote:
>> static inline uint32_t
>> crc32_sse42_u32(uint32_t data, uint32_t init_val)
>> {
>> /*??__asm__ volatile(
>> "crc32l %[data], %[init_
and test_hash.
* setting default algorithm implementation as a constructor while application
startup.
* SSE4.2 intrinsics are implemented through inline assembly code.
* added additional run-time check for 64-bit support.
Yerden Zhumabekov (7):
hash: add software CRC32 implementation
hash
Add lookup tables for CRC32 algorithm, crc32c_1word() and crc32c_2words()
functions returning hash of 32-bit and 64-bit operand.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 316
1 file changed, 316 insertions(+)
diff --git a
Added:
- crc32c_sse42_u32() emits 'crc32l' asm instruction;
- crc32c_sse42_u64() emits 'crc32q' asm instruction;
- crc32c_sse42_u64_mimic(), wrapper in case of run on 32-bit platform.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/r
Give up using built-in intrinsics and use our own assembly
implementation. Remove #include entry as well.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lib/librte_hash/rte_hash_crc.h b/lib/librte_hash
SSE4.2 provides CRC32 intrinsic with 8-byte operand.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 16
1 file changed, 16 insertions(+)
diff --git a/lib/librte_hash/rte_hash_crc.h b/lib/librte_hash/rte_hash_crc.h
index cd28833..2c8ec99 100644
--- a
Calculating hash for data of variable length is more efficient
when that data is sliced into 8-byte pieces. The rest part of data
is hashed using CRC32 functions with either 8 and 4 byte operands.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_hash/rte_hash_crc.h | 33
1 - 100 of 109 matches
Mail list logo
