On Tue, Jun 26, 2018 at 07:01:32PM +0000, Vadim Pasternak wrote:
>
>
> > -----Original Message-----
> > From: Andrew Lunn [mailto:and...@lunn.ch]
> > Sent: Tuesday, June 26, 2018 9:18 PM
> > To: Vadim Pasternak <vad...@mellanox.com>
> > Cc: Guenter Roeck <li...@roeck-us.net>; linux...@vger.kernel.org;
> > netdev@vger.kernel.org; rui.zh...@intel.com; edubez...@gmail.com;
> > j...@resnulli.us
> > Subject: Re: [patch net-next RFC 03/12] mlxsw: core: Add core environment
> > module for port temperature reading
> >
> > > However, I have some concerns on this matter.
> > > Our hardware provides bulk reading of the modules temperature, means I
> > > can get all inputs by one hardware request, which is important
> > > optimization.
> > > Reading each module individually will be resulted in huge overhead and
> > > will require maybe some cashing of temperature inputs.
> >
> > Well, you can cache the SFP calibration values, and the 4 limit values. To
> > get an
> > actually temperature you need to read 2 bytes from the SFP module. I don't
> > see
> > why that would be expensive. You talk to the firmware over PCIe right? So
> > you
> > have lots of bandwidth.
>
> Yes, but FW in its turn will run I2C transaction to read temperature sensor.
So how does that add overhead? It needs to read the same two bytes
independent of if it is getting readings from one sensor, or all
sensors.
> And we also run hwmon and thermal parts of our driver on BMC (Based
> Management Controller) on system equipped with it.
> In such case host CPU performs networking stuff, while BMC system related
> stuff. And in such configuration BMC talks to FW over I2C.
So you have a 20MHz I2C bus between your BMC and the firmware. Lets
assume a relativity dumb protocol. 2 bytes for command to read an sfp
sensor, 3 bytes for a replay. 5 bytes, at 20Mbps allows you to read
500,000 sensors per second. And for environment monitoring, 64 sensors
one per second should be sufficient.
Andrew
