crossbow discuss - Aug 2007 - Crossbow virtualization architecture

Folks,

I posted a first draft of the Crossbow virtualization architecture  
document. It can be found at:

http://opensolaris.org/os/project/crossbow/Docs/crossbow-virt.pdf

Enjoy!

Nicolas.

-- 
Nicolas Droux - Solaris Networking - Sun Microsystems, Inc.
droux at sun.com - http://blogs.sun.com/droux

> I posted a first draft of the Crossbow virtualization architecture  
 > document. It can be found at:
 > 
 > http://opensolaris.org/os/project/crossbow/Docs/crossbow-virt.pdf

Nicolas,

I plan to read this thoroughly shortly, but a couple of superficial things
caught my eye upon a quick glance-through:

   * I notice that Crossbow plans to extend show-dev.  Post-UV, show-dev
     still deals with device names, whereas the other show-<foo> commands
     deal with link names.  Accordingly, we''ve added a show-phys
     subcommand that describes "physical links" by their linkname, and
     obsoleted show-dev (see section 4.1.2 and section 4.1.3. of [1] for
     more details).  Would it be reasonable for this new functionality to
     be folded into show-phys?

   * Similarly, as we''ve discussed in the past, a number of the new
dladm
     "-d <dev>" options need to become "-l
<link>" post-UV.

   * In general, field names in dladm show-<foo> output should be a single
     word.  (Among other things, this sidesteps having to quote whitespace
     when using the -o <field> option that we''d like all the
show-<foo>
     commands to have.)   Accordingly, the "MAC ADDRESS" field needs
to be
     recast.

[1] http://opensolaris.org/os/project/clearview/uv-design.pdf

-- 
meem

Meem,

Thanks for the comments.

On Jul 31, 2007, at 11:09 PM, Peter Memishian wrote:
>    * I notice that Crossbow plans to extend show-dev.  Post-UV,  
> show-dev
>      still deals with device names, whereas the other show-<foo>  
> commands
>      deal with link names.  Accordingly, we''ve added a show-phys
>      subcommand that describes "physical links" by their
linkname, and
>      obsoleted show-dev (see section 4.1.2 and section 4.1.3. of  
> [1] for
>      more details).  Would it be reasonable for this new  
> functionality to
>      be folded into show-phys?
If the option is specific to devices I agree. If there''s a chance  
that this information might be applicable to other types of links,  
then we might want to expose them through show-link. For example, we  
might down the road expose expose MAC address slots and factory MAC  
address from aggregations. In this case, should we have an option  
that shows that information as part of show-phys and show-aggr, or  
should we show that information via show-link since it might apply to  
different types of links. It''s best if we can find an approach which  
is consistent with Clearview UV.
>
>    * Similarly, as we''ve discussed in the past, a number of the
new
> dladm
>      "-d <dev>" options need to become "-l
<link>" post-UV.
Agreed. We''ve kept the man page in sync with ONNV since that''s
what
we''re based on today. As soon as UV and Crossbow merge, then
we''ll
update the option names accordingly to be consistent across the board.
>    * In general, field names in dladm show-<foo> output should be a  
> single
>      word.  (Among other things, this sidesteps having to quote  
> whitespace
>      when using the -o <field> option that we''d like all the
show-
> <foo>
>      commands to have.)   Accordingly, the "MAC ADDRESS" field  
> needs to be
>      recast.
OK, I don''t see a problem with that.

Thanks,
Nicolas.

-- 
Nicolas Droux - Solaris Networking - Sun Microsystems, Inc.
droux at sun.com - http://blogs.sun.com/droux

hi
what is the timeline for ce support of dladm for link aggregation?
TIA



