> > Pull pkey_tbl_len, gid_tbl_len and your new thing into a single struct > > and allocate an array of them. > > > > Actually, why not just allocate an array of ib_port_attrs and fill > > that? Then you can use it for the mad size too. > > That was debated before and I was hoping to leave that for another day. > > It does make some sense to roll it in here. I remember more details now... This came up in my original OPA patch series when Sean objected to me calling the port attributes "cached_port_attr". There are a number of values in the ib_port_attr structure which are not fixed (state, active_mtu, lid, sm_lid, etc...) Putting another copy of this data in the device will be confusing to know which of these one can count on for the correct data. I did not write the table length code so I am assuming that data is immutable. As is the max MAD size, and these new capability bits. But storing the entire ib_port_attr structure is probably going to mislead someone. Do we still think this is a good idea? I think putting in a single struct with the proper immutable data is the proper way to go. Ira -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
