<tt>Scott Feldman <scofeldm@cisco.com> wrote on 05/08/2010 07:28:11 PM: > chrisw, libvir-list, libvir-list-bounces, Vivek Kashyap</tt> <tt>> > On 5/8/10 12:12 PM, "Stefan Berger" <stefanb@us.ibm.com> wrote: > > >> From: Scott Feldman <scofeldm@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</tt> <tt>> need the VDP tuple encoded in port-profile. We need a string to identify > the desired port-profile.</tt> <tt>I thought this was the work of the standards committee ... If I understand the </tt> <tt>situation correctly, then there is a setup protocol that needs to be run with</tt> <tt>the switch to setup parameters for clients' network streams on a port. That </tt> <tt>protocol needs a couple of parameters. In your case you seem to need the </tt> <tt>profile id and then the hosts' uuid. What else do you need? Do you need the</tt> <tt>manager ID in that protocol + type id + type id version as proposed yesterday?</tt> <tt>Or is the protocol not 100% defined, yet?</tt> <tt>> VSI Manager ID 1 octet > VSI Type ID 3 octets > VSI Type ID Version 1 octet > VSI Instance ID 16 octets <-- taken care of via dimdecode </tt> <tt> > > 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"?</tt> <tt>This is fine by me, but we could also split it up into different fields.</tt> <tt>I assume that different vendors' switches will all somehow need to see the</tt> <tt>same parameters so they can run the protocol? Virtual machines will also</tt> <tt>be able to migrate to hosts that are connected to different vendors' switches</tt> <tt>and then will always present the same set of parameters since they migrate </tt> <tt>along. So I hope this is completely independent of what vendor's switch</tt> <tt>is connected to a host.</tt> <tt> > > > 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</tt> <tt>The guest UUID is available in libvirt and can be passed through to where it </tt> <tt>is needed but I didn't see you sending it via the netlink message so far.</tt> <tt>What is a 'guest port'? The port the cable from the host is connected to the</tt> <tt>switch (port)?</tt> <tt> > 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.</tt> <tt>Yeah, I guess you can figure out in the kernel whether to contact the hardware</tt> <tt>for eth{0, 1, or 2} to run the protocol on.</tt> <tt> > > 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.</tt> <tt>Though it seemed a pattern that when a macvtap was opened or closed that the</tt> <tt>function to set or unset the port profile was always called. So instead of calling</tt> <tt>the close macvtap function + the unset function for the profile in 3 different places, </tt> <tt>just call the close macvtap function in 3 places and have the close macvtap</tt> <tt>call the unset function for the profile. If other components can also use the </tt> <tt>profile related functions, we can still export them, but at the moment we don't</tt> <tt>have the necessary parameters available if anything else than the 'direct' type of </tt> <tt>interface was to be used.</tt> <tt> > 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.</tt> <tt>Yes, as said, the setPortProfile can then become {vsi|vepa}SetPortProfile, and be exported</tt> <tt>for other functions to use.</tt> <tt> > > > > > 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.</tt> <tt>Yes, and you are using #define's that aren't available for many, yet, so you</tt> <tt>may need to add #ifdef's around certain code parts and fail the function</tt> <tt>with error related to unavailable kernel functionality if #ifndef.</tt> <tt>Also we'll probably need an rpm dependency on the dmidecode package.</tt> <tt> Stefan</tt> <tt> > > -scott > </tt>