Nicolas Droux wrote:
>Meem,
>
>Thanks for the comments.
>
>On Jul 31, 2007, at 11:09 PM, Peter Memishian wrote:
>
>  
>
>>   * I notice that Crossbow plans to extend show-dev.  Post-UV,  
>>show-dev
>>     still deals with device names, whereas the other show-<foo>  
>>commands
>>     deal with link names.  Accordingly, we''ve added a
show-phys
>>     subcommand that describes "physical links" by their
linkname, and
>>     obsoleted show-dev (see section 4.1.2 and section 4.1.3. of  
>>[1] for
>>     more details).  Would it be reasonable for this new  
>>functionality to
>>     be folded into show-phys?
>>    
>>
>
>If the option is specific to devices I agree. If there''s a chance  
>that this information might be applicable to other types of links,  
>then we might want to expose them through show-link. For example, we  
>might down the road expose expose MAC address slots and factory MAC  
>address from aggregations. In this case, should we have an option  
>that shows that information as part of show-phys and show-aggr, or  
>should we show that information via show-link since it might apply to  
>different types of links. It''s best if we can find an approach
which
>is consistent with Clearview UV.
>
>  
>
>>   * Similarly, as we''ve discussed in the past, a number of the
new
>>dladm
>>     "-d <dev>" options need to become "-l
<link>" post-UV.
>>    
>>
>
>Agreed. We''ve kept the man page in sync with ONNV since
that''s what
>we''re based on today. As soon as UV and Crossbow merge, then
we''ll
>update the option names accordingly to be consistent across the board.
>
>  
>
>>   * In general, field names in dladm show-<foo> output should be
a
>>single
>>     word.  (Among other things, this sidesteps having to quote  
>>whitespace
>>     when using the -o <field> option that we''d like all
the show-
>><foo>
>>     commands to have.)   Accordingly, the "MAC ADDRESS" field
>>needs to be
>>     recast.
>>    
>>
>
>OK, I don''t see a problem with that.
>
>Thanks,
>Nicolas.
>
>  
>
-- 
Hung-Sheng Tsao, Ph.D. (LaoTsao)       Sr. System Engineer
US, State Local & Education East        Data Center Ambassador
400 Atrium Dr, 1ST FLOOR                P/F:1877 319 0460 (x67079)
Somerset, NJ 08873                      C: 973 495 0840
http://blogs.sun.com/hstsao/            E:Hung-Sheng.Tsao at sun.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or
distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy
all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/crossbow-discuss/attachments/20070801/31dcefcd/attachment.html>

> > * I notice that Crossbow plans to extend show-dev.  Post-UV, show-dev
 > >   still deals with device names, whereas the other show-<foo>
commands
 > >   deal with link names.  Accordingly, we''ve added a
show-phys
 > >   subcommand that describes "physical links" by their
linkname, and
 > >   obsoleted show-dev (see section 4.1.2 and section 4.1.3. of [1] for
 > >   more details).  Would it be reasonable for this new functionality
to
 > >   be folded into show-phys?
 > 
 > If the option is specific to devices I agree. If there''s a chance
 > that this information might be applicable to other types of links,  
 > then we might want to expose them through show-link. For example, we  
 > might down the road expose expose MAC address slots and factory MAC  
 > address from aggregations. In this case, should we have an option  
 > that shows that information as part of show-phys and show-aggr, or  
 > should we show that information via show-link since it might apply to  
 > different types of links.

Agreed.  As long as we can keep new things out of show-dev, I''m happy
:-)

 > >    * Similarly, as we''ve discussed in the past, a number of
the new
 > >      dladm "-d <dev>" options need to become "-l
<link>" post-UV.
 > 
 > Agreed. We''ve kept the man page in sync with ONNV since
that''s what
 > we''re based on today. As soon as UV and Crossbow merge, then
we''ll
 > update the option names accordingly to be consistent across the board.

Cool.

-- 
meem

Nicolas Droux wrote:
>Folks,
>
>I posted a first draft of the Crossbow virtualization architecture  
>document. It can be found at:
>
>http://opensolaris.org/os/project/crossbow/Docs/crossbow-virt.pdf
>  
>
good job Nicolas.

Quick comments/questions after a first skimming:

. About the Random MAC addresses for vnic. What was the rationale for 
having the local
bit set?

. There could be a bit of inconcistency in the expected behavior between 
create-vnic and
  move-vnic: create-vnic without -m attempts to allocates a factory MAC 
address, and, in
  case of unavailability generates a random one. The user doesn''t need 
any extra option
   for the right thing to succees. On the other hand, if the user is 
moving a
  vnic that was using a factory MAC address (even without the user''s 
explicitly asking for it),
  to a NIC that doesn''t has MAC address slots left, then he/she needs
to
pass an overriding
   option, -F, to force the move.
    The user didn''t care in the first time whether hardware resource 
must be used for
    the vnic, and shouldn''t care when the vnic is relocated neither.

. Any example of what down-vnic is needed for?


    Kais

