[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FW: [802.1] MSTP MIB - mstpMapTable



> > What you say is true for atomic data, but in this particular case, the
> > data is an array of 4096 separate pieces of information.  In other
> > words, this is not a case of "splitting the value into smaller pieces",
> > but rather it's a case of combining many values into a small number
> > of medium-sized aggegates instead of into a single large aggregate.
> 
> The issue is whether you need atomic access to data and the
> implications of a lack of atomic access build into a MIB module. I
> don't care whether the data you need to access is stored under a
> single OID or a collection of OIDs and this is why I am saying that
> looking at the size of a single object likely misses the point when it
> comes down to semantically meaningful management operations.
 
Your issue seems to be concerned with the size of the PDU (rather
than of the object), i.e., you seem to be saying that bigger PDUs are
needed.  In fact, if you're saying that the size of the PDU needs to be
large enough to contain all the data the application wants to obtain
atomically, then that's impractical: a) the "all the data" could be
Gigabytes, and b) a device would have to disable interrupts while
constructing the PDU in order to guarantee atomicity.

Keith.