Re: [PATCH v18 2/8] eal: add thread attributes

[Tyler Retzlaff <roretzla@linux.microsoft.com>]

On Sat, Feb 05, 2022 at 10:00:01AM +0100, Thomas Monjalon wrote:
> 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.
> 
> 

you haven't addressed my concern. when deployed at scale i need to be
able to capture the state of what was wrong in order to debug the
problem. a crash dump does this.

i agree that the dpdk functionality may be shared/hosted in a process
that does other work but this api hard-codes a behavior that does not
permit easy diagnostics of buggy usage of api vs actual errors. there
is a distinction and it is important.

with the api hard-coded to a single policy you leave the application
author only the option of wrapping every single api in some boilerplate
error handling logic that has to teadeously log part of the application
state (hopefully the part you need)  from the current scope before
explicitly exiting.

as i explained previously i'm not asking that dpdk hard-codes a policy
of crashing either. we just need it to be a choice rather than forcing a
single hard-coded behavior.