All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ed Tanous <ed@tanous.net>
To: "Spencer Ku (古世瑜)" <spencer.ku@quantatw.com>
Cc: "Litzung Chen (陳利琮)" <Litzung.Chen@quantatw.com>,
	"Ed Tanous" <edtanous@google.com>,
	"Fran Hsu (徐誌謙)" <Fran.Hsu@quantatw.com>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
	"Nan Zhou" <nanzhou@google.com>
Subject: Re: Implement Ethernet Interface Properties
Date: Mon, 24 Jan 2022 12:37:46 -0800	[thread overview]
Message-ID: <CACWQX81Er6MEfb+AOGS1XGOw4dULZvSxRAJOGQu+YhBW-jTwfA@mail.gmail.com> (raw)
In-Reply-To: <HK0PR04MB3299DA39BBF0596CA83BC41EE45A9@HK0PR04MB3299.apcprd04.prod.outlook.com>

On Thu, Jan 20, 2022 at 12:44 AM Spencer Ku (古世瑜)
<Spencer.Ku@quantatw.com> wrote:
>
> Hi All,
>
> We finally decide to implement six properties to Ethernet interface:
> RxPackets, TxPackets, RxBytes, TxBytes, RxDropped, and TxDropped.
>
> Those information come from Ethernet statistics and we can read the file
> to get the property value directly. (under /sys/class/net/<Ethernet name>/statistics)
>
> For the suitable property in EthernetInterface model, we got the feedback
> form Redfish forum and they said OEM properties would be the only other
> option at this time. For more discussion detail:

From their reply
"We may need to open discussions further for how to model these sorts
of metrics purely under EthernetInterface"

I think you've misinterpreted the response.  They asked for further
discussion on how to model it, and that OEM would be the alternative
if you weren't able to discuss.  Given our rules around OEM schemas,
please continue the discussion with the Redfish forum around this
topic to determine the right way to model this in the standard without
OEM.  There is nothing unique about OpenBMC with regards to these
telemetries, so it should be generic.  This might be a good candidate
for the newly formed "DiagnosticData" resource model, which is
initially exposing basically this same telemetry, but for i2c lanes
instead of network lanes.

> https://redfishforum.com/thread/579/additional-information-ethernet-interface
>
> The following output is the result of my currently OEM implement:
> https://${bmc}/redfish/v1/Managers/bmc/EhernetInterfaces/eth0
> {
>   "@odata.id": "/redfish/v1/Managers/bmc/EthernetInterfaces/eth0",
>   ...
>   "Oem": {
>     "Statistics": [
>       {
>         "RxBytes": 48244026,
>         "RxDropped": 222856,
>         "RxPackets": 484315,
>         "TxBytes": 825845,
>         "TxDropped": 0,
>         "TxPackets": 5472
>       }
>     ]
>   },
>   "SpeedMbps": 100,
>   ...
> }
>
> But it cannot pass the Redfish validator, and here is the error messages:
> ERROR - This complex object RxBytes should be a dictionary or None, but it's of type ...
> ERROR - RxBytes: Could not finish check on this property ('int' object is not iterable)
>
> Is there anything I didn't notice? Or has there any spec or example that I can follow to implement?
>
> I had already push the implementation to gerrit and mark as WIP. Here is the link:
> https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/50522


You haven't modeled your schema properly in the above.  This is one of
the reasons we try to avoid OEM schemas, as they're difficult to get
right without help from the standards body.  Please continue to engage
with them to get this in a standard interface.

>
> We are willing to see any suggestions and alternatives as well. Thanks!
>
> Sincerely,
> Spencer Ku

  parent reply	other threads:[~2022-01-24 20:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-01  9:58 Implement Ethernet Interface Properties Spencer Ku (古世瑜)
2021-12-01 18:24 ` Ed Tanous
2021-12-02  8:45   ` Spencer Ku (古世瑜)
2022-01-20  8:42     ` Spencer Ku (古世瑜)
2022-01-20  9:07       ` i.kononenko
2022-01-24  2:22         ` Spencer Ku (古世瑜)
2022-01-24 20:37       ` Ed Tanous [this message]
2022-01-25  8:00         ` Spencer Ku (古世瑜)
2021-12-01 22:49 ` Patrick Williams
2021-12-02  9:22   ` Spencer Ku (古世瑜)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACWQX81Er6MEfb+AOGS1XGOw4dULZvSxRAJOGQu+YhBW-jTwfA@mail.gmail.com \
    --to=ed@tanous.net \
    --cc=Fran.Hsu@quantatw.com \
    --cc=Litzung.Chen@quantatw.com \
    --cc=edtanous@google.com \
    --cc=nanzhou@google.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=spencer.ku@quantatw.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.