From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============5347240054479490050=="
MIME-Version: 1.0
From: Andrey Kuzmin <andrey.v.kuzmin at gmail.com>
Subject: Re: [SPDK] SPDK Event notifications
Date: Thu, 11 Oct 2018 22:13:56 +0200
Message-ID: <CANvN+emwAZKsYdoWAo5zMS_T+1QOj71x2pxBhHfYOC_J1iuEGw@mail.gmail.com>
In-Reply-To: 0c9766a9f2e8e31bcc7868440544a6d7268d2ce4.camel@intel.com
List-ID: <spdk@lists.01.org>
To: spdk@lists.01.org

--===============5347240054479490050==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 10, 2018, 19:19 Walker, Benjamin <benjamin.walker(a)intel.com>
wrote:

> On Wed, 2018-10-10 at 15:38 +0000, Wodkowski, PawelX wrote:
> > See comments inline.
> >
> > Pawe=C5=82
> >
> > > 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 y=
ou
> > > 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.
>

Just curious, how does SPDK NVMe driver handle AENs then (if at all), as
the problem statement above is pretty similar to what AEN aimed to address?

Regards,
Andrey


> 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.
>
> > >
> > > RPC Calls:
> >
> > Are you describing the JSON RPC objects here or rpc.py commands?
> >
> > >
> > > 1.      show_async_events <component>
> > > component (optional) - show events for specified component only
> > >
> > > 2.      register_async_events <unique_id>, <events>
> > > unique_id - unique identifier for client
> >
> > What is the unique_id for? Isn't the connection itself an "unique id"
> enough?
>
> Presumably the client could crash, get restarted, and want to grab the
> events it
> missed by using the unique id.
>
> >
> >
> > > events - list of comma separated events which client wants to
> subscribe to.
> >
> >
> > > (Additional question: Does event should have parameters too? e.g.
> subscribe
> > > only to event: deletion of bdev with specific name)
> > > Response is a list of types of events to which client was subscribed.
> > >
> > > 3.      poll_async_events <unique_id>
> > > unique_id - unique identifier for client
> > > Response is a list of events which happen from last call, which
> include:
> > >
> > > -        Component, # component type for which event is raised
> > >
> > > -        Notification,  # type of event, e.g. add, delete or update
> > >
> > > -        Component_uuid, (e.g lvol uuid)
> > >
> > > -        Parent_uuid (e.g. lvolstore uuid)
> > >
> > > My question is what are the types of events we could register to?
> > > I can think of few generic bdev events like:
> > > -added bdev
> > > -deleted bdev
> > > -updated bdev
> > >
> > > What other types of event do you see?
> >
> > Runtime errors? Statistics? Nvmf/iscsi/vhost initiators connecting and
> > disconnecting.
> > There will be many more but the solution you are proposing should be
> generic
> > enough to easly add more event in the future. bdev subsystem good
> starting
> > point.
> >
> > >
> > > You can also look at the updates on this topic on trello:
> > > https://trello.com/c/ZTIHxp3w/28-asynchronous-rpc-notifications
> > >
> > > --
> > > Best Regards,
> > > Piotr Pelpli=C5=84ski
> > >
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk
>

--===============5347240054479490050==--