Scott Feldman <scofeldm@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" <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.
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