On 12/4/2018 2:10 AM, Leon Romanovsky wrote: > On Mon, Dec 03, 2018 at 03:04:43PM -0700, Jason Gunthorpe wrote: >> On Mon, Dec 03, 2018 at 03:00:07PM -0600, Steve Wise wrote: >>> >>> On 12/3/2018 2:48 PM, Jason Gunthorpe wrote: >>>> On Sat, Dec 01, 2018 at 10:53:02AM +0800, liyangyang (M) wrote: >>>>> On 2018/11/30 23:56, Jason Gunthorpe wrote: >>>>>> On Fri, Nov 30, 2018 at 03:16:23PM +0800, liyangyang (M) wrote: >>>>>>> Hi Leon: >>>>>>> >>>>>>> Thanks a lot for your reply. >>>>>>> >>>>>>> On 2018/11/29 15:42, Leon Romanovsky wrote: >>>>>>>> On Thu, Nov 29, 2018 at 03:30:14PM +0800, liyangyang (M) wrote: >>>>>>>>> Hi Leon: >>>>>>>>> >>>>>>>>> Thanks a lot for your reply. >>>>>>>>> >>>>>>>>> On 2018/11/28 20:55, Leon Romanovsky wrote: >>>>>>>>>> On Wed, Nov 28, 2018 at 08:21:29PM +0800, Tao Tian wrote: >>>>>>>>>>> This patch adds support of resource track for hip08 and take >>>>>>>>>>> dumping cq context state used for debugging as an example. >>>>>>>>>>> More resources track supports for hns driver will be added in future. >>>>>>>>>>> >>>>>>>>>>> The output should be as follows. >>>>>>>>>>> $ ./rdma res show cq dev hnseth0 -d >>>>>>>>>>> dev hnseth5 cqe 5555 users 2 poll-ctx WORKQUEUE pid 0 comm [ib_core] state 2 ceq >>>>>>>>>>> n 0 cqn 0 hopnum 1 pi 0 ci 0 maxcnt 0 period 0 cqe 0 >>>>>>>>>> You have "cqe" twice, one from IB/core and another from your driver. >>>>>>>>>> It will blow mind to everyone who will see it. >>>>>>>>> "cqe" in my driver means "cqe_cnt", but I mistakenly abbreviated it as "cqe". >>>>>>>>> This name will be changed to "cnt" in patch v5. >>>>>>>>> >>>>>>>>> The output should be as follows. >>>>>>>>> $ ./rdma res show cq dev hnseth0 -d >>>>>>>>> dev hnseth5 cqe 1023 users 2 poll-ctx WORKQUEUE pid 0 comm [ib_core] state 2 ceq >>>>>>>>> n 0 cqn 0 hopnum 1 pi 0 ci 0 maxcnt 0 period 0 cnt 0 >>>>>>>> So what does it mean to see maxcnt? Why is it zero? >>>>>>> "maxcnt" is the number of cqe aggregations. If it is 0, it means that cqe is not >>>>>>> aggregated. This name has existed for a long time, and it really makes users >>>>>>> confused. Perhaps "coalesce_num" or "coalesce" is a more appropriate name. >>>>>> coalesce is certainyl better english what you described.. I would >>>>>> never guess maxcnt has anything to do with aggregation. >>>>>> >>>>>> Jason >>>>> Hi Jason: >>>>> >>>>> Thanks a lot for your reply. >>>>> >>>>> Inappropriate naming is not friendly to user, I will pay more attention to the >>>>> subsequent resources track in future. >>>> The other thing that comes to mind here is how does the user know if a >>>> string is a driver string or a core string? I don't like the idea that >>>> the two namespaces would be conflated.. >>>> >>>> Steve? Did you do anything to prevent this in cxgb? >>>> >>>> Jason >>>> >>> In what way could they be conflated? >>> >>> Does the user really care whether an given string is from the core or >>> driver_specific? >> They might if the driver is spitt out very generic names like 'cqn' >> and soemday we use that string in the core code... > Or in Steve's code, it is "size" for RQ. I don't think we need to change the driver code since the nldev attributes explicitly identify driver-specific attributes. But perhaps the rdma tool should require a prefix for driver-specific attributes? IE: when displaying them, rdma could prefix each string with "drv_" or "d_". And when taking new strings from the the user, rdma could require the prefix and then strip it off when placing them into nlattrs... Steve.