LaoTsao(Dr. Tsao) wrote:
> hi
> what is the timeline for ce support of dladm for link aggregation?

No timeline for the porting of ce to Nemo yet. It is not in the scope of 
the crossbow project,

    Kais
> TIA
>
>

Kais Belgaied wrote:
>LaoTsao(Dr. Tsao) wrote:
>
>  
>
>>hi
>>what is the timeline for ce support of dladm for link aggregation?
>>    
>>
>
>
>No timeline for the porting of ce to Nemo yet. It is not in the scope of 
>the crossbow project,
>
>    Kais
>  
>
However, some people have expressed personal interest in doing that 
port: Garrett has already ported hme to nemo and is in the process of 
doing so for qfe. He told me he might do the same for ce.

Markus
>>TIA
>>
>>
>>    
>>
>
>_______________________________________________
>crossbow-discuss mailing list
>crossbow-discuss at opensolaris.org
>http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
>  
>

Kais Belgaied wrote:
> Nicolas Droux wrote:
> 
>> Folks,
>>
>> I posted a first draft of the Crossbow virtualization architecture  
>> document. It can be found at:
>>
>> http://opensolaris.org/os/project/crossbow/Docs/crossbow-virt.pdf
>>  
>>
> 
> good job Nicolas.
> 
> Quick comments/questions after a first skimming:
> 
> . About the Random MAC addresses for vnic. What was the rationale for 
> having the local
> bit set?
We need to have a OUI used by the VNIC to avoid conflicts with other 
nodes on the network. Using an existing Sun OUI with the local bit set 
was a quick way to get this. If we had a OUI reserved for VNICs, we 
wouldn''t have to turn the local bit on, but the allocation of new OUIs 
is not free.
> 
> . There could be a bit of inconcistency in the expected behavior between 
> create-vnic and
>  move-vnic: create-vnic without -m attempts to allocates a factory MAC 
> address, and, in
>  case of unavailability generates a random one. The user doesn''t
need
> any extra option
>   for the right thing to succees. On the other hand, if the user is 
> moving a
>  vnic that was using a factory MAC address (even without the
user''s
> explicitly asking for it),
>  to a NIC that doesn''t has MAC address slots left, then he/she
needs to
> pass an overriding
>   option, -F, to force the move.
>    The user didn''t care in the first time whether hardware
resource must
> be used for
>    the vnic, and shouldn''t care when the vnic is relocated
neither.
Yes, moving VNICs that have a factory MAC address assigned to it needs 
to be done with care. The user still needs to be informed in this case, 
since the VNIC MAC address shouldn''t be changed automatically during a 
move, and the factory MAC address cannot be simply moved along with the 
VNIC without warning, since it is still associated with the hardware 
that was underneath. That''s why the option needs to be specified.
> . Any example of what down-vnic is needed for?
For symmetry with ''up-vnic'', and for consistency with the
other pseudo
devices managed with dladm, and because it is useful to be able to 
quickly bring down all VNICs to be able to unload the VNIC driver.

Nicolas.
> 
> 
>    Kais
> 
-- 
Nicolas Droux - Solaris Networking - Sun Microsystems, Inc.
droux at sun.com - http://blogs.sun.com/droux

Kais Belgaied wrote:
> LaoTsao(Dr. Tsao) wrote:
>
>   
>> hi
>> what is the timeline for ce support of dladm for link aggregation?
>>     
>
>
> No timeline for the porting of ce to Nemo yet. It is not in the scope of 
> the crossbow project,
>   
Ask me again in a month.  There''s a good chance that I''ll have
something
beta testable by then.

    -- Garrett
>     Kais
>
>   
>> TIA
>>
>>
>>     
>
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
>

It might be worth adding SRs to CR 6575845. It is a P4 with only 
two service requests.

Markus.Flierl at Sun.COM wrote:
> Kais Belgaied wrote:
> 
> 
>>LaoTsao(Dr. Tsao) wrote:
>>
>> 
>>
>>
>>>hi
>>>what is the timeline for ce support of dladm for link aggregation?
>>>   
>>>
>>
>>
>>No timeline for the porting of ce to Nemo yet. It is not in the scope of
>>the crossbow project,
>>
>>   Kais
>> 
>>
> 
> However, some people have expressed personal interest in doing that 
> port: Garrett has already ported hme to nemo and is in the process of 
> doing so for qfe. He told me he might do the same for ce.
> 
> Markus
> 
> 
>>>TIA
>>>
>>>
>>>   
>>>
>>
>>_______________________________________________
>>crossbow-discuss mailing list
>>crossbow-discuss at opensolaris.org
>>http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
>> 
>>
> 
> 
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss

