Message-ID: <CAHLZf_tzpG9J=_orUsD9xto_Q818S-YqOTFvWchFjRkR3LXhvA@mail.gmail.com>
Date:   Wed, 13 Jul 2022 12:10:50 +0530
From:   Vikas Gupta <vikas.gupta@...adcom.com>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     Jiri Pirko <jiri@...dia.com>, Jakub Kicinski <kuba@...nel.org>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>, dsahern@...nel.org,
        stephen@...workplumber.org, Eric Dumazet <edumazet@...gle.com>,
        pabeni@...hat.com, ast@...nel.org, leon@...nel.org,
        linux-doc@...r.kernel.org, corbet@....net,
        Michael Chan <michael.chan@...adcom.com>,
        Andrew Gospodarek <andrew.gospodarek@...adcom.com>
Subject: Re: [PATCH net-next v2 1/3] devlink: introduce framework for selftests

Hi Jiri,

On Tue, Jul 12, 2022 at 11:38 PM Jiri Pirko <jiri@...nulli.us> wrote:
>
> Tue, Jul 12, 2022 at 06:41:49PM CEST, vikas.gupta@...adcom.com wrote:
> >Hi Jiri,
> >
> >On Tue, Jul 12, 2022 at 11:58 AM Jiri Pirko <jiri@...dia.com> wrote:
> >>
> >> Tue, Jul 12, 2022 at 08:16:11AM CEST, vikas.gupta@...adcom.com wrote:
> >> >Hi Jiri,
> >> >
> >> >On Mon, Jul 11, 2022 at 6:10 PM Jiri Pirko <jiri@...dia.com> wrote:
> >> >
> >> >> Thu, Jul 07, 2022 at 08:29:48PM CEST, vikas.gupta@...adcom.com wrote:
>
> [...]
>
>
> >> >> >  * enum devlink_trap_action - Packet trap action.
> >> >> >  * @DEVLINK_TRAP_ACTION_DROP: Packet is dropped by the device and a copy
> >> >> is not
> >> >> >@@ -576,6 +598,10 @@ enum devlink_attr {
> >> >> >       DEVLINK_ATTR_LINECARD_TYPE,             /* string */
> >> >> >       DEVLINK_ATTR_LINECARD_SUPPORTED_TYPES,  /* nested */
> >> >> >
> >> >> >+      DEVLINK_ATTR_SELFTESTS_MASK,            /* u32 */
> >> >>
> >> >> I don't see why this is u32 bitset. Just have one attr per test
> >> >> (NLA_FLAG) in a nested attr instead.
> >> >>
> >> >
> >> >As per your suggestion, for an example it should be like as below
> >> >
> >> >        DEVLINK_ATTR_SELFTESTS,                 /* nested */
> >> >
> >> >        DEVLINK_ATTR_SELFTESTS_SOMETEST1            /* flag */
> >> >
> >> >        DEVLINK_ATTR_SELFTESTS_SOMETEST2           /* flag */
> >>
> >> Yeah, but have the flags in separate enum, no need to pullute the
> >> devlink_attr enum by them.
> >>
> >>
> >> >
> >> >....    <SOME MORE TESTS>
> >> >
> >> >.....
> >> >
> >> >        DEVLINK_ATTR_SLEFTESTS_RESULT_VAL,      /* u8 */
> >> >
> >> >
> >> >
> >> > If we have this way then we need to have a mapping (probably a function)
> >> >for drivers to tell them what tests need to be executed based on the flags
> >> >that are set.
> >> > Does this look OK?
> >> >  The rationale behind choosing a mask is that we could directly pass the
> >> >mask-value to the drivers.
> >>
> >> If you have separate enum, you can use the attrs as bits internally in
> >> kernel. Add a helper that would help the driver to work with it.
> >> Pass a struct containing u32 (or u8) not to drivers. Once there are more
> >> tests than that, this structure can be easily extended and the helpers
> >> changed. This would make this scalable. No need for UAPI change or even
> >> internel driver api change.
> >
> >As per your suggestion, selftest attributes can be declared in separate
> >enum as below
> >
> >enum {
> >
> >        DEVLINK_SELFTEST_SOMETEST,         /* flag */
> >
> >        DEVLINK_SELFTEST_SOMETEST1,
> >
> >        DEVLINK_SELFTEST_SOMETEST2,
> >
> >....
> >
> >......
> >
> >        __DEVLINK_SELFTEST_MAX,
> >
> >        DEVLINK_SELFTEST_MAX = __DEVLINK_SELFTEST_MAX - 1
> >
> >};
> >Below  examples could be the flow of parameters/data from user to
> >kernel and vice-versa
> >
> >
> >Kernel to user for show command . Users can know what all tests are
> >supported by the driver. A return from kernel to user.
> >______
> >|NEST |
> >|_____ |TEST1|TEST4|TEST7|...
> >
> >
> >User to kernel to execute test: If user wants to execute test4, test8, test1...
> >______
> >|NEST |
> >|_____ |TEST4|TEST8|TEST1|...
> >
> >
> >Result Kernel to user execute test RES(u8)
> >______
> >|NEST |
> >|_____ |RES4|RES8|RES1|...
>
> Hmm, I think it is not good idea to rely on the order, a netlink library
> can perhaps reorder it? Not sure here.
>
> >
> >Results are populated in the same order as the user passed the TESTs
> >flags. Does the above result format from kernel to user look OK ?
> >Else we need to have below way to form a result format, a nest should
> >be made for <test_flag,
> >result> but since test flags are in different enum other than
> >devlink_attr and RES being part of devlink_attr, I believe it's not
> >good practice to make the below structure.
>
> Not a structure, no. Have it as another nest (could be the same attr as
> the parent nest:
>
> ______
> |NEST |
> |_____ |NEST|       |NEST|       |NEST|
>         TEST4,RES4   TEST8,RES8   TEST1, RES1
>
> also, it is flexible to add another attr if needed (like maybe result
> message string containing error message? IDK).

For above nesting we can have the attributes defined as below

Attribute in  devlink_attr
enum devlink_attr {
  ....
  ....
        DEVLINK_SELFTESTS_INFO, /* nested */
  ...
...
}

enum devlink_selftests {
        DEVLINK_SELFTESTS_SOMETEST0,   /* flag */
        DEVLINK_SELFTESTS_SOMETEST1,
        DEVLINK_SELFTESTS_SOMETEST2,
        ...
        ...
}

enum devlink_selftest_result {
        DEVLINK_SELFTESTS_RESULT,       /* nested */
        DEVLINK_SELFTESTS_TESTNUM,      /* u32  indicating the test
number in devlink_selftests enum */
        DEVLINK_SELFTESTS_RESULT_VAL,   /* u8  skip, pass, fail.. */
        ...some future attrr...

}
enums in devlink_selftest_result can be put in devlink_attr though.

Does this look OK?

Thanks,
Vikas

>
>
>
> >______
> >|NEST |
> >|_____ | TEST4, RES4|TEST8,RES8|TEST1,RES1|...
> >
> >Let me know if my understanding is correct.
>
> [...]

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4206 bytes)

Powered by blists - more mailing lists