On Tue, Mar 10, 2009 at 4:23 PM, James Carlson <[email protected]> wrote:
> Jason King writes:
>> On Tue, Mar 10, 2009 at 3:31 PM, James Carlson <[email protected]>
>> wrote:
>> > Or do you have a single LLP daemon that supports multiple instances?
>> > If that's the case, then you might want to look into making each of
>> > the instances be a separate SMF instance anyway: it makes for simpler
>> > administrative control.
>>
>>
>> It's a single-instance daemon that sends/receives on multiple links.
>
> OK; that's actually quite similar to bridging.
>
>> It sounds like this could be simplified down to one added subcommand for
>> dladm:
>>
>> Putting the per-link data under {get,set}-linkprop (with interfaces in
>> libdladm to manipulate) -- actual data resides in a per link property
>> group in SMF, global data only in SMF in a separate property group.
>> The 'show-discovery-config' subcommand can be eliminated.
>
> Actually, I found it much simpler just to use the regular link
> property storage mechanism rather than to try to force per-link data
> into SMF.
Ahh I had forgotten about that, that would probably be simpler.
>
> The only things I have in SMF are the things you're implementing as
> globals.
>
>> The {start,stop}-discovery subcommands could be eliminated -- enabling
>> LLDP tx or rx on any interface implicitly enables the service (I
>> believe share(1m) does something like this). It can still be turned
>> on/off via svcadm {enable,disable} of course.
>
> That makes sense to me.
One other thing would be that a separate client library could also go
away since all the action is happening in libdladm
>
>> Per link stats can be viewed via the show-link -s (or if dlstat
>> integrates, can be moved to that), removing 'show-discovery-stats'.
>>
>> That would leave the actual LLDP data ('show-discovery' -- though I'm
>> really thinking 'show-neighbo[u]rs' might be better -- seems to better
>> match switch nomenclature).
>
> It seems we're going to get "dlstat" soonish to take over these
> functions. (Unfortunately, it looks like this proposal, though it's a
> good idea, was discussed somewhere off-list, and hasn't been ARC'd
> yet, so it's a bit of a surprise ...)
Since the number of stats are small (7 32-bit counters per link) and
otherwise pretty straightforward, I'd be surprised if there were any
issues to fold these into that.
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
