Re: [PATCH 0/2] Display adjacent switch port's attributes

[Stefan Raspl <raspl@linux.vnet.ibm.com>]

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?

Stefan