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. The second problem seems more difficult to address. From reading around, removing the restriction requires an update to the firmware for the wireless NIC. This is not likely to be possible in all cases. So, what to do? The options are: 1. Disallow non-pure DL_ETHER underlying devices when creating VNICs. 2. Allow non-pure DL_ETHER underlying devices, knowing that many (most? all?) of them won''t actually produce a working VNIC. For the second case, a decision about whether to hide the fact that they are non-pure is required, but not so urgent. I''m inclined to go for option 1, particularly as that reduces the risk for the Xen project integration into Nevada. It''s always possible to come back later and revisit, obviously. Thoughts? dme.
On Fri, 2007-08-10 at 14:01 +0100, David Edmondson wrote:> 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. > > The second problem seems more difficult to address. From reading > around, removing the restriction requires an update to the firmware > for the wireless NIC. This is not likely to be possible in all cases. > > So, what to do? The options are: > > 1. Disallow non-pure DL_ETHER underlying devices when creating VNICs. > 2. Allow non-pure DL_ETHER underlying devices, knowing that many > (most? all?) of them won''t actually produce a working VNIC. > > For the second case, a decision about whether to hide the fact that > they are non-pure is required, but not so urgent. > > I''m inclined to go for option 1, particularly as that reduces the risk > for the Xen project integration into Nevada. It''s always possible to > come back later and revisit, obviously.I''m not sure why you have to restrict the devices to DL_ETHER only. I think you can allow DL_WIFI devices if-and-only-if the device is STA/client mode. - Garrett> > Thoughts? > > dme. > _______________________________________________ > crossbow-discuss mailing list > crossbow-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
On Fri, Aug 10, 2007 at 06:18:30AM -0700, Garrett D''Amore wrote:> I''m not sure why you have to restrict the devices to DL_ETHER only. > I think you can allow DL_WIFI devices if-and-only-if the device is > STA/client mode.I don''t understand what you said, perhaps because I don''t know what "STA/client" mode is :-/ When the device is in "client" mode (is that the same as "STA/client"?) it will only transmit packets with one source MAC address. In that mode we can''t use it for MAC address based VNICs (because we need to transmit packets with more than one source MAC address). Perhaps it''s possible to kick the device into something other than "client" mode, but I couldn''t see a way to do this with the Solaris drivers. dme.
On Fri, 2007-08-10 at 14:35 +0100, David Edmondson wrote:> On Fri, Aug 10, 2007 at 06:18:30AM -0700, Garrett D''Amore wrote: > > I''m not sure why you have to restrict the devices to DL_ETHER only. > > I think you can allow DL_WIFI devices if-and-only-if the device is > > STA/client mode. > > I don''t understand what you said, perhaps because I don''t know what > "STA/client" mode is :-/ > > When the device is in "client" mode (is that the same as > "STA/client"?) it will only transmit packets with one source MAC > address. In that mode we can''t use it for MAC address based VNICs > (because we need to transmit packets with more than one source MAC > address).STA == client mode. (STA == station mode, as opposed to AP mode.) Now I understand the problem. I''m surprised that you can''t cook up raw headers (maybe full 802.11 headers) to issue any mac address you want. Some chips have support for "multiple STA" support... intended to support being connected to multiple WLANs at the same time. I wonder if this could be used to create the necessary support. (Of course the Solaris drivers for these devices don''t generally have the necessary support.) In any case, VNICs are probably nearly exclusively of interest to wired LANs. (Although a system with a WLAN might want to have a virtual switch layer between zones that are running on it.) -- Garrett
On Fri, Aug 10, 2007 at 06:44:51AM -0700, Garrett D''Amore wrote:> STA == client mode. (STA == station mode, as opposed to AP mode.)Thanks.> I''m surprised that you can''t cook up raw headers (maybe full 802.11 > headers) to issue any mac address you want.Gee, thanks :-p> In any case, VNICs are probably nearly exclusively of interest to > wired LANs.The Solaris on Xen project by default uses VNICs to provide network access for guest domains. If VNICs aren''t available on wireless NICs then guest domains on systems with only a wireless NIC won''t be able to get to the network. Of course, we need to hurry up the work to provide a NAT (L2 or L3) or routing based solution, but neither of those will happen in time for our initial putback.
On Fri, 2007-08-10 at 14:54 +0100, David Edmondson wrote:> On Fri, Aug 10, 2007 at 06:44:51AM -0700, Garrett D''Amore wrote: > > STA == client mode. (STA == station mode, as opposed to AP mode.) > > Thanks. > > > I''m surprised that you can''t cook up raw headers (maybe full 802.11 > > headers) to issue any mac address you want. > > Gee, thanks :-p > > > In any case, VNICs are probably nearly exclusively of interest to > > wired LANs. > > The Solaris on Xen project by default uses VNICs to provide network > access for guest domains. If VNICs aren''t available on wireless NICs > then guest domains on systems with only a wireless NIC won''t be able > to get to the network. > > Of course, we need to hurry up the work to provide a NAT (L2 or L3) or > routing based solution, but neither of those will happen in time for > our initial putback.I understood that someone was working on a "vswitch" project? Combined with VNICs and routing in the Dom0, it should work. -- Garrett> _______________________________________________ > crossbow-discuss mailing list > crossbow-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
David Edmondson wrote:> 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. > > The second problem seems more difficult to address. From reading > around, removing the restriction requires an update to the firmware > for the wireless NIC. This is not likely to be possible in all cases. > > So, what to do? The options are: > > 1. Disallow non-pure DL_ETHER underlying devices when creating VNICs. > 2. Allow non-pure DL_ETHER underlying devices, knowing that many > (most? all?) of them won''t actually produce a working VNIC. > > For the second case, a decision about whether to hide the fact that > they are non-pure is required, but not so urgent. > > I''m inclined to go for option 1, particularly as that reduces the risk > for the Xen project integration into Nevada. It''s always possible to > come back later and revisit, obviously.I agree, I would suggest going with option 1. I don''t think we should allow combinations which could fail randomly depending on the hardware used. If we could express that wireless NIC limitation through a capability exported by the wireless driver, then we could have the VNIC driver and the MAC layer check for that limitation and "gracefully fail" the VNIC creation operation if the wireless NIC underneath doesn''t support that capability. I think we should be able to provide information about that capability through dladm show-* as well. Something else to consider is that in the future we are planning to allow multiple VNICs to share a single MAC address. It seems that this could be used to properly support the wireless NICs with these limitation. This feature could kick in automatically for NICs which don''t support sending packets with multiple source MAC addresses, in this case either for all DL_WIFI or for the DL_WIFI drivers with that limitation. Nicolas.> > Thoughts? > > dme. > _______________________________________________ > xen-discuss mailing list > xen-discuss@opensolaris.org-- Nicolas Droux - Solaris Networking - Sun Microsystems, Inc. droux@sun.com - http://blogs.sun.com/droux
On Fri, Aug 10, 2007 at 10:27:16AM -0700, Garrett D''Amore wrote:> I understood that someone was working on a "vswitch" project? Combined > with VNICs and routing in the Dom0, it should work.Of course, but not yet. dme.
On Fri, Aug 10, 2007 at 11:39:31AM -0600, Nicolas Droux wrote:> If we could express that wireless NIC limitation through a > capability exported by the wireless driver, then we could have the > VNIC driver and the MAC layer check for that limitation and > "gracefully fail" the VNIC creation operation if the wireless NIC > underneath doesn''t support that capability. I think we should be > able to provide information about that capability through dladm > show-* as well.I''ll enquire of the WiFi driver folks.> Something else to consider is that in the future we are planning to > allow multiple VNICs to share a single MAC address.How will packets be de-multiplexed (a simple IP address based mechanism might not be sufficient)? dme.
On Aug 13, 2007, at 12:02 AM, David Edmondson wrote:>> Something else to consider is that in the future we are planning to >> allow multiple VNICs to share a single MAC address. > > How will packets be de-multiplexed (a simple IP address based > mechanism might not be sufficient)?This still has to be designed properly, but for DHCP we''ll most likely use client IDs to demultiplex the DHCP replies. For IP traffic of course the unicast IP address(es) associated with the VNICs will be used. Other type of traffic might require special processing (e.g. ARP). Nicolas. -- Nicolas Droux - Solaris Core OS - Sun Microsystems, Inc. droux@sun.com - http://blogs.sun.com/droux
On Tue, 2007-08-14 at 23:26 -0600, Nicolas Droux wrote:> On Aug 13, 2007, at 12:02 AM, David Edmondson wrote: > > >> Something else to consider is that in the future we are planning to > >> allow multiple VNICs to share a single MAC address. > > > > How will packets be de-multiplexed (a simple IP address based > > mechanism might not be sufficient)? > > This still has to be designed properly, but for DHCP we''ll most > likely use client IDs to demultiplex the DHCP replies. For IP traffic > of course the unicast IP address(es) associated with the VNICs will > be used. Other type of traffic might require special processing (e.g. > ARP). > > Nicolas. >Btw, a bunch of the 10/100 legacy NICs can support multiple MAC addresses fairly trivially. Should updating this be something I should be looking at? If there was a simple test suite to validate this feature, it would certainly help in getting the feature added. -- Garrett
Garrett D''Amore wrote:> On Tue, 2007-08-14 at 23:26 -0600, Nicolas Droux wrote: > >> On Aug 13, 2007, at 12:02 AM, David Edmondson wrote: >> >> >>>> Something else to consider is that in the future we are planning to >>>> allow multiple VNICs to share a single MAC address. >>>> >>> How will packets be de-multiplexed (a simple IP address based >>> mechanism might not be sufficient)? >>> >> This still has to be designed properly, but for DHCP we''ll most >> likely use client IDs to demultiplex the DHCP replies. For IP traffic >> of course the unicast IP address(es) associated with the VNICs will >> be used. Other type of traffic might require special processing (e.g. >> ARP). >> >> Nicolas. >> >> > > Btw, a bunch of the 10/100 legacy NICs can support multiple MAC > addresses fairly trivially. Should updating this be something I should > be looking at? If there was a simple test suite to validate this > feature, it would certainly help in getting the feature added. >There is no test suite :-(. But it can be tested easily by creating VNICs and generating some traffic. -krgopi> > -- Garrett > > _______________________________________________ > crossbow-discuss mailing list > crossbow-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss >
On Wed, 2007-08-15 at 13:24 -0700, Rajagopal Kunhappan wrote:> > Garrett D''Amore wrote: > > On Tue, 2007-08-14 at 23:26 -0600, Nicolas Droux wrote: > > > >> On Aug 13, 2007, at 12:02 AM, David Edmondson wrote: > >> > >> > >>>> Something else to consider is that in the future we are planning to > >>>> allow multiple VNICs to share a single MAC address. > >>>> > >>> How will packets be de-multiplexed (a simple IP address based > >>> mechanism might not be sufficient)? > >>> > >> This still has to be designed properly, but for DHCP we''ll most > >> likely use client IDs to demultiplex the DHCP replies. For IP traffic > >> of course the unicast IP address(es) associated with the VNICs will > >> be used. Other type of traffic might require special processing (e.g. > >> ARP). > >> > >> Nicolas. > >> > >> > > > > Btw, a bunch of the 10/100 legacy NICs can support multiple MAC > > addresses fairly trivially. Should updating this be something I should > > be looking at? If there was a simple test suite to validate this > > feature, it would certainly help in getting the feature added. > > > > There is no test suite :-(. But it can be tested easily by creating > VNICs and generating some traffic.So I need to use the crossbow gate to test? That makes it hard for me to integrate into Nevada before then. Although I guess I could give you patches for the drivers in the crossbow gate... it just seems like that leads to more headaches for sustaining as other patches get integrated (merge headaches). -- Garrett> > -krgopi > > > > > -- Garrett > > > > _______________________________________________ > > crossbow-discuss mailing list > > crossbow-discuss@opensolaris.org > > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss > > > _______________________________________________ > crossbow-discuss mailing list > crossbow-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
Garrett D''Amore wrote:> On Wed, 2007-08-15 at 13:24 -0700, Rajagopal Kunhappan wrote: > >> Garrett D''Amore wrote: >> >>> On Tue, 2007-08-14 at 23:26 -0600, Nicolas Droux wrote: >>> >>> >>>> On Aug 13, 2007, at 12:02 AM, David Edmondson wrote: >>>> >>>> >>>> >>>>>> Something else to consider is that in the future we are planning to >>>>>> allow multiple VNICs to share a single MAC address. >>>>>> >>>>>> >>>>> How will packets be de-multiplexed (a simple IP address based >>>>> mechanism might not be sufficient)? >>>>> >>>>> >>>> This still has to be designed properly, but for DHCP we''ll most >>>> likely use client IDs to demultiplex the DHCP replies. For IP traffic >>>> of course the unicast IP address(es) associated with the VNICs will >>>> be used. Other type of traffic might require special processing (e.g. >>>> ARP). >>>> >>>> Nicolas. >>>> >>>> >>>> >>> Btw, a bunch of the 10/100 legacy NICs can support multiple MAC >>> addresses fairly trivially. Should updating this be something I should >>> be looking at? If there was a simple test suite to validate this >>> feature, it would certainly help in getting the feature added. >>> >>> >> There is no test suite :-(. But it can be tested easily by creating >> VNICs and generating some traffic. >> > > > So I need to use the crossbow gate to test? That makes it hard for me > to integrate into Nevada before then. >That is a problem. When I integrated multiple MAC address support to S10, I got help from LDOM folks to test out the multiple MAC address support. Since they were the ones asking for this support, they were more than willing to help out at that time. -krgopi> Although I guess I could give you patches for the drivers in the > crossbow gate... it just seems like that leads to more headaches for > sustaining as other patches get integrated (merge headaches). > > -- Garrett > >> -krgopi >> >> >>> -- Garrett >>> >>> _______________________________________________ >>> crossbow-discuss mailing list >>> crossbow-discuss@opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss >>> >>> >> _______________________________________________ >> crossbow-discuss mailing list >> crossbow-discuss@opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss >> > >
On Wed, 2007-08-15 at 13:24 -0700, Rajagopal Kunhappan wrote:> > Garrett D''Amore wrote: > > On Tue, 2007-08-14 at 23:26 -0600, Nicolas Droux wrote: > > > >> On Aug 13, 2007, at 12:02 AM, David Edmondson wrote: > >> > >> > >>>> Something else to consider is that in the future we are planning to > >>>> allow multiple VNICs to share a single MAC address. > >>>> > >>> How will packets be de-multiplexed (a simple IP address based > >>> mechanism might not be sufficient)? > >>> > >> This still has to be designed properly, but for DHCP we''ll most > >> likely use client IDs to demultiplex the DHCP replies. For IP traffic > >> of course the unicast IP address(es) associated with the VNICs will > >> be used. Other type of traffic might require special processing (e.g. > >> ARP). > >> > >> Nicolas. > >> > >> > > > > Btw, a bunch of the 10/100 legacy NICs can support multiple MAC > > addresses fairly trivially. Should updating this be something I should > > be looking at? If there was a simple test suite to validate this > > feature, it would certainly help in getting the feature added. > > > > There is no test suite :-(. But it can be tested easily by creating > VNICs and generating some traffic.So you mentioned that the LDOMs folks wanted it on S10. Does that mean that there is some other consumer of this feature *today*? Btw, this will need to be included in an expanded version of the NICDRV test suite, once there is some not-to-difficult mechanism for it to configure this feature. -- Garrett> > -krgopi > > > > > -- Garrett > > > > _______________________________________________ > > crossbow-discuss mailing list > > crossbow-discuss@opensolaris.org > > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss > >
Garrett D''Amore wrote:> On Wed, 2007-08-15 at 13:24 -0700, Rajagopal Kunhappan wrote: > >> Garrett D''Amore wrote: >> >>> On Tue, 2007-08-14 at 23:26 -0600, Nicolas Droux wrote: >>> >>> >>>> On Aug 13, 2007, at 12:02 AM, David Edmondson wrote: >>>> >>>> >>>> >>>>>> Something else to consider is that in the future we are planning to >>>>>> allow multiple VNICs to share a single MAC address. >>>>>> >>>>>> >>>>> How will packets be de-multiplexed (a simple IP address based >>>>> mechanism might not be sufficient)? >>>>> >>>>> >>>> This still has to be designed properly, but for DHCP we''ll most >>>> likely use client IDs to demultiplex the DHCP replies. For IP traffic >>>> of course the unicast IP address(es) associated with the VNICs will >>>> be used. Other type of traffic might require special processing (e.g. >>>> ARP). >>>> >>>> Nicolas. >>>> >>>> >>>> >>> Btw, a bunch of the 10/100 legacy NICs can support multiple MAC >>> addresses fairly trivially. Should updating this be something I should >>> be looking at? If there was a simple test suite to validate this >>> feature, it would certainly help in getting the feature added. >>> >>> >> There is no test suite :-(. But it can be tested easily by creating >> VNICs and generating some traffic. >> > > So you mentioned that the LDOMs folks wanted it on S10. Does that mean > that there is some other consumer of this feature *today*? >Yes, LDOM vswitch uses it. We integrated this into S10 in Jan this year. Is that still S10U4?> Btw, this will need to be included in an expanded version of the NICDRV > test suite, once there is some not-to-difficult mechanism for it to > configure this feature. >Yes, this should be done. -krgopi> -- Garrett > > >> -krgopi >> >> >>> -- Garrett >>> >>> _______________________________________________ >>> crossbow-discuss mailing list >>> crossbow-discuss@opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss >>> >>> > > _______________________________________________ > crossbow-discuss mailing list > crossbow-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss >
Rajagopal Kunhappan wrote:> > Garrett D''Amore wrote: >> On Wed, 2007-08-15 at 13:24 -0700, Rajagopal Kunhappan wrote: >> >>> Garrett D''Amore wrote: >>> >>>> On Tue, 2007-08-14 at 23:26 -0600, Nicolas Droux wrote: >>>> >>>>> On Aug 13, 2007, at 12:02 AM, David Edmondson wrote: >>>>> >>>>>>> Something else to consider is that in the future we are planning to >>>>>>> allow multiple VNICs to share a single MAC address. >>>>>>> >>>>>>> >>>>>> How will packets be de-multiplexed (a simple IP address based >>>>>> mechanism might not be sufficient)? >>>>>> >>>>> This still has to be designed properly, but for DHCP we''ll most >>>>> likely use client IDs to demultiplex the DHCP replies. For IP traffic >>>>> of course the unicast IP address(es) associated with the VNICs will >>>>> be used. Other type of traffic might require special processing (e.g. >>>>> ARP). >>>>> >>>> Btw, a bunch of the 10/100 legacy NICs can support multiple MAC >>>> addresses fairly trivially. Should updating this be something I should >>>> be looking at? If there was a simple test suite to validate this >>>> feature, it would certainly help in getting the feature added. >>>> >>> There is no test suite :-(. But it can be tested easily by creating >>> VNICs and generating some traffic. >>> >> So you mentioned that the LDOMs folks wanted it on S10. Does that mean >> that there is some other consumer of this feature *today*? >> > Yes, LDOM vswitch uses it. We integrated this into S10 in Jan this year. > Is that still S10U4? >Yes. The framework support went into s10u4_02 (snv_44) along with support for bge 6339368 Ability to set multiple MAC addresses to a network interface Support for e1000g went into s10u4_07 (snv_47) 6447914 e1000g should support setting of multiple unicast addresses -- Liam
[ 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 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"? -- meem
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@sun.com - http://blogs.sun.com/droux
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.
> 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. Agreed. > 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. Yep. Which is why I''m uncomfortable with the direction David is outlining. Even for WiFi, it''s preferable to use DL_WIFI so that tools making use of the VNIC can be as fully-featured as possible (e.g., I can see actual WiFi frames with Wireshark), and so that we we''re not wasting cycles swapping back and forth between frame formats. > > 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. Right, which should make this a non-issue since existing MAC clients can already handle native DL_WIFI links. So, in other words, I''m questioning the original design decision to translate DL_WIFI to DL_ETHER for VNICs -- while expedient, it doesn''t allow VNICs to be as flexible and extensible as we''d want. -- meem
On 16 Nov 2007, at 6:00am, Peter Memishian wrote:> [ Old thread, but I''ve been meaning to ask. ]I should declare that I didn''t implement either of the approaches suggested, as the difficulties in having Wifi links support multiple unicast addresses threw me a curve. When I have to go back to this I''d expect to have the VNIC code expose the true details of the underlying link.>> 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 > 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"?As others indicated, any code that directly opens mac devices (by calling mac_open()) is likely to need support for cook/uncook operations. Right now that''s a set something like dls, vsw, aggr, vnic and xnbo. The code is not complex, but knowing that it''s required is the first step :-) dme. -- David Edmondson, Solaris Engineering, http://dme.org
> When I have to go back to this I''d expect to have the VNIC code> expose the true details of the underlying link. OK, that sounds good. > As others indicated, any code that directly opens mac devices (by > calling mac_open()) is likely to need support for cook/uncook > operations. Right now that''s a set something like dls, vsw, aggr, > vnic and xnbo. The code is not complex, but knowing that it''s > required is the first step :-) I''m still a bit confused here. Any code that directly opens mac devices already has to prepare itself for opening a non-Ethernet mactype today, so what change is required? -- meem
On 20 Nov 2007, at 9:39pm, Peter Memishian wrote:>> As others indicated, any code that directly opens mac devices (by >> calling mac_open()) is likely to need support for cook/uncook >> operations. Right now that''s a set something like dls, vsw, aggr, >> vnic and xnbo. The code is not complex, but knowing that it''s >> required is the first step :-) > > I''m still a bit confused here. Any code that directly opens mac > devices > already has to prepare itself for opening a non-Ethernet mactype > today, > so what change is required?It was previously adequate to examine mi_media for DL_ETHER if only ethernet devices should be supported. Now there are devices which present mi_media as DL_ETHER, yet they don''t then supply ethernet frames (such devices have mi_nativemedia other than DL_ETHER). dme. -- David Edmondson, Solaris Engineering, http://dme.org
> > I''m still a bit confused here. Any code that directly opens mac> > devices > > already has to prepare itself for opening a non-Ethernet mactype > > today, > > so what change is required? > > It was previously adequate to examine mi_media for DL_ETHER if only > ethernet devices should be supported. Now there are devices which > present mi_media as DL_ETHER, yet they don''t then supply ethernet > frames (such devices have mi_nativemedia other than DL_ETHER). They should supply Ethernet frames unless the consumer issues a DLIOCNATIVE. -- meem
On 21 Nov 2007, at 6:36am, Peter Memishian wrote:>> It was previously adequate to examine mi_media for DL_ETHER if only >> ethernet devices should be supported. Now there are devices which >> present mi_media as DL_ETHER, yet they don''t then supply ethernet >> frames (such devices have mi_nativemedia other than DL_ETHER). > > They should supply Ethernet frames unless the consumer issues a > DLIOCNATIVE.Hmm. Well, that was very much not my experience when I encountered this at the time of the original posting (testing with an Intel 3945 wifi NIC). dme. -- David Edmondson, Solaris Engineering, http://dme.org
> > They should supply Ethernet frames unless the consumer issues a> > DLIOCNATIVE. > > Hmm. Well, that was very much not my experience when I encountered > this at the time of the original posting (testing with an Intel 3945 > wifi NIC). Ah, my mistake, I was thinking of the DLPI packet format. Yes, as a mac client, you''ll always see traffic matching the mi_nativemedia type. -- meem
On 21 Nov 2007, at 6:58am, David Edmondson wrote:> On 21 Nov 2007, at 6:36am, Peter Memishian wrote: >>> It was previously adequate to examine mi_media for DL_ETHER if only >>> ethernet devices should be supported. Now there are devices which >>> present mi_media as DL_ETHER, yet they don''t then supply ethernet >>> frames (such devices have mi_nativemedia other than DL_ETHER). >> >> They should supply Ethernet frames unless the consumer issues a >> DLIOCNATIVE. > > Hmm. Well, that was very much not my experience when I encountered > this at the time of the original posting (testing with an Intel > 3945 wifi NIC).DLIOCNATIVE only applies if we''re talking to the NIC via dld/dls, which is not the case here. Using the mac device directly (via mac_open()) results in uncooked frames. dme. -- David Edmondson, Solaris Engineering, http://dme.org