[Bcc'ing [email protected], let's continue the
discussion on [EMAIL PROTECTED]
A couple of additional items came up while I was making some progress
on the VNIC design and implementation.
- Editorial: the "-m share" option will not be provided for our next
release, so it should be removed from that man page to avoid confusion.
- I don't think the model we've been considering of exposing MAC
address slot numbers to dladm(1M) users is really useful, and it adds
unnecessary complexity to the user interface as well as the
underlying kernel implementation.
A user wants to assign one of the factory MAC addresses to a VNIC. I
don't see why the actual slot which ends-up being assigned to a VNIC
when it is created matters [1,2]. It would be sufficient to always
choose the slot number for the user when a VNIC is created, and store
that slot number with the rest of the VNIC configuration. That
approach would allow the same factory MAC address to be assigned to
the VNIC when the host OS restarts, and also avoid exposing MAC
address slots to dladm(1M) users.
For these reasons I propose we remove the -m option from "dladm show-
dev", and the -n option from "dladm create-vnic".
Thanks,
Nicolas.
Footnotes:
[1] Internally, VNICs will still be able to distinguish between the
primary unicast address of the underlying NIC, and the additional
factory MAC addresses. This will be needed when we allow a NIC to be
shared by VNICs and plumbed directly, i.e. the "bge0" data-link will
in this case become a VNIC with the default unicast address of the
bge0 NIC.
[2] If we provide "-m shared" in the future, the grouping of VNICs
sharing the same MAC factory MAC address could still be expressed
without requiring exposing the MAC address slots. A factory MAC
address slot would be selected automatically when a group is first
created.
On Oct 24, 2006, at 1:05 AM, Sunay Tripathi wrote:
Guys,
As promised earlier, the two manpages for Crossbow are attached.
dladm (1M) allows creation/modification/deletion of Virtual NICs
and assigning bandwidth resources to it including binding
them to processors.
netrcm (1M) allows assigning bandwidth and CPU resources to
flows without creating the VNICs as administrative entity (primarily
used for service consolidation and tradition QOS based usage).
This is the first draft of the man pages that we are targetting for
next release of Crossbow bits. Comments/feedback welcome.
Cheers,
Sunay
--
Sunay Tripathi
Sr. Staff Engineer
Solaris Core Networking Technologies
Sun MicroSystems Inc.
Solaris Networking: http://www.opensolaris.org/os/community/networking
Project Crossbow: http://www.opensolaris.org/os/project/crossbow
<dladm.1m.txt>
<netrcm.1m.txt>
_______________________________________________
crossbow-discuss mailing list
[EMAIL PROTECTED]
http://opensolaris.org/mailman/listinfo/crossbow-discuss
--
Nicolas Droux, Solaris Kernel Networking
Sun Microsystems, Inc. http://blogs.sun.com/droux
_______________________________________________
networking-discuss mailing list
[email protected]
