------- Comment From [email protected] 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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1541544 Title: ubuntu-installer makes a contradictional statement regarding layer2/layer3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1541544/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
