RE: Implement Ethernet Interface Properties

["Spencer Ku (古世瑜)" <Spencer.Ku@quantatw.com>]

Hi Ed, thank you for the feedback!

> -----Original Message-----
> From: openbmc
> <openbmc-bounces+spencer.ku=quantatw.com@lists.ozlabs.org> On Behalf Of
> Ed Tanous
> Sent: Tuesday, January 25, 2022 4:38 AM
> 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; Nan Zhou <nanzhou@google.com>
> Subject: Re: Implement Ethernet Interface Properties
> 
> 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.
> 

Understand, after looking for the DiagnosticData resource model, I think the model is actually more suitable field for the Ethernet statistic.
I will continue discuss with them and see if the Ethernet statistic can be the standard under the DiagnosticData or EthernetInterface model without OEM.

> > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fredf
> > ishforum.com%2Fthread%2F579%2Fadditional-information-ethernet-interfac
> >
> e&amp;data=04%7C01%7CSpencer.Ku%40quantatw.com%7Ce1af9d9b5520475
> f00180
> >
> 8d9df797c1f%7C179b032707fc4973ac738de7313561b2%7C1%7C0%7C637786
> 5351607
> >
> 38828%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJB
> >
> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HP1lhG%2FtnuKvgskOes
> dwDrpJ
> > 7S56XmXAXJrFUwV%2F6%2BY%3D&amp;reserved=0
> >
> > 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://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgerr
> >
> it.openbmc-project.xyz%2Fc%2Fopenbmc%2Fbmcweb%2F%2B%2F50522&amp;
> data=0
> >
> 4%7C01%7CSpencer.Ku%40quantatw.com%7Ce1af9d9b5520475f001808d9df79
> 7c1f%
> >
> 7C179b032707fc4973ac738de7313561b2%7C1%7C0%7C637786535160738828
> %7CUnkn
> >
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
> aWwi
> >
> LCJXVCI6Mn0%3D%7C3000&amp;sdata=KlMfvE50FOX3DPqDoHfQ952XSNEMs
> EDUpO2tdF
> > j8%2BZQ%3D&amp;reserved=0
> 
> 
> 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.
> 

I see, here I missed the odata ID and odata type properties which OEM properties must have.
If we can let the properties become standard, this problem can be above. 

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

Sincerely,
Spencer Ku