[PATCH] eng: Add performance specification items

[Gedare Bloom]

On Wed, Nov 25, 2020 at 7:38 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> Hello,
>
> On 14/11/2020 12:59, Sebastian Huber wrote:
> > On 13/11/2020 20:03, Gedare Bloom wrote:
> >
> >>> +Generic Non-Functional Requirement Item Type
> >>> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>> +
> >>> +This type refines the following types:
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >> through?
> > Nice an automatically generated typo.
> >>
> >>> +  ``non-functional-type`` attribute if the value is
> >>> ``build-configuration``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> +  ``non-functional-type`` attribute if the value is ``constraint``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> +  ``non-functional-type`` attribute if the value is ``design``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> +  ``non-functional-type`` attribute if the value is ``documentation``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> +  ``non-functional-type`` attribute if the value is ``interface``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> +  ``non-functional-type`` attribute if the value is
> >>> ``interface-requirement``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> +  ``non-functional-type`` attribute if the value is
> >>> ``maintainability``
> >>> +
> >>> +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
> >>> +  ``non-functional-type`` attribute if the value is ``performance``
> >>> +
> >> Is there a specific kind of performance (metric) in mind? latency vs
> >> throughput? Or does it not matter
> >>
> > In the generic non-functional requirements, the requirements text is
> > in natural language. So, you can write whatever you want.
> >
> > This patch introduces a specialization for performance requirements
> > which are expressed in limits of a sample set of some measured runtime
> > of an operation.
> >
> > text: |
> >   When a partition has exactly
> > ${../val/performance:/params/buffer-count} free
> >   buffers, the ${.:limit-kind} runtime of exactly
> >   ${../val/performance:/params/sample-count} successful calls to
> >   ${../if/get-buffer:/name} in the ${.:/environment} shall be
> >   ${.:limit-condition}.
> >
> > In this item, the corresponding test code is also included.
> >
> > test-body:
> >   brief: |
> >     Get a buffer.
> >   code: |
> >     ctx->status = rtems_partition_get_buffer( ctx->part_many,
> > &ctx->buffer );
> >   description: null
>
> I think this can be checked in independent of the open discussion how a
> particular performance limit is identified. The item just uses a string
> to identify a set of performance limits. An open issue is how this
> string is generated and what data it includes.
>
> I already fixed the "though" -> "through" typo.
>
> Fine with me


> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hubere at embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201125/313f7d9b/attachment.html>