On 12/16/2013 04:32 PM, Stefan Raspl wrote: > Am 12.12.2013 22:47, schrieb John Fastabend: >> [...] >> >>>> Just to elaborate... >>>> >>>> Any application using lldp information will want to get events when >>>> TLVs change. Maybe you can contrive ethtool to do this but its >>>> going to >>>> be ugly. Netlink can support multicast events and applications can >>>> register for them. Also netlink's TLV format matches nicely with >>>> LLDPs >>>> TLV format. >>> >>> ethtool and netlink usually intersect for a few bits of information >>> such as link status for instance. It is useful to have this >>> information twice, with ethtool as a debugging aid, and via >>> netlink to >>> take appropriate actions. >>> >>> Maybe we just need to be clear on what needs to be present in ethtool >>> only (configuration, static information) and see on a case-by-case >>> what needs to be present in both ethtool and netlink? >>> >> >> OK if there is an enable/disable bit in ethtool that might make some >> sense. Or an error flag that is helpful to have. >> >> In this case we are dealing with peer attributes which are dynamic and >> in my opinion should go into netlink and duplicating them in ethtool >> although possible doesn't seem very useful to me. > > I think what most folks in the discussion so far assume is that we > have a full LLDP implementation with respective hooks and events. > This is not true for our device: We can only poll it for the > adjacent link port's state, and that's it. I.e. we don't receive any > events for changes on the port's state. > lldpad seems to handle the entire LLDP layer in software. And I'm > not sure if our device integrates with that so well, as it handles > LLDP on its own. We'd have to disable pretty much all functionality > that lldpad offers, and limit support to display of a few parameters > which we would have to poll on demand. > Likewise with netlink: If one of the arguments for netlink is that > it supports notifications, then we can't take any advantage of that > either, for the reasons stated above. > By its nature, what we can offer and support with our device is > simple debugging functionality, displaying the current state of the > switch port at a given moment - just like ethtool will display the > current port speed and media type. Hence the original idea to add > respective functionality to ethtool in a generic manner, so others > with similar constraints could use it as well. > If ethtool is not acceptable, and if lldpad and netlink are no good > fits either, would respective sysfs attributes for our device type work? Since I didn't receive any further feedback, please let me summarize: * As elaborated in my most recent reply (cited above), our device does not provide for any notifications regarding LLDP-related events - we can only query the current state. Hence we could not take advantage of a netlink interface. Plus even if we still went with netlink, we'd have to introduce yet another userspace tool just for querying the current state. * For the same reason, lldpad would be hard to integrate with, since all we can do is to query a limited amount of information, where lldpad seems to be targeted at devices that can provide events. * Integration with ethtool was our attempt at providing a common interface for our and other devices with similar characteristics regarding LLDP, since ethtool is semantically a good fit. However, it was indicated that this is not desirable. * It seems that the only choice left is to implement sysfs attributes to query LLDP-related attributes. Any other device with similar characteristics would probably need to re-do the same functionality independently. Is this really what we want to do? Please let me know what you think. Regards, Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
