05/02/2022 05:41, Tyler Retzlaff:
> On Fri, Feb 04, 2022 at 07:21:10PM +0000, Ananyev, Konstantin wrote:
> > > +int
> > > +rte_thread_attr_init(rte_thread_attr_t *attr)
> > > +{
> > > + RTE_VERIFY(attr != NULL);
> >
> > As a generic one, here and everywhere:
> > Please don't use RTE_VERIFY() for checking input function parameters.
> > We don't want to panic in case of just invalid parameter from user.
>
> i ask this question again. what useful thing will the user application
> do when handling -EINVAL or rte_errno = EINVAL is returned for
> incorrectly supplied parameters?
>
> again, there should be a mechanism that allows a policy for how these
> non-recoverable errors are handled rather than defaulting to tossing
> it over the fence and expecting the application to do something
> sensible when the only thing it could do is conclusively more
> complicated than having passed the correct parameters in the first place.
>
> more often then not application programmers will ignore superfluous
> return values from functions like this resulting in the bug remaining
> longer and the state / reason being lost.
>
> please reconsider.
The application should just abort this feature indeed.
But remember the application can have other features.
In some applications, the DPDK features are a minor part.
So we don't want to crash the entire application just because
a DPDK feature has a bug.
More generally, a library should never crash an entire application.
