Nicolas Droux writes:
> http://opensolaris.org/os/project/crossbow/Docs/crossbow-virt.pdf
I have A few questions about this. I've also read through as much of
the crossbow-discuss archives as seemed to be related to these
topics, and didn't find answers there.
- Why are bandwidth, CPU control, and MAC address assignment
exclusively a VNIC feature, at least at the administrative level?
Section 4.7 seems to say that MAC instances will get these
features, so shouldn't this be "modify-dev" instead?
Needing to create a "dummy" VNIC on top of a regular interface
just to interpose these new features seems like an implementation
artifact.
- I assume we need a redesign of the VLAN code in order to get
per-VLAN bandwidth control. Is that redesign part of Crossbow, or
is it some later project? In reading the archives, it seems that
it's been proposed as part of Crossbow, but in reading this
document it seems to be part of something else.
- If per-VLAN control appears, do the units of administration
change? Does it then become reasonable to talk about bandwidth
and CPU control using "set-linkprop"?
- Do bandwidth and CPU controls rely on squeues? If so, then VNICs
may not be able to control utilization from non-IP traffic, such
as with bridging.
- I'm not sure I understand the (undocumented? -- not in summary)
"-F" option for move-vnic. If I'm using a factory address on one
NIC and I move a VNIC to another NIC, does this cause the VNIC to
continue using the _same_ address but just on a new NIC?
If so, how is duplication avoided if that factory address is ever
reused from the original NIC?
I would have expected that a VNIC using a factory address would
just get a *new* address during a forced move to a new NIC.
Changing MAC address during reconfiguration doesn't seem like a
disaster to me -- in fact, it seems expected. Why should it try
to retain the address?
- For showing statistics with "show-vnic -s", are these the same as
"show-link -s"? If so, wouldn't the existing "show-link -s" do
the job?
- What do "up" and "down" mean? Are these equivalent to controlling
the "RUNNING" bit from user space (i.e., some way of marking link
up and link down manually)? Or are they something else? Should
regular MAC instances (other than VNICs) have the ability to be
set administratively up and down?
What would happen if VNICs were always "up?"
- What happens if a NIC is oversubscribed by the amount of bandwidth
configured for the VNICs? Is the result proportionate (and thus
"fair") allocation, or do they compete on some other grounds?
What kind of bandwidth control exists here? How granular is it,
and what effects do clients see from restricted bandwidth? Are
packets dropped (they have to be, if bandwidth limits apply to
forwarded traffic)? If so, is it tail drop or something more
sophisticated?
- Can a VNIC be built atop another non-anchor VNIC? (Seems like the
answer is "yes.")
- When VNICs share rings due to a lack of hardware resources, what
happens when the client of one VNIC is using polling and the
client of the other one is not?
Won't one client end up blanking the interrupts for another?
- Instead of adding more arguments to mac_open() to handle priority
and bandwidth, I'd suggest making these separate calls. You'll
need the separate call anyway to implement the "modify" mechanism.
- What exactly does exclusive MAC access do? If mac_exclusive_set
is called, are other client requests blocked (sleeping)? Or are
they rejected (return error)? Or are they just let through, and
all clients are expected to bracket requests with exclusive
set/clear calls?
- MAC_UNICAST_AUTO seems unnecessary to me. Why not just call first
with MAC_UNICAST_FACTORY and, if that fails, call again with
MAC_UNICAST_RANDOM? Doing that would even have better
functionality as MAC_UNICAST_AUTO seems to omit the possibility of
desiring a particular factory address when available.
I think having MAC_UNICAST_AUTO in the mix ends up pushing some of
the control-path complexity out of the user space and into the
kernel. It'd be better to simplify the kernel parts.
- What sorts of privileges are required to create and administer
VNICs? Are these things that can be delegated to non-global
zones?
- Why is [V]NIC the right level of bandwidth control? If I want to
give a zone 100Mbps worth of bandwidth, but I'm giving it multiple
VNICs, how do I do that -- can the bandwidth control logic do
accounting based on multiple interfaces (aggregate control, rather
than individual interface control)?
If I have application-level controls, such as HTTP virtual servers
or a sendmail configuration handling multiple domains, how can I
control bandwidth for those things? Won't the application need to
be involved?
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