Good point!

Markus


Steffen Weiberle wrote:
> It might be worth adding SRs to CR 6575845. It is a P4 with only 
> two service requests.
>
> Markus.Flierl at Sun.COM wrote:
>   
>> Kais Belgaied wrote:
>>
>>
>>     
>>> LaoTsao(Dr. Tsao) wrote:
>>>
>>>
>>>
>>>
>>>       
>>>> hi
>>>> what is the timeline for ce support of dladm for link
aggregation?
>>>>   
>>>>
>>>>         
>>> No timeline for the porting of ce to Nemo yet. It is not in the
scope of
>>> the crossbow project,
>>>
>>>   Kais
>>>
>>>
>>>       
>> However, some people have expressed personal interest in doing that 
>> port: Garrett has already ported hme to nemo and is in the process of 
>> doing so for qfe. He told me he might do the same for ce.
>>
>> Markus
>>
>>
>>     
>>>> TIA
>>>>
>>>>
>>>>   
>>>>
>>>>         
>>> _______________________________________________
>>> crossbow-discuss mailing list
>>> crossbow-discuss at opensolaris.org
>>> http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
>>>
>>>
>>>       
>> _______________________________________________
>> crossbow-discuss mailing list
>> crossbow-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
>>     
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
>   

-- 
---
Markus Flierl
Manager, Solaris Core OS
17 Network Circle
Menlo Park, CA 94025

phone: 650-786-2056
http://blogs.sun.com/roller/page/markusflierl

> > . Any example of what down-vnic is needed for?
 > 
 > For symmetry with ''up-vnic'', and for consistency with
the other pseudo
 > devices managed with dladm, and because it is useful to be able to 
 > quickly bring down all VNICs to be able to unload the VNIC driver.

I presume that down-vnic (like down-aggr) would not be documented and thus
is intended for internal development use?  As an aside, I think the
current UV bits no longer have a down-aggr (since it was unused), but I
think it could be added back.  CC''ing clearview-discuss so that Cathy
can
comment.

-- 
meem

Hi, Nicolas,

