On Nov 15, 2007, at 11:00 PM, Peter Memishian wrote: > > [ Old thread, but I've been meaning to ask. ] > >> I'm looking at 6579770 (VNICs over wpi: corrupted inbound, nothing >> out). There are really two parts to the problem: >> >> * The VNIC driver presents a 'pure' DL_ETHER device upward, >> regardless >> of the downstream device (which in this case is <DL_ETHER, >> DL_WIFI>). >> * Most wireless NICs will only transmit packets with their assigned >> MAC address as a source address when in "client" mode. >> >> The first of these could be fixed in two ways: >> >> * Have the VNIC driver continue to present a pure DL_ETHER device >> upwards and manage the header cooking as necessary, >> * Have the VNIC driver properly reflect the type of the underlying >> device and have all VNIC mac clients deal with cooking as required. >> >> Implementing the first of these two options was straightforward, so >> that's what I did. > > It may be straightforward, but it seems like it would eventually > lead to > problems. For instance, how would a technology like Infiniband be > supported? Are we also going to make it look like DL_ETHER?
We cannot make the assumption that the VNIC will always only expose DL_ETHER MACs regardless of the type of the underlying device. Today VNICs support only DL_ETHER at the bottom, and expose DL_ETHER MACs on top. Some MAC types might have different requirements for virtualization, or might not even support virtualization. WIFI is an interesting example in that we can chose to expose a pure DL_ETHER or a DL_WIFI/DL_ETHER MAC. However we cannot assume that this will be always possible for all device types. > How much > work would be involved in option (2)? Also, how large is the set > of "all > VNIC mac clients" that would need to "cook as required"? I think David meant the same cooking which is already done by the MAC clients on top of a DL_WIFI MAC. If the VNIC on top of such a device exposes the same type of MAC, then the clients of that VNIC would have to perform the same operations as they do today when using the device directly. Nicolas. -- Nicolas Droux - Solaris Core OS - Sun Microsystems, Inc. droux at sun.com - http://blogs.sun.com/droux
