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. > > > > 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. -Seb
