On Dec 6, 2008, at 1:59 PM, Andrew Gallatin wrote: > Nicolas Droux wrote: >> On Dec 5, 2008, at 3:25 PM, Andrew Gallatin wrote: >>> Nicolas Droux wrote: >>> >>>> >>>> For the 3rd party device driver writers who have already >>>> experimented >>>> with GLDv3 and want to port their drivers, you can look at the >>>> drivers >>>> in ON (for example ixgbe) which have been already ported to the >>>> latest >>>> API. Diffs of the changes made to the drivers by the Crossbow >>>> project >>>> can be seen in the following webrev: >>>> >>>> http://cr.opensolaris.org/~ndroux/crossbow/webrev-103.2 >>> >>> Is there any way for a 3rd party to see the links behind the >>> numbered things? Eg, I'm interested in: >>> >>> 6761011 Code review Phase II. flow control comments >>> >>> But the link resolves to what seems to be an internal >>> Sun server: (http://monaco.sfbay.sun.com/detail.jsp?cr=6761011) >> These were bugs used for tracking purpose during the life of the >> project. Not very interesting at this points since they have been >> all either resolved and closed, or moved to other categories of >> solaris (for example kernel/gld) They were visible through >> opensolaris.org at some point, but they are no longer accessible >> for some reason. I don't think it's worth fixing at this point. >> If you're interested to see the code review comments, see: >> http://www.opensolaris.org/jive/thread.jspa?threadID=83402&tstart=0 > > I was mainly interested in the ixgbe comments linked above, which > mentioned some discussion about either enabling or disabling > flow control. We enable flow control by default (but provide > a mechanism by which a hung or unresponsive host will not > lock down the network indefinately), and I was wondering if the > flow control discussion would be relevant to our NIC.
Here are the basics of flow control between the stack and the driver: the driver notifies the stack that it can no longer send packets by returning the unsent packets from its transmit entry points. The driver is then responsible to notify the framework that it can again send more packets by invoking the framework mac_tx_update() or mac_tx_ring_update() entry points. mac_tx_update() is called by drivers which don't support multiple rings, and mac_tx_ring_update() is called by drivers which implement the MAC_CAPAB_RINGS capability. Nicolas. > > > Thanks, > > Drew > -- Nicolas Droux - Solaris Kernel Networking - Sun Microsystems, Inc. [EMAIL PROTECTED] - http://blogs.sun.com/droux _______________________________________________ networking-discuss mailing list [email protected]
