On Mon, 28 Sep 2009, Sebastien Roy wrote:
>
> On Mon, 2009-09-28 at 12:38 -0700, venugopal iyer wrote:
>> Thanks, Seb.
>>
>> On Mon, 28 Sep 2009, Sebastien Roy wrote:
>>
>>> On Fri, 2009-09-18 at 12:29 -0700, Kais Belgaied wrote:
>>>> Background
>>>> ==========
>>>>
>>>> Project Crossbow (PSARC/2006/357) enables creating hardware-based MAC
>>>> clients (some of these MAC clients are data links such as VNICs) both on
>>>> the RX and TX side. We define hardware-based MAC clients as having
>>>> dedicated
>>>> hardware resources; a RX hardware-based MAC client will have one or more RX
>>>> ring for exclusive use while a TX hardware-based MAC client will have one
>>>> or
>>>> more TX ring for exclusive use. MAC clients that are not hardware-based
>>>> (RX or TX) share hardware resources with other MAC clients, such MAC
>>>> clients will not have any TX or RX rings exclusively reserved for them.
>>>> MAC clients may be hardware-based on RX, but not on TX (and vice-versa).
>>>
>>> To me, that last sentence is essentially saying, "MAC clients may not be
>>> hardware-based on both RX and TX". Is that what you meant?
>>
>> No. It was just to note that it *need* not be h/w on both. How about
>> "MAC clients could be hardware based on either TX, RX, both or neither"
>> or some such.
>
> Yes, that would be more clear.
>
>>>> If the property is not specified for a link, the system will attempt
>>>> to maxmize the hardware resource utilization by making this MAC client
>>>> hardware-based depending on rings availability.
>>>
>>> This is slightly ambiguous to me. Does that mean that if I neglect to
>>> override the default, that the first MAC client gets all of the hardware
>>> resources while subsequent clients get none?
>>
>>
>> That's not the case. Today, when we create a VNIC and don't specify the
>> -H option we try to give it one ring (assuming we have free rings).
>> That won't change, if we don't specify rxringcnt then we will try to
>> give the new MAC client 1 ring and make it hardware based. We do
>> this till there are free rings available. When there aren't any
>> free rings, MAC clients that don't specify this property will be
>> software based.
>
> Okay, that's fine. Please clarify that in the spec because your use of
> the word "maximize" could imply differently.
>
>>> I would think that unless
>> i otherwise specified, a sensible default behavior would result in evenly
>>> distributing resources among clients.
>>>
>>>> dladm show-phys will be modified to display the ring information on TX and
>>>> RX.
>>>>
>>>> e.g:
>>>> # dladm show-phys -H nxge0
>>>> LINK RINGTYPE RINGS CLIENTS
>>>> nxge0 RX 0 <mcast>
>>>> nxge0 TX 0,5 vnic1
>>>> nxge0 RX 1-3 vnic1
>>>>
>>>> which means vnic1 has exclusive use of 3 RX rings and 5 TX rings.
>>>
>>> I would interpret the above as "vnic1 has transmit rings 0 and
>>> 5" (because of the comma), and "vnic1 has receive rings 1, 2, and
>>> 3" (because of the hyphen). Am I reading that right?
>>
>> yes.
>
> So it does not have access to 5 TX rings as you state, but rather 2.
Yes, sorry, you are right I should have said 2 TX rings, not 5.
>
>>>
>>> How do I view the total number of hardware resources available on nxge0?
>>
>> the read-only rings property (rxringavailcnt, txringavailcnt) we are
>> introducing is for that purpose.
>>
>> let me know if I missed answering any of your questions.
>
> Got it, thanks.
>
> +1 from me.
thanks, I'll send a revised text addressing the above.
-venu
>
> -Seb
>
>
>
