Jason Jiang - Solaris China Team wrote: > Hi Roamer and all, > > Here is my comments[resent from our internal aliases to sync with people > here :-) ] > After a long digging into this document, for me, it is a very decent > document. And I have a few questions according to this document( maybe > related, maybe not :-) , but I ask help from your expertise on this). > 1. Multiple Interrupts Support: When the device driver is capable of > MSI-X, *how about MSI?* The flexibilities of MSI-X, like larger maximum number interrupt vectors and per-vector maksing, are what Crossbow is interested in. Of course, MSI is also a nice feature if MSI-X is not implemented. New 10GbE NICs almost all support MSI-X. The interface of Crossbow doesn't reject MSI, but prefer MSI-X. > 2. For DRR and DRRG, is there any parameter to record this in your ring > structure? Good question! We think the simplest way is to register the default ring as the first one. For current hardware implementations, this way works. Some hardware allow to set default ring by software, but some others don't. We're considering a common interface that may handle both with enough simplicity. :) > 3. Is it possible that remove/add ring group functions were required? > Especially for TX ring group, if some error happenes on one ring (or > group), may I remove it dynamically? Yes. The new notification interface will address this. When a hardware fail happen with a ring, driver may call the new interface to report a status changes like link_up/down. > For group, I think mr_rem_ring is not enough. Is the mrg_stop used for > this purpose? All those optional interfaces are checked and called. Safely, the framework may call mrg_stop()-mr_rem_ring()-mrg_start() to finish the regrouping. But it's up to driver to decide to only provide mr_rem_ring() and handle all conflicts in the driver itself. Driver may not support regrouping feature if the hardware is not capable. > *4. *The administrator may choose to maximize the number of groups, in > order to increase the number of virtual NICs that can be built over this > NIC.** > If a NIC only has 1 rx ring and 1 tx ring, does it mean that only one > VNIC can be built over this NIC? Or I can simply increase the number of > groups to increase the number of VNICs but every VNIC share the only 1 > rx/tx ring? Yes, it's possible. But two things need to be balanced: * Throughput of single VNIC * Virtualization and independence Even if the hardware support, to have only one rx ring in a group can not drive to line speed for 10GbE. Also, it's hard to tell how many VNICs are needed by the system users. I think we're still looking for the balance point. > > 5. Does it need to add status bit into > mac_rx_ring_info_t/mac_rx_ring_group_info_t/mac_tx_ring_info_t structures? Probably not. In MAC layer, rings' statuses are recorded and updated accordingly if needed. While, we're trying to simplify the interface to driver. For example, to add a status to indicate whether it's default ring was proposed, but we didn't think it's necessary. > > 6. For this document is about hardware resources, but I can not see any > words about hardware checksum. Will you merge the rings capability into > m_getcapab or add another item into mac_callbacks_t? It should be part of this document but we didn't include it to keep the document focusing on resource virtualization. Eventually, hardware checksum could be covered by the ring capability, in fact rx hcksum and tx hcksum could be split to two parts. Anyway, need more investigation and discussions. > 7. For VNIC is introduced by Crossbow. Is it possible that we can use a > uniform name for all the NICs drivers when doing the configuration(, > such as ifconfig vnic0 plumb up)? Maybe it is related to Brussel. :-) There has been addressed by Vanity Naming in ClearView project, and you may find out more information from http://www.opensolaris.org/os/project/clearview/uv/
Thanks, Roamer > > Thanks, > Jason > Yunsong (Roamer) Lu ??: >> Hi, >> We've posted a new design document, Crossbow Hardware Resources >> Management and Virtualization, here: >> http://dlc.sun.com/osol/netvirt/downloads/docs/virtual_resources.pdf >> you're welcome to review and comment. >> >> In this document, we introduce the new driver interfaces of virtualizing >> NIC resources, like multiple rings and multiple MAC addresses, and we >> talk about the ideas about organizing various hardware implementations >> into the new framework. We're glad to know any comments from IHVs who >> are designing new NICs. >> >> What's not included in the document? The new design evolves GLDv3 >> interfaces, but before finalizing those changed interfaces, like >> (*mc_tx)(), (*mc_unicast)(), (*mc_resoureces)(), mac_rx(), etc., we >> would like to listen to your opinions first. Also, support for PCI-SIG >> IOV will be added afterwards. >> >> Please feel free to comment and share your opinions! >> >> Thanks, >> >> Kais & Roamer >> >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > crossbow-discuss mailing list > crossbow-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
