(Catching up with all emails exchanged during my vacation). Whenever an API has a create call, there should be a corresponding destroy call that reverses the effects of the create call.
Resetting and freeing up HW resources ought to the be responsibility of the OS and the hypervisor (if any). But if an application uses the destroy calls in an appropriate way, it should be possible for the application to reverse all resource allocation and initialisation, thus enabling the application to restart (indefinitely) without OS/HV intervention. Is this required behaviour? Should we have a test case for this? On 15 July 2014 21:35, Bill Fischofer <[email protected]> wrote: > Thanks Mike. I've assigned the card to me and will take an initial stab > at summarizing the issues and proposals in arch doc format. > > Bill > > > On Tue, Jul 15, 2014 at 1:09 PM, Mike Holmes <[email protected]> > wrote: > >> After todays call it was clear that at the very least the ODP >> architecture document needs to spell out ODPs role in teardown. >> >> The issues were: >> The context within which ODP apis may be called. >> The graceful and abnormal termination cases. >> Define ODPs role, vs that of the application, vendor support and the HW >> in the tear down cases. >> >> I created a Linaro JIRA card https://cards.linaro.org/browse/CARD-1563 >> to capture this work item. >> >> >> On 11 July 2014 08:22, Bill Fischofer <[email protected]> wrote: >> >>> I can certainly add it to the agenda so we can get wider feedback on >>> this subject. >>> >>> Bill >>> >>> >>> On Fri, Jul 11, 2014 at 5:40 AM, Mike Holmes <[email protected]> >>> wrote: >>> >>>> What is the outcome of this thread - do we need to look at cleanup APIs >>>> ? >>>> >>>> Are there any more opinions on the list ? >>>> My feeling is we have a partial use case discussion and a general >>>> feeling that it is a good idea from a few others, I propose we bring this >>>> up in the Tuesday Call if possible. >>>> >>>> Mike >>>> >>>> >>>> On 9 July 2014 04:19, Maxim Uvarov <[email protected]> wrote: >>>> >>>>> On 07/09/2014 11:58 AM, Alexandru Badicioiu wrote: >>>>> >>>>>> In addition to "close" calls for queues, pktios, buffer pools, etc >>>>>> there might be hardware resources requested from the specific device >>>>>> drivers during global and local initialization and required for queues, >>>>>> pktios, etc. >>>>>> These have to be returned to the drivers in order to avoid leaks and >>>>>> support application restart, for example. >>>>>> To handle this kind of cleanup I'm proposing to have explicit calls : >>>>>> odp_finish_local() and odp_finish_global() as counterparts for init >>>>>> calls. >>>>>> >>>>>> Alex >>>>>> >>>>> >>>>> +1 for odp_finish_xx() >>>>> >>>>> Maxim. >>>>> >>>>>> >>>>>> >>>>>> On 8 July 2014 19:42, Bill Fischofer <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> The problem with an innocent-looking cleanup call is that is makes >>>>>> it easy to assume that ODP is keeping track of a lot of things >>>>>> that clearly it isn't. Does ODP know how many buffer pools have >>>>>> been allocated so that they'll be released at cleanup? Does ODP >>>>>> track which queues have been allocated or contain pending events >>>>>> that need to be flushed? Or threads? Or any number of other >>>>>> resources? Do we want ODP to be doing that sort of tracking? >>>>>> Clearly not. >>>>>> >>>>>> Graceful cleanup in general is a lot more complex than >>>>>> initialization because initialization starts from and idle system >>>>>> with nothing going on. By contrast, once a system is up and >>>>>> running there are all sorts of loosely-tracked things "in motion" >>>>>> that need to be stopped and recovered for an orderly return to an >>>>>> idle state (from which a new init can be started) can be >>>>>> successful. >>>>>> >>>>>> Abnormal termination processing doesn't have to worry about this >>>>>> because it makes no pretense of being surgical. I just don't see >>>>>> a real need for this sort of thing (and the resources needed to >>>>>> develop and test it) being high on the priority list for ODP given >>>>>> it's intended use. >>>>>> >>>>>> Whether or not we want to pursue this, we certainly need to add >>>>>> the "bracketing" close calls for things like queues, pktio, etc. >>>>>> first since they'd be needed as a precursor to any general >>>>>> cleanup. So I'd start with these. >>>>>> >>>>>> >>>>>> On Tue, Jul 8, 2014 at 10:35 AM, Mike Holmes >>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>> >>>>>> I would couple of points >>>>>> >>>>>> 1. A clean up hook imposes no overhead if not needed, it can >>>>>> >>>>>> be compiled out transparently if there is no content for a >>>>>> given platform. >>>>>> 2. I find symmetry is generally beneficial, being able to >>>>>> >>>>>> undo something can simplify code and provide a contract >>>>>> with the application that it things are available for >>>>>> reuse at a defined point. >>>>>> 3. SoCs are used in complex systems where "hooks" can often >>>>>> >>>>>> allow use cases or "silicon patches" that expand on the >>>>>> originally imaged utility of a device. >>>>>> >>>>>> >>>>>> >>>>>> On 8 July 2014 10:25, Santosh Shukla >>>>>> <[email protected] <mailto:[email protected] >>>>>> >> >>>>>> >>>>>> wrote: >>>>>> >>>>>> On 8 July 2014 19:54, Bill Fischofer >>>>>> <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> > By discarded I mean the old VM is terminated. All >>>>>> hypervisors automatically >>>>>> > clean up terminated VMs the same way that Linux cleans >>>>>> up terminated >>>>>> > processes. This does not involve the cooperation of the >>>>>> entity being >>>>>> > terminated since it may be in an error state and >>>>>> non-functional anyway. >>>>>> > >>>>>> >>>>>> Now, It make sense to me, thanks :) >>>>>> > >>>>>> > On Tue, Jul 8, 2014 at 9:21 AM, Santosh Shukla >>>>>> <[email protected] <mailto:santosh.shukla@linaro. >>>>>> org>> >>>>>> >>>>>> > wrote: >>>>>> >> >>>>>> >> On 8 July 2014 19:34, Bill Fischofer >>>>>> <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >> > VM migration is transparent to the VM, no? Quiescing >>>>>> operation (an >>>>>> >> > application function) is a different matter. In the >>>>>> case of NFV I'd >>>>>> >> > expect >>>>>> >> > instance A to be quiesced, (new) instance B to be >>>>>> started, and then >>>>>> >> > quiesced >>>>>> >> > flows to be restarted against instance B. Instance A >>>>>> is then discarded >>>>>> >> > so >>>>>> >> >>>>>> >> I am with till here except "discarded" - If you discard >>>>>> resource then >>>>>> >> those resource could be IO, Memory wont be reclaimed to >>>>>> hypervisor for >>>>>> >> use to another VM right? Or I am confused in understand >>>>>> discarded vs >>>>>> >> termination, I believe termination something mean to >>>>>> source VM >>>>>> >> explicitly free resources. >>>>>> >> >>>>>> >> > termination is a non-issue. >>>>>> >> >>>>>> >> > >>>>>> >> > >>>>>> >> > On Tue, Jul 8, 2014 at 8:58 AM, Lide, David >>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>> >> >> >>>>>> >> >> VM migration for SDN use case (where data plane may >>>>>> get moved) would be >>>>>> >> >> a >>>>>> >> >> use case where a cleanup API would be required. >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> regards, >>>>>> >> >> >>>>>> >> >> dave >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> From: [email protected] >>>>>> <mailto:[email protected]> >>>>>> >> >> [mailto:[email protected] >>>>>> >>>>>> <mailto:[email protected]>] On Behalf Of >>>>>> Bill Fischofer >>>>>> >> >> Sent: Tuesday, July 08, 2014 9:52 AM >>>>>> >> >> To: Alexandru Badicioiu >>>>>> >> >> Cc: [email protected] >>>>>> <mailto:[email protected]> >>>>>> >>>>>> >> >> Subject: Re: [lng-odp] ODP cleanup API >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> I'd like to understand the use case for such an API. >>>>>> Generally >>>>>> >> >> embedded >>>>>> >> >> systems (and that's what data plane applications >>>>>> are--switches, >>>>>> >> >> routers, >>>>>> >> >> etc.) are designed for continuous operation once >>>>>> they are initialized. >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> On Tue, Jul 8, 2014 at 8:40 AM, Alexandru Badicioiu >>>>>> >> >> <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >> >> >>>>>> >> >> Hi, >>>>>> >> >> >>>>>> >> >> I would like to get your comments related to having >>>>>> ODP cleanup API - >>>>>> >> >> the >>>>>> >> >> counterpart of init API. Perhaps not required for >>>>>> linux-generic >>>>>> >> >> implementation where all process memory, sockets, >>>>>> file handles are >>>>>> >> >> eventually returned to the OS, I think they are >>>>>> required to properly >>>>>> >> >> cleanup >>>>>> >> >> any allocation of HW resources. >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> Thanks, >>>>>> >> >> >>>>>> >> >> Alex >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> _______________________________________________ >>>>>> >> >> lng-odp mailing list >>>>>> >> >> [email protected] >>>>>> <mailto:[email protected]> >>>>>> >>>>>> >> >> http://lists.linaro.org/mailman/listinfo/lng-odp >>>>>> >> >> >>>>>> >> >> >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > _______________________________________________ >>>>>> >> > lng-odp mailing list >>>>>> >> > [email protected] >>>>>> <mailto:[email protected]> >>>>>> >>>>>> >> > http://lists.linaro.org/mailman/listinfo/lng-odp >>>>>> >> > >>>>>> > >>>>>> > >>>>>> >>>>>> _______________________________________________ >>>>>> lng-odp mailing list >>>>>> [email protected] <mailto:[email protected] >>>>>> > >>>>>> http://lists.linaro.org/mailman/listinfo/lng-odp >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- *Mike Holmes* >>>>>> >>>>>> Linaro Technical Manager / Lead >>>>>> LNG - ODP >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> lng-odp mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> >>>>>> http://lists.linaro.org/mailman/listinfo/lng-odp >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> lng-odp mailing list >>>>>> [email protected] >>>>>> http://lists.linaro.org/mailman/listinfo/lng-odp >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> lng-odp mailing list >>>>> [email protected] >>>>> http://lists.linaro.org/mailman/listinfo/lng-odp >>>>> >>>> >>>> >>>> >>>> -- >>>> *Mike Holmes* >>>> Linaro Technical Manager / Lead >>>> LNG - ODP >>>> >>>> _______________________________________________ >>>> lng-odp mailing list >>>> [email protected] >>>> http://lists.linaro.org/mailman/listinfo/lng-odp >>>> >>>> >>> >> >> >> -- >> *Mike Holmes* >> Linaro Technical Manager / Lead >> LNG - ODP >> > > > _______________________________________________ > lng-odp mailing list > [email protected] > http://lists.linaro.org/mailman/listinfo/lng-odp > >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
