On 5/8/10 12:12 PM, "Stefan Berger" <stefanb@xxxxxxxxxx> wrote:
>> From: Scott Feldman <scofeldm@xxxxxxxxx>
>> 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list