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