On 22/09/09 12:46 PM, venugopal iyer wrote:
>
>
>
>
> On Tue, 22 Sep 2009, Darren Reed wrote:
>
>> venugopal iyer wrote:
>>>
>>> Thanks, Darren.
>>>
>>> On Mon, 21 Sep 2009, Darren Reed wrote:
>>>
>>>> On 18/09/09 12:29 PM, Kais Belgaied wrote:
>>>>> ...
>>>>>
>>>>> +      rxringavailcnt
>>>>>
>>>>> +          A read-only property that specifies the number of rings 
>>>>> available
>>>>> +        on the receive side.
>>>>>
>>>>> +      rxringcnt
>>>>>
>>>>> +          Specifies the number of receive rings side for the MAC 
>>>>> client.
>>>>> +        A value of 0 means this MAC client should not be assigned 
>>>>> any RX
>>>>> +        ring.  A non-0 value means reserve that many rings for 
>>>>> this MAC
>>>>> +        client, if available, and fail if not. If this property 
>>>>> is not
>>>>> +        specified the MAC client may get one RX ring, if 
>>>>> available, or
>>>>> +        will be software based.
>>>>> +
>>>>> +      rxhwavailclnt
>>>>> +
>>>>> +          A read-only property that specifies the number of 
>>>>> additional
>>>>> +        RX hardware-based MAC clients that can be created.
>>>>> +
>>>>> +      txringavailcnt
>>>>> +
>>>>> +          A read-only property that specifies the number of rings 
>>>>> available
>>>>> +        on the transmit side.
>>>>> +
>>>>> +      txringcnt
>>>>> +
>>>>> +          Specifies the number of transmit rings for the MAC client.
>>>>> +        A value of 0 means this MAC client should not be assigned 
>>>>> need any
>>>>> +        TX ring. A non-0 value means reserve that many rings for 
>>>>> this MAC
>>>>> +        client, if available, and fail if not. If this property 
>>>>> is not
>>>>> +        specified the MAC client may get one TX ring, if 
>>>>> available, or
>>>>> +        will be software based.
>>>>> +
>>>>> +      txhwavailclnt
>>>>> +
>>>>> +          A read-only property that specifics the number of 
>>>>> additional
>>>>> +        TX hardware-based MAC clients that can be created.
>>>>> +
>>>>> +
>>>>>
>>>>
>>>> The only comment I have is the naming, specifically the "cnt" and 
>>>> "clnt" on the end, seems ... I don't know... awkward/cumbersome?
>>>>
>>>> For example, "rxringavailclnt" and "rxringcnt" both are associated 
>>>> with mac client but only one mentions "clnt" in its name.
>>>
>>> I think you mean rxhwavailclnt and rxringcnt, right?
>>> If so, then rxhwavailclnt is the number of clients that can be 
>>> created and we
>>> wanted to have the client in the name, I can add cnt to 
>>> rxhwavailclnt if that
>>> makes it any better.
>>>
>>>>
>>>> Additionally, they are all a "count" of something, so "cnt" should 
>>>> be present on all, right?
>>>
>>> yes, they are counts. As mentioned above if rxhwavailclntcnt and
>>> txhwavailclntcnt makes it better, I am fine with it.
>>
>> And that is the point, these names look awful :-(
>>
>> For example, if you look through any of statistics in kstat, you 
>> generally don't see "cnt" or "count".
>>
>>
>>>> I'd like to suggest thinking of simpler names that do not include 
>>>> redundant information such as "clnt" and "cnt."
>>>>
>>>> For example, if "rxringcnt" became "rxrings", is any meaning really 
>>>> lost?
>>>
>>> We started off with rxrings, but wanted to make it explicit that it is
>>> the number or rx rings and not, say, as ring index.
>>
>> If it was just "rxring", then perhaps I would agree that maybe it 
>> might be something else...
>>
>> But, for example, we have "Inbound Packets", not "Inbound Packet 
>> Count" in "netstat -i" output.
>>
>> To me, the label "rxrings" does not imply it could be about anything 
>> else but rx rings. If it were to be about an index, then it would be 
>> "rxringindex" or "rxringindexes" - the name becomes more specific.
>
> So, do you prefer:
>
>     rxrings/txrings

much better.

>     rxringsavail/txringsavail

much better

>     rxhwavailclnt/txhwavailclnt

Is "clnt" required here?

Darren

Reply via email to