[crossbow-discuss] Re: driver API information

Paul Durrant pdurrant at gmail.com
Thu Sep 28 12:02:59 PDT 2006


On 9/27/06, Nicolas Droux <Nicolas.Droux at sun.com> wrote:
> Paul,
>
> On Sep 27, 2006, at 5:45 AM, Paul Durrant wrote:
>
> > m_vnic_create/destroy entry point - to request new vnic
> > creation/destruction (creation should cause the driver to register the
> > interface to the vnic using the normal mac_register() call).
>
> Do you require a kernel API in this case?

Personally not from a client point of view, although I guess Xen
required some sort of kernel API to set up a new vnic and then map it
into a domU.

> Currently VNIC creation/
> deletion is driven by a new libvnicadm library. This library is used
> by dladm(1M) and we could envision exporting it as a public interface
> as well. Note that the VNIC creation already triggers a mac_register
> () today, more on that below.
>
> > m_vnic_steer entry point - to be passed a description of a flow or
> > flows that should be steered to a particular vnic
>
> Traffic is steered to the VNICs according to the MAC address
> associated with the VNIC. The MAC address is basically what
> characterizes the main flow of the VNIC [1]. Within a VNIC, or any
> other data-link for that matter, we will allow sub-flows to be
> defined. The plan is to allow separate rings to be associated with
> these sub-flows, if hardware resources are available. When a sub-flow
> is created, it can then be associated with a callback routine which
> will be invoked to process traffic matching that sub-flow. Would this
> work for you?

Yes. Our h/w will not steer traffic based on MAC address - our point
of view is that the MAC is associated with the physical port rather
than any virtualization thereof. We steer traffic to multiple receive
queues based only on IP header information.

>
> >
> > mac_open() could then be used to access the vnic (or perhaps vmac?) as
> > if it were just another piece of h/w.
>
> That's already the case today. The VNIC driver registers a separate
> MAC for each created VNIC. To the rest of the system, VNICs look and
> behave like regular NICs, and can be opened through mac_open() of
> course.
>

Cool. Sounds good.

  Paul

> Thanks,
> Nicolas.
>
> [1] we are also considering allowing the administrator to have
> multiple VNICs share a MAC address of the underlying NIC, in this
> case the IP address will be part of what characterizes the main flow
> of a VNIC.
>
> --
> Nicolas Droux, Solaris Kernel Networking
> Sun Microsystems, Inc. http://blogs.sun.com/droux
>
>
>
>


-- 
Paul Durrant
http://www.linkedin.com/in/pdurrant



More information about the crossbow-discuss mailing list