The document looks very good.  But I think there is something wrong
with Figure 6.4:  Either ngz 1 should be plumbed to bge0 and vnic5 (not
vnic1), with the arrow line connecting to the anchor vnic5 (not to the
MAC/virtual switch), or vnic1 should be listed alongside vnic[234] in
the virtual switch dashed box and the arrow line connected there.  I
think the latter is more consistent with what the text says - ngz 1 is
connected to the virtual switch in exactly the same way as the other
ngzs, and the figure should make that clear.

					-=] Mike [=-

Nicolas Droux wrote:
> Folks,
>
> I posted a first draft of the Crossbow virtualization architecture  
> document. It can be found at:
>
> http://opensolaris.org/os/project/crossbow/Docs/crossbow-virt.pdf
>
> Enjoy!
>
> Nicolas.
>
>   
Hi Nicolas,

    Nice writing!

    A few questions:

    1. The document doesn''t seem to cover much on flows, is it due to 
that we are still discussing flows and the details are not determined yet?

    2. On page 29 and 30, there are several places which metioned 
"primary mac address of the VNIC", it seems to me that this implies
that
a VNIC can have more than one MAC address, is this the case?

    3. On page 34, can we get the status of physical NIC through VNIC, 
so in case physical NIC fails we can get a notification instead of using 
probe-based detection?


Thanks,
Zhijun

Hi Mike,

Thanks for your comments.

On Aug 12, 2007, at 1:41 PM, Mike Ford Ditto wrote:
> Hi, Nicolas,
>
> The document looks very good.  But I think there is something wrong
> with Figure 6.4:  Either ngz 1 should be plumbed to bge0 and vnic5  
> (not
> vnic1), with the arrow line connecting to the anchor vnic5 (not to the
> MAC/virtual switch), or vnic1 should be listed alongside vnic[234] in
> the virtual switch dashed box and the arrow line connected there.  I
> think the latter is more consistent with what the text says - ngz 1 is
> connected to the virtual switch in exactly the same way as the other
> ngzs, and the figure should make that clear.
That''s correct, vnic1 should be listed alongside vnic{2,3,4}. Good  
catch.

Nicolas.
>
> 					-=] Mike [=-
-- 
Nicolas Droux - Solaris Core OS - Sun Microsystems, Inc.
droux at sun.com - http://blogs.sun.com/droux

Nicolas Droux wrote:
> Folks,
> 
> I posted a first draft of the Crossbow virtualization architecture  
> document. It can be found at:
> 
> http://opensolaris.org/os/project/crossbow/Docs/crossbow-virt.pdf
> 
> Enjoy!
> 
> Nicolas.
> 
Nicolas,

Very good writeup. Thanks for doing this. As we were discussing
in the meeting today, one of the goals would be to ensure that
all Crossbow functionality works across all NICs and all platforms.
In that sense, exposing the rings and poll H/W APIs probably won''t
be suitable. If you can separate out the MAC apis into what a
typical MAC client can use and then possibly leave things specific
to our implementation in the header file itself (mac_impl.h would
be good here), that would be great.

As for mac clients, we agreed to think in terms of what are the
requirements instead of blindly exposing the H/W. For example, instead
of client saying that it needs 4 Rx rings, it should instead say
that it needs "level of parallelism" to be 4 and it can actually
assign specific CPUs as well. Similarly, client should say
it would rather use L2 as a hashing mechanism to spread load to 4
parallel threads instead of saying use a specific offset.

Cheers,
Sunay

-- 
Sunay Tripathi
Distinguished Engineer
Solaris Core Operating System
Sun MicroSystems Inc.

Solaris Networking:	http://www.opensolaris.org/os/community/networking
Project Crossbow:	http://www.opensolaris.org/os/project/crossbow

Nicolas,

This looks good.

Page 8.  Item 6.  should read ''VLANs to be implemented at the VNIC
layer
instead of DLS''

3.1.4 move-vnic:  Will the command fail if the vnic is busy ? That could 
be the easy route. Trying to move it while it is busy i.e. with clients 
having it open may be more difficult from an implementation perspective.

3.1.6, 3.1.7 - up-vnic and down-vnic is the same as creation and 
deletion of vnics except that it is done based on information from the 
repository instead of from the command line ? Somehow up and down 
conjure up vision of just a flag change (similar to ifconfig up/down) 
instead of creation / deletion, may be just the nomenclature ?

MAC API: We also need to mention somewhere that most (need to enumerate) 
control APIs may wait for serialization and must be called from a 
cv_waitable context. Also some more clarifications may be needed with 
respect to locking issues, Eg. upcalls must not hold any locks etc. Will 
get back to you after working out the issues more fully.

Thirumalai

Nicolas Droux wrote:
>Folks,
>
>I posted a first draft of the Crossbow virtualization architecture  
>document. It can be found at:
>
>http://opensolaris.org/os/project/crossbow/Docs/crossbow-virt.pdf
>
>Enjoy!
>
>Nicolas.
>
>  
>

> 3.1.4 move-vnic:  Will the command fail if the vnic is busy ? That could 
 > be the easy route. Trying to move it while it is busy i.e. with clients 
 > having it open may be more difficult from an implementation perspective.
 > 
 > 3.1.6, 3.1.7 - up-vnic and down-vnic is the same as creation and 
 > deletion of vnics except that it is done based on information from the 
 > repository instead of from the command line ? Somehow up and down 
 > conjure up vision of just a flag change (similar to ifconfig up/down) 
 > instead of creation / deletion, may be just the nomenclature ?

Maybe init-vnic would be more clear?  It has precedent (e.g.,
init-linkprop; init-secobj).

--
meem

Thiru,
Thiru,

Thirumalai Srinivasan wrote:
> Nicolas,
> 
> This looks good.
Thanks for your comments.
> 
> Page 8.  Item 6.  should read ''VLANs to be implemented at the VNIC
layer
> instead of DLS''
Yes.
> 
> 3.1.4 move-vnic:  Will the command fail if the vnic is busy ? That could 
> be the easy route. Trying to move it while it is busy i.e. with clients 
> having it open may be more difficult from an implementation perspective.
No, the move will not fail if the VNIC is busy. This allows VNICs to be 
moved to a different NIC or anchor VNIC without requiring the VNICs 
interfaces to be unplumbed.
> 
> 3.1.6, 3.1.7 - up-vnic and down-vnic is the same as creation and 
> deletion of vnics except that it is done based on information from the 
> repository instead of from the command line ? Somehow up and down 
> conjure up vision of just a flag change (similar to ifconfig up/down) 
> instead of creation / deletion, may be just the nomenclature ?
I''ve no problem using a better alternative like init-vnic as suggested 
by Meem. We could also rename up-aggr to init-aggr for consistency 
acrossbow the board, and use init-vlan instead of up-vlan as currently 
proposed by UV.
> 
> MAC API: We also need to mention somewhere that most (need to enumerate) 
> control APIs may wait for serialization and must be called from a 
> cv_waitable context. Also some more clarifications may be needed with 
> respect to locking issues, Eg. upcalls must not hold any locks etc. Will 
> get back to you after working out the issues more fully.
Yes, this will need to be properly documented. let me know and I will 
add the needed info.

Nicolas.
> 
> Thirumalai
> 
> Nicolas Droux wrote:
> 
>> Folks,
>>
>> I posted a first draft of the Crossbow virtualization architecture  
>> document. It can be found at:
>>
>> http://opensolaris.org/os/project/crossbow/Docs/crossbow-virt.pdf
>>
>> Enjoy!
>>
>> Nicolas.
>>
>>  
>>
> 
-- 
Nicolas Droux - Solaris Networking - Sun Microsystems, Inc.
droux at sun.com - http://blogs.sun.com/droux

Nicolas,

Nicolas Droux wrote:
> I posted a first draft of the Crossbow virtualization architecture  
> document. It can be found at:
> 
> http://opensolaris.org/os/project/crossbow/Docs/crossbow-virt.pdf
This is an excellent document.  I have a high-level question:

There was some discussion in the past about how Crossbow might subsume 
the functionality offered by the IPQos "feature" in the ip module.  Is
that still (or was that ever) one of the goals?

Along similar lines, the document talks about the ability to specify the 
priority associated with a given VNIC, but doesn''t define what that 
means.  Does the priority associated with a VNIC get mapped to the 
priority field (priority portion of ether_tci) of packets flowing through 
it?  If so, how do you handle a situation where a packet comes down from 
above with conflicting priority either due to the mblk''s b_band
setting,
a previously negotiated DL_UDQOS_* DLPI attribute, or non-zero 
dl_priority in the DL_UNITDATA_REQ?  Can these mechanisms override the 
VNIC''s setting, or is it the other way around?  I would guess that once
set at the VNIC level, nothing can override that.

Thanks,
-Seb

Seb,

Sebastien Roy wrote:
> Nicolas,
> 
> Nicolas Droux wrote:
>> I posted a first draft of the Crossbow virtualization architecture  
>> document. It can be found at:
>>
>> http://opensolaris.org/os/project/crossbow/Docs/crossbow-virt.pdf
> 
> This is an excellent document.  I have a high-level question:
Thanks for the review.
> There was some discussion in the past about how Crossbow might subsume 
> the functionality offered by the IPQos "feature" in the ip
module.  Is
> that still (or was that ever) one of the goals?
We''re not going to EOL IPQoS for now. I think we still need to go 
through a more comprehensive gap analysis to know how far we are from 
being able to do that, and of course better understand the impact on 
users who might be still be depending on these interfaces.
> Along similar lines, the document talks about the ability to specify the 
> priority associated with a given VNIC, but doesn''t define what
that
> means.  Does the priority associated with a VNIC get mapped to the 
> priority field (priority portion of ether_tci) of packets flowing 
> through it?  If so, how do you handle a situation where a packet comes 
> down from above with conflicting priority either due to the mblk''s
> b_band setting, a previously negotiated DL_UDQOS_* DLPI attribute, or 
> non-zero dl_priority in the DL_UNITDATA_REQ?  Can these mechanisms 
> override the VNIC''s setting, or is it the other way around?  I
would
> guess that once set at the VNIC level, nothing can override that.
No, we''re talking about something different. In this context we mean
the
priority of the threads that process traffic for these MAC/VNICs/flows.

Thanks,
Nicolas.

-- 
Nicolas Droux - Solaris Networking - Sun Microsystems, Inc.
droux at sun.com - http://blogs.sun.com/droux