[libvirt] [PATCH v8] add 802.1Qbh and 802.1Qbg handling

[Arnd Bergmann]

On Wednesday 26 May 2010, Stefan Berger wrote:
> On Wed, 2010-05-26 at 15:45 +0200, Arnd Bergmann wrote:

> > 
> > I think we need to distinguish three cases here, not two: PORT_SELF_VF
> > (configuring an enic static function), a specific VF (configuring an
> > enic dynamic function) and no VF at all (using lldpad). We cannot use
> > IFLA_PORT_SELF in lldpad because that would imply that we do the
> > communication on the macvtap link itself, which is not allowed to talk
> > VDP to the switch.
> > 
> > We also need a way to communicate the MAC and VLAN address to lldpad
> > in this case.
> 
> Why is that? If we tell lldpad the macvtap device name, it can walk the
> links backwards to the root physical device and determine the vlan id on
> the way. I think it is the most generic solution to let lldpad start
> from the 'top', no? It would do just the same as libvirt would do
> internally.

We should never need to tell lldpad the macvtap name, because lldpad
should not need to care about the implementation details of macvtap.
The problem is that the link may be on anything, including but not limited
to
- tap on a bridge
- raw socket on vhost-net
- macvlan
- macvtap
- sr-iov VF

Some of these are not visible to lldpad, or may not have been created
yet, or may already be in a different namespace, so it's impossible
for lldpad to cover this in general, only the macvtap/macvlan case
without namespaces would work reliably.

libvirt however does know both the mac address and the vlan id,
because it knows what it has created (e.g. macvlan) or configured
(e.g. sr-iov).

> > I would suggest leaving out the IFLA_PORT_VF attribute in that case,
> > and transmitting IFLA_VF_MAC and IFLA_VF_VLAN attributes with their
> > vf field set to zero or maybe (__u32)-1. lldpad would then choose
> > a vf number for its internal housekeeping which gets returned when
> > querying the device, so you have an identifier to refer to.
> 
> So, please modify my dummy server so I can test this.

patch attached.

> > What is ifname here, the macvtap interface or the underlying
> > interface that lldpad talks to?
> 
> It's the macvtap device and lldpad would determine what the underlying 
> physical device is.

Ok, so we need to fix that as well. In case of enic VFs, we also
need to pass the physical device, so the information should be there
somewhere in libvirt. Passing the macvtap device won't work because
of the reasons mentioned above.

> > > +    rc = doPortProfileOpCommon(nltarget_kernel, ifindex,
> > > +                               NULL,
> > > +                               &portVsi,
> > > +                               virtPort->u.virtPort8021Qbg.instanceID,
> > > +                               NULL,
> > > +                               PORT_SELF_VF,
> > > +                               op);
> > 
> > Maybe just pass vf=0 here?
> 
> What are the semantics of
> < 0: ?
> = 0: ?
> > 0: ?
> 
> in case of 802.1Qbg?

This is independent of Qbg but depends on whether we're talking to
the kernel or to a user application like lldpad. The VF number does
not have a meaning to lldpad, so we can define whatever we see fit
here.
My idea was to always pass VF=0 on a request in the IFLA_VF_VLAN
and IFLA_VF_MAC attributes, which unfortunately require putting
something in there. lldpad can reject anything that has a nonzero
number in there, to let us extend the protocol in the future.

	Arnd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: netlinkserver-mac-vlan.patch
Type: text/x-patch
Size: 4525 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20100526/9448df14/attachment-0001.bin>