So I have tried both IPsec ESP in transport mode with aes-gcm and aes-cbc
and it does encrypt properly.
In the test I'm using VPP 19.01 release with software cryptodevs and the
built-in packet-generator:
00:00:07:563578: ipsec4-output-feature
spd 1
00:00:07:563595: dpdk-esp4-encrypt
cipher aes
Hi Sergio,
thank you for your comment, I will try to debug the problem ASAP.
BR,
Manuel
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12213): https://lists.fd.io/g/vpp-dev/message/12213
Mute This Topic: https://lists.fd.io/mt/29538345/21656
Mute
Hi all,
reading a piece of code( *src/vnet/llc/node.c* ) I noticed that llc_input is
almost the same as function snap_input( *src/vnet/snap/node.c* )...
but there is a different line and I would like to understand the reason, may be
is the same having or not that line but I am not sure.
*src/vne
Hi Manuel,
I forgot to mention that the test I performed does not validate the HW
crypto device case, ie. there could be a bug in the DMA addresses for the
crypto op. I do not have any crypto HW to test but afaik CSIT does run a
few different use cases using HW crypto.
HTH,
Sergio
On Fri, Feb 8,
Hi everyone,
I’m very happy to announce that the first hICN release is out.
hICN 19.01 release makes use of VPP 19.01 and artifacts are
available on package cloud.
hICN (hybrid ICN) is composed of a server stack (network + transport)
based on VPP and a client portable stack (macO
If yes, why the frame needs to traverse two directions?Should it not
traverse only feature-arc?
The flow is in one direction only.
Every node has speculated "next_index" node. If the speculated "next_index"
node is not same as actual "next0" node (which is typically retrieved by
either pa
The discussion about feature arcs is a red herring with respect to the buffer
enqueue dance. It's about node A enqueueing to its successor nodes B, C, D,
etc. It's the same whether or not A (and friends) are part of a feature arc.
The feature arc code manages the set of successor nodes, and has
Hi,
Assuming the heap is sufficiently dimensioned, can any size be
requested from clib_mem_alloc which fits in u32 ? Are there any issues
if higher sizes are requested eg. can clib_mem_alloc actually return a
pointer but the allocated size is not as much as the requested size ?
Perhaps it is biza
Due to overhead, you won't be able to allocate 0x bytes (4gb-1), but in
the size range you're describing there are no known first-order obvious problem
with the memory allocator.
I don't blame you for asking, but I'm afraid it's likely that you have a
dangling reference in your app code
Folks,
Here is a short VoD which shows how to capture and visualize fine-grained event
log data: https://youtu.be/KwHOgdm3_sY
HTH... Dave
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12221): https://lists.fd.io/g/vpp-dev/message/12221
Mute Th
Most excellent!
Another fine tool in the VPP toolbox.
Thanks,
-daw-
On 02/06/2019 04:23 PM, Dave Barach via Lists.Fd.Io wrote:
See https://youtu.be/wmp3X8NipEM...
HTH... Dave
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12197): https://li
11 matches
Mail list logo
