Hi Christian,
I don't think you have missed anything, as far as I can tell it is a bug.
Wondering how it is done in the non-DPDK case with handoff. I don't know
the handoff internals but from a quick glance, and I might be wrong here,
it seems that you would run into a similar situation.
Cheers,
Hi Jitendra,
I have not followed DPDK Cryptodev development over the last year, but
given my vague memory and latest VPP code, I reckon your configuration is
not supported.
The cryptodev scheduler supports common cipher/auth algorithms among all
slaves, which in your case is none.
Which VPP
+1
Cheers,
Sergio
On Wed, Feb 27, 2019 at 2:21 PM Damjan Marion via Lists.Fd.Io wrote:
> +1
>
> On 27 Feb 2019, at 14:20, Dave Barach via Lists.Fd.Io <
> dbarach=cisco@lists.fd.io> wrote:
>
> +1... Dave
>
> *From:* vpp-dev@lists.fd.io *On Behalf Of *Dave
> Barach via Lists.Fd.Io
> *Sent:*
Hi Manuel,
Thanks for reporting back.
Cheers,
Sergio
On Tue, Feb 12, 2019 at 5:14 PM wrote:
> Hi Sergio,
>
> ipsec is actually working(therefore also your patch), my issue was
> regarding dpdk and hw setup.
>
> BR,
> Manuel -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to
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
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
Have you tried using the OpenSSL backend instead of cryptodev ?
Just wondering if there is a bug in the transport mode case in the DPDK
code.
Looking at the trace again, the src/dst mac seems to be ok, yet the
ethertype is already 0 on the sender side after crypto.
On Thu, Feb 7, 2019 at 1:48 PM
Hi Manuel,
If I am not mistaken, you should be able to forward the same traffic if you
disable ipsec, have you tried that with success?
On Thu, Feb 7, 2019 at 11:15 AM wrote:
> Hi Sergio,
>
> you are right, both boards are connected back to back in the
> 192.168.30.0/24 net.
> I have cleaned
Hi Manuel,
Could you try modifying your config with something like below?
By the way, I am not sure you need to set any arp entries, I am assuming
you have connected back-to-back the interfaces with IPs in the
192.168.30.0/24 net.
You can check with 'show ip arp' that you have entries for the
Hi Manuel,
I was having another look at this. Could you provide the configuration
commands you have used to setup ipsec sa/spd etc ?
Regards,
Sergio
On Fri, Feb 1, 2019 at 2:13 PM wrote:
> capture and config. attached -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this
node distances:
>
> node 0 1 2 3
>
> 0: 10 16 16 16
>
> 1: 16 10 16 16
>
> 2: 16 16 10 16
>
> 3: 16 16 16 10
>
> [root@cl41 ~]#
>
>
>
> Might there be confusion between “NUMA node” and “socket_id” definitions?
>
> My
o Devices, Inc. [AMD] Device
> 1468
>
> NUMA node: 2
>
> ...
>
> 62:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Family
> 17h (Models 00h-0fh) Platform Security Processor
>
> NUMA node: 3
>
> ...
>
> 63:00.1 Encryption controlle
Hi Lee,
Looking at your startup.conf below, are you sure those parameters are
correct? are you running 4 numa node platform?
If that is the case, you should also use cores from each numa node.
vdev crypto_ccp0,socket_id=0
vdev crypto_ccp1,socket_id=1
vdev crypto_ccp2,socket_id=2
vdev
Hi,
I have to admit that the intention (when I wrote the code) of the
__attribute__ ((aligned(64))) on the typedef struct was to have elements
properly sized.
I thought to remember that I did look at this attribute behavior before but
then again my memory is not as reliable as I wish for, so
14 matches
Mail list logo
