On 13:42 Mon 31 Aug , Hal Rosenstock wrote:
Wouldn't endlid be set to top for this case (since top endlid) ? It
ignores endlid and not top in this case.
Ok, it is clear for me now (sorry, it took a long time :)). Thanks for
the explanations.
Sasha
On 12:35 Sun 30 Aug , Hal Rosenstock wrote:
Doesn't the loop:
for (block = startblock; block = lastblock; block++)
terminates without any blocks read ? So it shows no entries.
Sorry, I still don't understand. Let's suppose that top = 0xbfff,
cap = 1024, startlid = 0xc000, endlid = 0xc030
On 8/31/09, Sasha Khapyorsky sas...@voltaire.com wrote:
On 12:35 Sun 30 Aug , Hal Rosenstock wrote:
Doesn't the loop:
for (block = startblock; block = lastblock; block++)
terminates without any blocks read ? So it shows no entries.
Sorry, I still don't understand. Let's suppose
On 10:03 Wed 26 Aug , Hal Rosenstock wrote:
Add support for SwitchInfo:MulticastFDBTop
Added by MgtWG errata #4505-4508 and #4640
If MulticastFDBTop is set to other than 0, only fetch MulticastForwardingTable
blocks up through MulticastFDBTop rather than MulticastFDBCap
If
On 08:42 Sun 30 Aug , Hal Rosenstock wrote:
This is handled by the block loop inside of dump_multicast_tables.
Where? I don't see this. Should not it to show nothing (no entries)
when top = 0xbfff and dump_all is not set?
Sasha
___
general
On 8/30/09, Sasha Khapyorsky sas...@voltaire.com wrote:
On 08:42 Sun 30 Aug , Hal Rosenstock wrote:
This is handled by the block loop inside of dump_multicast_tables.
Where? I don't see this. Should not it to show nothing (no entries)
when top = 0xbfff and dump_all is not set?
