<tt>Scott Feldman <scofeldm@cisco.com> wrote on 05/10/2010 03:11:22 PM: > > chrisw, Gerhard Stenzel, libvir-list, libvir-list-bounces</tt> <tt>> > On 5/10/10 11:57 AM, "Stefan Berger" <stefanb@us.ibm.com> wrote: > > > libvir-list-bounces@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.</tt> <tt>Would it be possible to support these 2 XML :</tt> <tt> <interface type='direct'></tt> <tt> <source dev='static' mode='vepa'/></tt> <tt> <model type='virtio'/></tt> <tt> <vsi managerid='12' typeid='0x123456' typeidversion='1'</tt> <tt> instanceid='fa9b7fff-b0a0-4893-8e0e-beef4ff18f8f' /></tt> <tt> <filterref filter='clean-traffic'/></tt> <tt> </interface></tt> <tt> <interface type='direct'></tt> <tt> <source dev='static' mode='vepa'/></tt> <tt> <model type='virtio'/></tt> <tt> <vsi profileid='my_profile'/></tt> <tt> </interface></tt> <tt> and profileid becomes mutually exclusive to the parameters shown above.</tt> <tt>The internal data structures (domain_conf.h) to use would be defined as this:</tt> <tt>enum virVSIType {</tt> <tt> VIR_VSI_INVALID,</tt> <tt> VIR_VSI_8021QBG,</tt> <tt> VIR_VSI_8021QBH,</tt> <tt>};</tt> <tt>/* profile data for macvtap (VEPA) */</tt> <tt>typedef struct _virVSIProfileDef virVSIProfileDef;</tt> <tt>typedef virVSIProfileDef *virVSIProfileDefPtr;</tt> <tt>struct _virVSIProfileDef {</tt> <tt> enum virVSIType vsiType;</tt> <tt> struct {</tt> <tt> uint8_t managerID;</tt> <tt> uint32_t typeID; // 24 bit valid</tt> <tt> uint8_t typeIDVersion;</tt> <tt> unsigned char instanceID[VIR_UUID_BUFLEN];</tt> <tt> } vsi8021Qbg;</tt> <tt>#ifdef IFLA_VF_PORT_PROFILE_MAX</tt> <tt> struct {</tt> <tt> char profileID[IFLA_VF_PORT_PROFILE_MAX];</tt> <tt> } vsi8021Qbh;</tt> <tt>#endif</tt> <tt>};</tt> <tt>[...]</tt> <tt> struct {</tt> <tt> char *linkdev;</tt> <tt> int mode;</tt> <tt> virVSIProfileDef vsiProfile;</tt> <tt> } direct;</tt> <tt>Regards,</tt> <tt>Stefan</tt>