Rare project developers

[Alexander Gall <>]

On Tue, 15 Mar 2022 15:17:04 +0100 (CET), Fréderic LOUI 
<> said:

> Hi,
> Sorry for jumping a bit late. (I was somewhat unplugged due to a failing 
> laptop... :-( )

> Anyway, "mieux vaut tard que jamais":

>> anybody else have a different opinion?

> I agree the fact that it would be preferrable to keep counter and have the 
> interface DISABLED.
> The only suggestion I have is to report this behaviour to bundle and 
> respective memebrs.
> Not sure if it was always the case SDE propose a specific way to deal with 
> members and you'd have to use this mechanism.

> If i'm not mistaken, when we were working with bundle, the choice was to 
> consider interface member change as deletion and re-creation.
> (in that case we would lose related counters)

> Maybe you already handle bundle case as expected by INTEL/BAREFOOT in your 
> packet broker code @Alex ?

Yes. If the oper status of a port changes, one has to set the
$ACTIOM_MEMBER_STATUS field in the port group selector table
accordingly (to have it excluded or included in the hash calculation).

I don't quite understand yet how bundles are handled by freerouter and
bf_forwarder, TBH.

-- 
Alex

> Frederic

> ----- Mail original -----
> De: "cs" <>
> À: "rare-dev" <>, "gall" <>
> Envoyé: Lundi 14 Mars 2022 17:11:01
> Objet: Re: [rare-dev] Exception when deleting a subinterface in p4lang

> hi,

> On 3/14/22 17:00, Alexander Gall wrote:
>> 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.
>> 
> when one no export-port something, a state <id> 0 issued...


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

> when such a config requested from freerouter, it issues 2 state messages 
> for now....
> tight now, the state message have this format: state id 0/1 speed etc....

> okkk, got the point... i'll add the new message then....

> but since the state message will only have to deal with the (no)shutdown 
> state finally,
> what if we move all the parameters from it to the new message?
> i mean the following:
> state id 0/1 --- just to indicate the shutdown state
> ports_add/del/mod id speed etc --- to indicate the port config change

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

> it's a completely different idea i just got while i discussed with you the 
> above.... :)

> thanks,
> cs