Rare project developers

[Alexander Gall <>]

Hi

On Mon, 14 Mar 2022 14:56:09 +0100, mc36 <> said:

> 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....

I don't think it's a bad thing to remove a port from the list of
active ports if it's not referenced by an export-port clause. For one
thing, it will make sure that the port is shut down, which I would
expect as a user. If we don't remove the port once the export clause
goes away, I guess we would still have to generate a message that
issues a shutdown (even if there is a "no shutdown" in the interface
config). Removing the port would make that a non-brainer.

Also, for some configuration changes it is actually necessary to
remove the port. For example, let's assume we have ports 1/0 and 1/1
configured as 10G. Then we want to replace it by 1/0 configured as
100G.  This requires that 1/1 needs to be removed first since the 100G
config uses all 4 lanes.

> 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"

I don't understand how this relates to the issue above. Can you please
explain?

-- 
Alex

> 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?
>>