From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============3089757064529754652==" MIME-Version: 1.0 From: Pelplinski, Piotr Subject: Re: [SPDK] SPDK Event notifications Date: Fri, 12 Oct 2018 13:15:32 +0000 Message-ID: In-Reply-To: 0c9766a9f2e8e31bcc7868440544a6d7268d2ce4.camel@intel.com List-ID: To: spdk@lists.01.org --===============3089757064529754652== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable -- = Best Regards, Piotr Pelpli=C5=84ski > -----Original Message----- > From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Walker, Benj= amin > 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=C5=82 > > > > > From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Pelplins= ki, 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 abou= t 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 co= uld > check in once a month, for example. Further, how many simultaneous client= s 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 entir= ely > stateless (the REST paradigm - we even use JSON!). We could consider an e= vent > stream API as an optimization only, where clients send an RPC and the res= ponse > contains a file descriptor (maybe a domain socket?) where a stream of JSON > objects corresponding to events as they happen is published (but not even= ts > from > before the connection was established). A client would then begin by send= ing > 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=E2=80=99t require caching = of events or = allocating any special resources or memory. = Disconnected clients (i.e. due to reboot) would not receive those events, b= ut 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 --===============3089757064529754652==--