Scott Feldman <scofe...@cisco.com> wrote on 05/10/2010 03:11:22 PM: > > chrisw, Gerhard Stenzel, libvir-list, libvir-list-bounces > > On 5/10/10 11:57 AM, "Stefan Berger" <stef...@us.ibm.com> wrote: > > > libvir-list-boun...@redhat.com wrote on 05/10/2010 02:35:49 PM: > > > > > >> > >> Correct, IFLA_VF_PORT_PROFILE is not in the kernel yet. The kernel > >> patch is be discussed on the kernel netdev mailing list. The most recent > >> discussion is on ways to merge VDP and CDCP into what I've posted for > >> IFLA_VF_PORT_PROFILE. > >> > >> I'll send out another libvirt patch once the kernel discussions are > >> final. > > > > I suppose you will provide the libvirt patch only for what seems to be > > Cisco technology support. > > I can only test with our production equipment setup, so I'm hesitant to > include additions to the patch for VDP/CDCP which I can't test. > > > Now the slight differences in technology > > that we seem to try to support here are reflected in the parameters that > > go into the XML and end up in the netlink messages. Any way to > > consolidate that? > > I doesn't appear we'll be able to consolidate the parameters between the two > technologies based on what I've seen from Arnd's latest patch on the kernel > mailing list. The latest proposal is to define a single netlink msg that > can handle two disjoint sets of parameters. If there is no way for further > consolidation, it probably makes more senses to have two different netlink > msgs, one for each parameter set.
Would it be possible to support these 2 XML : <interface type='direct'> <source dev='static' mode='vepa'/> <model type='virtio'/> <vsi managerid='12' typeid='0x123456' typeidversion='1' instanceid='fa9b7fff-b0a0-4893-8e0e-beef4ff18f8f' /> <filterref filter='clean-traffic'/> </interface> <interface type='direct'> <source dev='static' mode='vepa'/> <model type='virtio'/> <vsi profileid='my_profile'/> </interface> and profileid becomes mutually exclusive to the parameters shown above. The internal data structures (domain_conf.h) to use would be defined as this: enum virVSIType { VIR_VSI_INVALID, VIR_VSI_8021QBG, VIR_VSI_8021QBH, }; /* profile data for macvtap (VEPA) */ typedef struct _virVSIProfileDef virVSIProfileDef; typedef virVSIProfileDef *virVSIProfileDefPtr; struct _virVSIProfileDef { enum virVSIType vsiType; struct { uint8_t managerID; uint32_t typeID; // 24 bit valid uint8_t typeIDVersion; unsigned char instanceID[VIR_UUID_BUFLEN]; } vsi8021Qbg; #ifdef IFLA_VF_PORT_PROFILE_MAX struct { char profileID[IFLA_VF_PORT_PROFILE_MAX]; } vsi8021Qbh; #endif }; [...] struct { char *linkdev; int mode; virVSIProfileDef vsiProfile; } direct; Regards, Stefan
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list