Rare project developers

[mc36 <>]

hi,
nice spot and an interesting question......
first of all, i agree with the suggestion to the state.py idea of yours...

regarding the new port_add/del message, i don't feel that it's a good idea
to even remove a port from that table, ever... okk we accidentally removed
the export-port for a while, but when re-adding it, one would expect that
the counters are back... especially the accumulated crc to name one....

anybody else have a different opinion?

ohhh, anyway, i also had an idea from the above.... we really would need an
other backward communication regarding the crc... let's say "show inter sdn1 
controller"
issued in freerouter, then freerouter could ask the dataplane for it by let's 
say
"portstats <id>", then the dataplane could tell them by
"portstats_beg <id>"
"portstats_txt <id> <text>"
"portstats_txt <id> <text>"
"portstats_txt <id> <text>"
...
"portstats_end <id>"
lemme quickly implement it in the pcap & dpdk to pilot the stuff.... :)

regards,
cs


On 3/14/22 13:53, Alexander Gall wrote:
> On Mon, 14 Mar 2022 12:02:24 +0100, mc36 <> said:
>
> > yeahhh, noticed myself too, just fixed again! :)
>
> Confirmed, thanks.
>
> Now one last thing :)
>
> Putting rare-dev back on Cc as the following might be of interest to
> others.
>
> When a Tofino port is shutdown, a "state" message is generated with
> the "adm_status" flag set to 0. The implementation in
> rare/api/state.py translates this to removing the port from the $PORT
> table, which is equivalent to the "port_del" command in UCLI. I think
> this is the wrong thing to do because this also causes the counters as
> well as the interface's rows in the ifTable/ifXTable MIBs to disappear
> as well, when all it should do is to bring down the interface.
>
> What I think should happen is that the state.py module should simply
> set the $PORT_ENABLE field to False in the interface's entry in the
> $PORT table (corresponding to the "port-dis" UCLI command). This will
> actually put the port into the "administratively down" state but leave
> the entries in the $PORT and $PORT_STAT tables intact (which, in turn
> will also keep the SNMP table entries for the port).
>
> I think a port should only be deleted from the $PORT table when the
> "export-port" stanza is deleted.
>
> Maybe something like this: instead of "state" we implement the call
> "port" that comes with all the "add", "mod", "del" flavors. "add" and
> "del" are emitted when the "export-port" stanza is added/removed. The
> "add" command can also set the initial port
> configuration. Modifications after creation are translated into
> "port_mod" messages, which include setting of the admin status.
>
> What do you think?