Re: [SPDK] SPDK Event notifications

[Pelplinski, Piotr <piotr.pelplinski at intel.com>]

[-- Attachment #1: Type: text/plain, Size: 3222 bytes --]



-- 
Best Regards,
Piotr Pelpliński


> -----Original Message-----
> From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Walker, Benjamin
> Sent: Wednesday, October 10, 2018 7:17 PM
> To: spdk(a)lists.01.org
> Subject: Re: [SPDK] SPDK Event notifications
> 
> On Wed, 2018-10-10 at 15:38 +0000, Wodkowski, PawelX wrote:
> > See comments inline.
> >
> > Paweł
> >
> > > From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Pelplinski, Piotr
> > >
> > > Hi,
> > > I started work on SPDK event notifications.  I have few doubts that you
> > > might help me resolve.
> > > This functionality adds ability to register for specific events (i.e. a new
> > > bdev), and be notified asynchronously when those events occur.
> > >
> > > My proposal is three RPC calls based on following workflow:
> > >
> > > 1.      After SPDK application starts, client sends RPCs to SPDK about what
> > > kinds of events it wants to register for.
> > >
> > > 2.      Then, client subscribes to specified events.
> > >
> > > 3.      Then the client periodically asks for new events.
> >
> > Why client need to ask for new event? Why event can't be send just send to all
> > clients ASAP they available?
> > You will have to track what events was send to what clients.
> 
> I think the above statement about tracking which events to send to which client
> outlines the major problem here. Tracking which events each client needs is very
> difficult - for instance, how long do you keep events around? A client could
> check in once a month, for example. Further, how many simultaneous clients do
> we
> need to keep track of? How much memory is that going to take? I'm positive
> that
> we don't want to go down this path.
> 
> Clients already have the ability to simply poll the state of the system by
> periodically issuing RPCs. That's good enough for most cases and is entirely
> stateless (the REST paradigm - we even use JSON!). We could consider an event
> stream API as an optimization only, where clients send an RPC and the response
> contains a file descriptor (maybe a domain socket?) where a stream of JSON
> objects corresponding to events as they happen is published (but not events
> from
> before the connection was established). A client would then begin by sending
> the
> existing RPCs to gather the current state of the world, then subscribe to this
> event API for changes only.
> 

How about returning events in response to RPC Call?

Client discovers events by calling show_events, then connects to RPC server
and asynchronously receives events as long as it is connected.

This way we have true asynchronous API. It doesn’t require caching of events or 
allocating any special resources or memory. 

Disconnected clients (i.e. due to reboot) would not receive those events, but do they
really want to receive them? I think that client after reboot would like to read entire
SPDK state anyway.

I updated trello card as well: 
https://trello.com/c/ZTIHxp3w/28-spdk-event-notifications

> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk