[libvirt] [libvirt PATCH] Port-profile ID support using IFLA_VF_PORT_PROFILE netlink msg

[Scott Feldman]

On 5/8/10 12:12 PM, "Stefan Berger" <stefanb at us.ibm.com> wrote:

>> From: Scott Feldman <scofeldm at cisco.com>
>> The device XML is:
>> 
>>     <interface type='direct'>
>>         <source dev='eth2' mode='private' profileid='dc_test'/>
>>         <mac address='00:16:3e:1a:b3:4b'/>
>>     </interface>
>> 
>> The port-profile ID msg is sent to source dev.
> 
> Great. Now we have two competing implementations where the underlying
> technology is supposed to be VEPA in both but the parameters to set
> it up are vastly different --
> if you compare
> against Vivek's post yesterfa. Above you are providing a profile id in
> form of a string.
> Is that string above just a dummy example or a real-world parameter that
> can actually be passed?

It was an example string.  The RTM_SETLINK IFLA_VF_PORT_PROFILE msg type
uses u8 array for port_profile, with the idea that it can hold a string (as
in the above example) or some encoded bytes.

> Vivek posted a message yesterday showing now 4 different parameters... are
> these somehow encoded in the profileid in your case or you simply don't
> need them?

Yes, somehow encoded.  There was discussion on the kernel netdev mailing
list on how to merge the VDP tuple into the port-profile, but I haven't seen
the final form.  Can you help push that discussion along?  Our case doesn't
need the VDP tuple encoded in port-profile.  We need a string to identify
the desired port-profile.

I think we can agree on these goals:

1) single RTM_SETLINK netlink msg type for set/unset of port-profile
2) single method in libvirt to send port-profile using RTM_SETLINK
3) single representation in XML

I'm not sure is 3) is possible given the different encodings of
port-profile.  Can the VDP tuple be represented as a string, e.g.
"1.2345.6"?

> I see you are getting the host UUID
> vid dmidecode, so there are still3 parameters left. Anyway, I let you guys
> figure that out.

Ideally, we'd like to have host UUID, guest UUID, and even name of guest
port, if available.  Any extra information passed with the port-profile
helps mgmt software organize the virtual ports.
 
> I suppose in your case we would use the external daemon to derive eth0
> from eth0.100 where the
> macvtap would be connected on along with the vlan id in eth0.100. So the
> functions I posted
> yesterday may need to go into that code then.

In our case, the src device driver in the kernel receives the RTM_SETLINK
msg directly; there is no external daemon on the host.  Our driver will
handle the RTM_SETLINK msg directly to make sure the virtual port is set up
accordingly.

Note the RTM_SETLINK msg is sent with multicast RTNLGRP_LINK so either a
host daemon or a kernel netdev driver may receive the port-profile msg.
 
>> diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
>> index 5fa8c0a..aff6f28 100644
>> --- a/src/qemu/qemu_conf.c
>> +++ b/src/qemu/qemu_conf.c
>> @@ -1479,6 +1479,11 @@ qemudPhysIfaceConnect(virConnectPtr conn,
>>          net->model && STREQ(net->model, "virtio"))
>>          vnet_hdr = 1;
>> 
>> +    if (!STREQ(net->data.direct.profileid, ""))
>> +        setPortProfileId(net->data.direct.linkdev,
>> +                         net->data.direct.profileid,
>> +                         net->mac);
>> +
> 
> Since setting up a port profile seems to be a step tightly connected
> to opening the macvtap I'd push this into the openMactapTap function.

I don't think port-profile should be tightly coupled with macvtap.  For
example, port-profile would be applicable for vhost-net where the emu device
sits right on top of the kernel netdev.  There is no macvtap in that case.
Here are some of the examples use-cases for port-profile that don't involve
macvtap:

    PCI device passthru
    vhost-net
    software tagging switch over simple nics that passthru tags

I'm sure there will be other ways invented to plumb the virtual device to
the guest interface.

> 
> use the libvirt function to copy string
> 
> 
> check for error
> 
> 
> use libvirt function to copy string
> 

I'll resend with this fixes.  Thanks for the review.

-scott