Scott Feldman <scofeldm@xxxxxxxxx> 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" <stefanb@xxxxxxxxxx> wrote:
>
> > libvir-list-bounces@xxxxxxxxxx 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list