[Openib-windows] RE: [PATCH] FW version in vstat

[Yossi Leybovich]

> -----Original Message-----
> From: Fab Tillier [mailto:ftillier at silverstorm.com] 
> Sent: Sunday, November 06, 2005 8:07 PM
> To: 'Yossi Leybovich'
> Cc: openib-windows at openib.org
> Subject: RE: [PATCH] FW version in vstat
> 
> 
> Hi Yossi,
> 
> > From: Yossi Leybovich [mailto:sleybo at mellanox.co.il]
> > Sent: Sunday, November 06, 2005 7:01 AM
> > 
> > we found it very useful to know the fw version on the HCA 
> this patch 
> > add fw version to the vstat report.
> 
> I think FW version is going to be a common field for any 
> implementation.  As such, I think it would be better to have 
> it as part of the ib_ca_attr_t structure.

I just followed the comment on the in ib_types.h
".....
*	size
*		Total size in bytes for the HCA attributes.  This size
includes total
*		size required for all the variable members of the structure.
If a
*		vendor requires to pass vendor specific fields beyond this
structure,
*		the HCA vendor can choose to report a larger size.  If a
vendor is
*		reporting extended vendor specific features, they should
also provide
*		appropriate access functions to aid with the required
interpretation.

..."
> 
> In the new verb API I started defining the FW version is a 
> 32-bit field in the CA attributes.  Can you do the same thing here?

We use 64 bits for FW version (its 3 digits of 16 bits ) [in the futur we
might want to add cmd_if version to this number]
So 32 bits its not enough for Mellanox .
So either we can change it to be 64bit or make it vendor specific

> 
> > to make it clean I want to create access function for Mellanox 
> > specific attributes in the query_ca , where do you think we 
> should put 
> > this functions ?
> 
> I don't quite follow you here.  You want to add private 
> vendor data to the CA attributes?  Why not just use the 
> ib_ci_call function to get this private data? I'm worried 
> about making the ib_query_ca call too complicated if we start 
> to add support for all sorts of "flexibility".  It just makes 
> it harder for the user to figure out how large a buffer to allocate.
> 

What complexity ? The user already need to query for the ca_attr size ? And
all I want to add is header file with functions that enable the user to get
Mellanox specific data. The common user don't have to use those function and
continue with his old code.
My question was where do you want this header to be place?

Of course that if we insert the FW version to the ca_attr struct we avoid
this problem (but we might bump it in the future in our next HCAs)

> Can you describe what changes you want to make in a little 
> more detail, along with the impact on users?
> 
 1. to add FW version to the end the ca_attr struct as Vendor specific data.
 2. add access function to retrieve that data
 3. change vstat to show FW version
	
Impact:

The size of ca_attr is bigger in 8 bytes so the user will need to allocate 8
more bytes.
The vstat will show the FW version and the user have simple way to know what
FW version he use.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20051107/d4f54c50/attachment.html>