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? How much >
and, if I may generalize the question here: the vnic driver may need in the future to be made aware of the different MAC types. It'll address the sharing depending on the type. For example, it may involve demultiplex'ing and sharing based on higher level headers for mediums that can't support more than a single address, or for point-to-point kind of links. > 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 don't know how large the whole set is, but they come in two families 1. DLS and anything above it, such as plumbed interfaces. 2. back-end drivers interfacing virtual machines (Xen, LDOMs, ...) Kais.
