Hi Marco,
Wondering if you still have this issue and had time to debug it further?
Regards,
Sergio
On 30/05/2017 08:10, Marco Varlese wrote:
On Mon, 2017-05-29 at 16:20 +0100, Sergio Gonzalez Monroy wrote:
On 29/05/2017 15:54, Marco Varlese wrote:
On Mon, 2017-05-29 at 15:35 +0100, Sergio Go
On Mon, 2017-05-29 at 16:20 +0100, Sergio Gonzalez Monroy wrote:
> On 29/05/2017 15:54, Marco Varlese wrote:
> >
> > On Mon, 2017-05-29 at 15:35 +0100, Sergio Gonzalez Monroy wrote:
> > >
> > > Hi,
> > >
> > > I have not seen that behavior before.
> > >
> > > The dpdk_crypto_sw is only for enab
On 29/05/2017 15:54, Marco Varlese wrote:
On Mon, 2017-05-29 at 15:35 +0100, Sergio Gonzalez Monroy wrote:
Hi,
I have not seen that behavior before.
The dpdk_crypto_sw is only for enabling SW crypto, the default is to
support just HW crypto devices.
I cannot think of a reason why you would se
On Mon, 2017-05-29 at 15:35 +0100, Sergio Gonzalez Monroy wrote:
> Hi,
>
> I have not seen that behavior before.
>
> The dpdk_crypto_sw is only for enabling SW crypto, the default is to
> support just HW crypto devices.
>
> I cannot think of a reason why you would see that behavior.
> Basically
Hi,
I have not seen that behavior before.
The dpdk_crypto_sw is only for enabling SW crypto, the default is to
support just HW crypto devices.
I cannot think of a reason why you would see that behavior.
Basically we just check if we found enough DPDK/Cryptodev HW crypto
devices for the numbe
Hi all,
I pulled the latest code from master branch last week and I'm seeing something
new and related (possibly) to the Cryptodev support in VPP/DPDK.
The issue is that it now takes much longer for VPP to initialize... eventually
printing out the message:
"not enough Cryptodevs, default to OpenS