> >
> > Hi Akhil,
> >
> > >
> > > Hi Anoob/Konstantin,
> > > > >
> > > > > Check that ops->get_userdata is a valid function pointer will be
> > > > > compiled
> > out.
> > > > > So PMDs that don't implement this function will crash in
> > > > > rte_security_get_userdata().
> > > > > In our parti
>
> Hi Akhil,
>
> >
> > Hi Anoob/Konstantin,
> > > >
> > > > Check that ops->get_userdata is a valid function pointer will be
> > > > compiled
> out.
> > > > So PMDs that don't implement this function will crash in
> > > > rte_security_get_userdata().
> > > > In our particular case - ixgbe.
>
Hi Akhil,
>
> Hi Anoob/Konstantin,
> > >
> > > Check that ops->get_userdata is a valid function pointer will be compiled
> > > out.
> > > So PMDs that don't implement this function will crash in
> > > rte_security_get_userdata().
> > > In our particular case - ixgbe.
> > > Same story with rte_s
W dniu 23.04.2020 o 14:55, Akhil Goyal pisze:
> Hi Anoob/Konstantin,
>>> Check that ops->get_userdata is a valid function pointer will be compiled
>>> out.
>>> So PMDs that don't implement this function will crash in
>>> rte_security_get_userdata().
>>> In our particular case - ixgbe.
>>> Same s
Hi Anoob/Konstantin,
> >
> > Check that ops->get_userdata is a valid function pointer will be compiled
> > out.
> > So PMDs that don't implement this function will crash in
> > rte_security_get_userdata().
> > In our particular case - ixgbe.
> > Same story with rte_security_set_pkt_metadata() - s
RE: [dpdk-dev] [PATCH] security: fix crash at accessing non-
> implemented ops
>
> External Email
>
> --
>
> > > >
> > > > These are data path ops and so it will be better if we can avoid
> &
> > >
> > > These are data path ops and so it will be better if we can avoid such
> > > checks in
> > the datapath. The same is done in ethdev also.
> >
> > AFAIK, get_userdata is an *optional* dev-ops function that can be used by
> > data-
> > path.
> > So far there was no strict requirement
dev] [PATCH] security: fix crash at accessing non-
> implemented ops
>
> External Email
>
> --
> >
> > Hi Konstantin,
> >
> > These are data path ops and so it will be better if we can a
> W dniu 23.04.2020 o 06:07, Anoob Joseph pisze:
> > Hi Konstantin,
> >
> > These are data path ops and so it will be better if we can avoid such
> > checks in the datapath. The same is done in ethdev also.
> >
> > https://protect2.fireeye.com/url?k=d44931cf-89d2cdac-d448ba80-0cc47a31cdbc-
> 8281
> >> Hi Konstantin,
> >>
> >> These are data path ops and so it will be better if we can avoid such
> >> checks in the datapath. The same is done in ethdev also.
> > AFAIK, get_userdata is an *optional* dev-ops function that can be used by
> > data-path.
> > So far there was no strict requireme
> -Original Message-
> From: Lukasz Wojciechowski
> Sent: Thursday, April 23, 2020 9:06 AM
> To: Ananyev, Konstantin ; Anoob Joseph
> ; dev@dpdk.org
> Cc: akhil.go...@nxp.com; Doherty, Declan ;
> techbo...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] security
W dniu 23.04.2020 o 09:54, Ananyev, Konstantin pisze:
>> Hi Konstantin,
>>
>> These are data path ops and so it will be better if we can avoid such checks
>> in the datapath. The same is done in ethdev also.
> AFAIK, get_userdata is an *optional* dev-ops function that can be used by
> data-pat
W dniu 23.04.2020 o 06:07, Anoob Joseph pisze:
> Hi Konstantin,
>
> These are data path ops and so it will be better if we can avoid such checks
> in the datapath. The same is done in ethdev also.
>
> https://protect2.fireeye.com/url?k=d44931cf-89d2cdac-d448ba80-0cc47a31cdbc-8281a62b4c91d848&q=1
W dniu 23.04.2020 o 02:11, Ananyev, Konstantin pisze:
> Actually looking at app/test/test_security.c
> I also see a few '#ifdef RTE_DEBUG's.
> Let say:
>
> +static int
> +test_get_userdata_inv_context(void)
> +{
> +#ifdef RTE_DEBUG
> + uint64_t md = 0xDEADBEEF;
> +
> + void *ret = rte
>
> Hi Konstantin,
>
> These are data path ops and so it will be better if we can avoid such checks
> in the datapath. The same is done in ethdev also.
AFAIK, get_userdata is an *optional* dev-ops function that can be used by
data-path.
So far there was no strict requirement for the rte_secur
Hi Konstantin,
These are data path ops and so it will be better if we can avoid such checks in
the datapath. The same is done in ethdev also.
http://code.dpdk.org/dpdk/v20.02/source/lib/librte_ethdev/rte_ethdev.h#L4372
Datapath functions in cryptodev (enqueue/dequeue) doesn't even have such che
Actually looking at app/test/test_security.c
I also see a few '#ifdef RTE_DEBUG's.
Let say:
+static int
+test_get_userdata_inv_context(void)
+{
+#ifdef RTE_DEBUG
+ uint64_t md = 0xDEADBEEF;
+
+ void *ret = rte_security_get_userdata(NULL, md);
+ TEST_ASSERT_MOCK_FUNCTION_CALL_RET(
17 matches
Mail list logo
