On Thursday 27 May 2010, Stefan Berger wrote:
> On Thu, 2010-05-27 at 17:43 +0200, Arnd Bergmann wrote:
> > > > Yes, the Qbg wire protocol has no need for this, because the
> > > > messages are only sent after the state has changed, we never
> > > > see a VDP message with an incomplete status in there, so there
> > > > is no need to specify it in Qbg, but we need something in the netlink
> > > > protocol.
> > >
> > > Yes, I would suggest to mimic 802.1Qbh in this case.
> >
> > Like what? The first 256 result numbers in the netlink protocol
> > are meant to be the same as the ones in the wire protocol, the
> > next 256 are for the Qbh protocol.
>
> I did not look carefully and differentiate between error codes of
> 802.1Qbg or .1Qbh but took them as shared between both technologies.
We discussed several options here but in the end went for separate
ranges.
> > We could of course define yet another range for the inprogress
> > result and possibly future extensions, starting at 512 if you
> > insist on requiring the IFLA_PORT_RESPONSE.
> >
>
> No, I'll fake it for now with the INPROGRESS value of 802.Qbh.
ok. This could probably use a comment of some sorts in the code then ;-)
> > I originally wanted to defer the response until we hear back
> > from the switch, but that may take a really long time
> > (over a minute with all the VDP timeouts). That would be
> > cleaner IMHO, but you may not want to wait that long in libvirt.
> >
>
> 802.1Qbh is polling for max. 10 seconds. So we need to tune this
> to a even higher value for 802.1Qbg ?
I fear so, yes. The actual maximum timeout get negotiated between
the switch and the host, but since there are retries on both the
lower ECP and the upper VDP layer, it can take a long time. Maybe
Jens knows a reasonable default for you.
> > I'd suggest doing a request with
> >
> > vfinfo_attr[IFLA_VF_MAC] = { .vf = -1u, .mac = OUR_MAC };
> > vfinfo_attr[IFLA_VF_VLAN] = { .vf = -1u, vlan = OUT_VLAN };
> > vf_port_attr[IFLA_PORT_VF] = NULL; /* don't send this at all */
> > vf_port_attr[IFLA_PORT_RESPONSE] = NULL; /* also don't send this */
> > vf_port_attr[IFLA_PORT_*] = WHATEVER_WE_NEED;
> >
> > and waiting for the receiver to choose a free VF and ack this message with
> >
>
> I think the typical ACK in a netlink message on a RTM_SETLINK is just
> an error code indication of whether the message was successfully process
> or now. The subsequent RTM_GETLINK would then return what you show here.
Ok, I didn't know that. I assumed that the response was always the full
message that got sent as a request, plus anything filled in that is
needed (like the VF number here).
Arnd
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list