Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/6] eal/interrupts: implement get set APIs

[Thomas Monjalon <thomas@monjalon.net>]

14/10/2021 19:53, Dmitry Kozlyuk:
> 2021-10-14 17:15 (UTC+0000), Harman Kalra:
> > > > +	rte_intr_type_set;
> > > > +	rte_intr_type_get;
> > > > +	rte_intr_instance_alloc;
> > > > +	rte_intr_instance_free;
> > > >  };  
> > > 
> > > Do I understand correctly that these exports are needed to allow an
> > > application to use DPDK callback facilities for its own interrupt sources?  
> > 
> > I exported only those APIs which are currently used by test suite or example
> > applications, may be later more APIs can be moved from internal to public on
> > need basis.
> > 
> > > If so, I'd suggest that instead we export a simpler set of functions:
> > > 1. Create/free a handle instance with automatic fixed type selection.
> > > 2. Trigger an interrupt on the specified handle instance.
> > > The flow would be that the application listens on whatever it wants, probably
> > > with OS-specific mechanisms, and just notifies the interrupt thread about
> > > events to trigger callbacks.
> > > Because these APIs are experimental we don't need to change it now, just my
> > > thoughts for the future.  
> > 
> > I am sorry but I did not followed your suggestion, can you please explain.
> 
> These API is used as follows. The application has a file descriptor
> that becomes readable on some event. The programmer doesn't want to create
> another thread like EAL interrupt thread, implement thread-safe callback
> registration and invocation. They want to reuse DPDK mechanism instead.
> So they create an instance of type EXT and give it the descriptor.
> In case of the unit test the descriptor is a pipe read end.
> In case of a real application it can be a socket, like in mlx5 PMD.
> This is often convenient, but not always. An event may be a signal,
> or busy-wait end, or it may be Windows with its completely different IO model
> (it's "issue an IO, wait for completion" instead of POSIX
> "wait for IO readiness, do a blocking IO").
> In all these cases the user needs to create a fake pipe (or whatever)
> to fit into how the interrupt thread waits for events.
> But what the application really needs is to say "there's an event, please run
> the callback on this handle". It's a function call that doesn't require any
> explicit file descriptors or handles, doesn't rely on any IO model.
> How it is implemented depends on the EAL, for POSIX it will probably be
> an internal pipe, Windows can use APC as in eal_intr_thread_schedule().
> Again, I'm thinking out loud here, nothing of this needs to be done now.

I like this way of thinking.