Comment 8 for bug 1541544

------- Comment From <email address hidden> 2016-02-08 07:33 EDT-------
Hi,

thanks for this important information. It would advice to list these also in the Device Drivers Book. I have seen that information not before and it could help to improve the implementation of the s390-netdevice.

(In reply to comment #10)
> Virt.NIC QDIO - depends on the z/VM layer configured, more details below
> Virt.NIC Hiper - always layer3
> Virt.NIC OSM - that's dead code, does not occur, I will add the removal on
> my to do list, any default is ok
> Virt.NIC OSX - that's dead code, does not occur, I will add the removal on
> my to do list, any default is ok
> unknown - should hopefully not occur, thus any default is ok
> OSD_100 - both layers possible, use layer2 as default
> HSTR - token ring no longer supported, does not occur, has been layer3 only
> OSD_1000 - both layers possible, use layer2 as default
> OSD_10GIG - both layers possible, use layer2 as default
> OSD_FE_LANE - outdated type, does no longer occur, has been layer3 only
> OSD_TR_LANE - token ring no longer supported, does not occur, has been
> layer3 only
> OSD_GbE_LANE - outdated type, does no longer occur, has been layer3 only
> OSD_ATM_LANE - outdated type, does no longer occur, has been layer3 only
> OSD_Express - both layers possible, use layer2 as default
> HiperSockets - both layers possible, use layer3 as default
> OSN - special case, needed for an IBM product already approaching end of
> life time (end of service effective 2016-03-31), does not have a layer2
> attribute at all, ignore?
> OSM_1000 - always layer2
> OSX_10GIG - both layers possible, use layer2 as default
>
> As you see, there are still some outdated OSA-types listed, which we have
> not yet removed to still enable running on old hardware. They are not
> critical, and you can configure them as you like.

Is there a sysfs attribute to get a numeric type for these or does an implementation needs to parse the strings?

>
> A problematic type is "Virt.NIC QDIO". Here qeth does not yet determine the
> layer of the z/VM VSWITCH automatically. zVM commands allow to determine the
> layer. You could first determine the name of the VSWITCH, a virtual NIC is
> connected to - with "vmcp q virtual nic <vdev>" .
> Sample:
> > vmcp QUERY VIRTUAL NIC f5f0
> Adapter F5F0.P00 Type: QDIO Name: HYD1G1 Devices: 3
> MAC: 02-12-34-56-78-90 VSWITCH: SYSTEM VSW444
> Here "VSW444" is the name of the VSWITCH. Then you can determine the layer
> of the VSWITCH with "vmcp q vswitch <vswitch name>".
> Sample:
> > vmcp QUERY VSWITCH VSW444
> VSWITCH SYSTEM VSW444 Type: QDIO Connected: 9 Maxconn: INFINITE
> PERSISTENT RESTRICTED ETHERNET Accounting: OFF
> ...
> The keyword here is "ETHERNET". In this case layer2 must be configured for
> the virtual NIC, otherwise layer3.

AFAIK, the CP QUERY VSWITCH is a privileged command and, thus, an implementation should not rely on getting this information.