Re: Large MIB table - do not want cache or copy

OK, I finally figured it out on my own. I'll post my findings here
for reference by my future self (who will undoubtedly forget) and
anyone else it might aid.

---

Using mib2c.raw-table.conf for a large table you have ordered access
to but don't want copied or cached into memory.
--------------------------------------------------------------------

- I didn't need to handle row create/remove, so I have no notes on
   that (sorry).

- The 'indexes' param to the get/getnext routines works like this:

     > Your table index is handed over in the 'indexes->val' union,
       and size in 'indexes->val_len'. Suppose your defined table
       index is an OCTET STRING of size 6 (MAC address). Then
       'indexes->val_len' should be 6 and 'indexes->val.string' array
       has your requested index.

     > If your defined table has multiple indexes, then the second one
       will be in 'indexes->next_variable' and so on.

   (the rest is for getnext only:)

     > If a table walk is happening, no index is passed and
       'indexes->val_len' will be 0. This means retrieve the first
       row. Once you do, be sure to set 'indexes->val_len' to the
       right size and populate 'indexes->val' with the index of the
       retrieved row (if there was one retrieved). You'll need to do
       that for any row retrieved (not just the first).

     > You do not need to worry about memory storage for
       'indexes->val'. Those members are pre-loaded to point to the
       'buf' array in indexes.  That array is 40 bytes. If your index
       is larger than that...  I'm not sure what you do.

- Once you've retrieved your row data, you need to allocate the
   struct the stub code defined for you (something like
   'myFooTable_entry') with:

       row = SNMP_MALLOC_STRUCT(myFooTable_entry);
       netsnmp_assert(row);

   Fill that in with your retrieved data and return the 'row' pointer
   (or NULL if no row could be retrieved).

- There are 2 important changes to the "_handler" function:

     > You need to
           SNMP_FREE(table_entry);
       after each
           switch(table_info->colnum)
       statement. Otherwise you'll leak memory.

     > In the MODE_GETNEXT case, the stub code sets error
       SNMP_NOSUCHINSTANCE if there was no 'table_entry' returned.
       This is apparently wrong. I had to change this to set error
       SNMP_ENDOFMIBVIEW for all columns.

---------

On 12/15/2015 09:44 AM, Joe Lorenz wrote:
> I'm trying to implement a MIB defining a very large (read-only) table
> (~250k rows).
> My data source API already provides get/get-next in correct order and
> data format. I expected it to be straightforward to map the appropriate
> handler actions, but I'm struggling with the details.
>
> It seemed like mib2c.raw-table.conf would be the right way to go,
> avoiding any caching or copying of the entire set of table data (which
> is a requirement). What I've been unable to find is any actual example
> that uses this mib2c config. I'm lost on what needs to be done with the
> various structures (indexes, etc.) especially for the get-next.
>
> The table is read-only. I have no need to implement row add/remove.
> I'm using version 5.7.2.1 of the software collection.
>
> If anyone can point me to an example or otherwise provide some hints,
> that would be most helpful.
>
> Many thanks,
>      -Joe

------------------------------------------------------------------------------
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users