Rare project developers

[Alexander Gall <>]

Hi

On Tue, 12 Jul 2022 11:04:56 +0200, mc36 <> said:

> On 7/12/22 10:45, Alexander Gall wrote:
>> Hi
>> 
>> On Tue, 5 Jul 2022 19:28:51 +0200, mc36 <> said:
>> 
>>> so as nobody likes the magic numbers, and we already have a handshake in 
>>> between the dataplane and the control plane,
>>> i got the idea that what if the bffwd would tell freerouter all the 
>>> remaining mapping of the export-port parameters,
>>> like fec, autoneg and flwctrl? then the netadmin would be able to use the 
>>> names much like it's already happening with
>>> the front-panel port names?
>> 
>> Appreciated :) What would be even better is if the config would show
>> the names instead of the translated numbers, e.g. from you example
>> 
>> sid(cfg-server)#show running-config this
>> server p4lang p4
>> export-port sdn1 sdn1 frontpanel-1/1 10 rs off auto
>> 
> so the thing is with this, is that when the startup config is parsed,
> the dataplane is not connected yet...

But the configuration is also ignored as long as the dataplane is not
connected.  It only takes effect once it is and at that point the
translation is known. So it actually seems natural that the
translation is done when the configuration is applied instead of when
it's parsed.

> the other thing is when you swap
> the dataplanes: we have dpdk, pcap, xdp, all interchangeable both in
> parameters, and so on... but they have different namings for the
> interfaces, at least...

I don't understand this argument. The p4lang section is specific to
the p4 dataplane, isn't it?

>> 
>> While you're at it, why not extend the mechanism to the other export
>> properties like VRFs?  It should not be up to the user to pick the
>> number that represents a VRF in a P4 table.
>> 
> this one is a good idea, i'll play around this a bit...

>> Ideally I would like to see the entire "server p4lang" section gone,
>> at least as a user-servicable config. I guess the export-port
>> functionality could remain there as an exception (once only the
>> symbolic names are shown :) I think I've mentioned before that the
>> mechanism used by IOS-XR (i.e. "interface preconfigure", "controller
>> Optics...") is pretty clever. Maybe something to work towards in the
>> future?

> this is not a thing to consider for now... once we'll have the vc about 
> stacking
> (probably today) it'll show the necessity of all these... so for example 
> one can
> export only parts of their configs to a given dataplane: i have 3 openwrt 
> aps,
> running the ebpf/xdp dataplane...

Sorry, I didn't follow the whole stacking thing, so can't comment
about this specifically.  I'm just worried that this complexity will
cause serious problems for users. People are already pretty confused
about the entire export-* stuff for p4, which is why we try to make
this more automatic. It seems to me that we should have some kind of
unified "parameter negotiation" between the various dataplanes and
freerouter to remove the burden on the user as much as possible and
make the configuration more uniform across dataplanes.

>> 
>>> here is the small change implementing the above:
>>> https://github.com/rare-freertr/freeRtr/csdn1 frontpanel-1/1 10 rs off 
>>> autoommit/7ffaa39864c0eb54fa546bb630337fab5dc60d7c
>>> the drawback of this commit is the additional complexity in case of 
>>> gearboxed switches like the
>>> bf2556tx where these magics need to be translated to the gearbox values 
>>> in case of gearbox ports...
>>> ps: alex, as you're the only one access to a tofino2, could you please 
>>> verify if these are the right values on 400g too?
>> 
>> Actually, the values are our own invention :/ BFRT uses strings like
>> 'BF_FEC_TYP_FC' or 'BF_SPEED_200G'. They are defined here: 
>> https://bitbucket.software.geant.org/projects/RARE/repos/rare/browse/bfrt_python/rare/bf_gbl_env/cst_env.py
>> and the translation is here: 
>> https://bitbucket.software.geant.org/projects/RARE/repos/rare/browse/bfrt_python/rare/bf_rt_rare/get_str_fec.py
>> 
> yeahhh, that was the source i used.....

>> Tofino2 uses the same names, so should not be a problem, except that
>> there are obviously more speed settings.
>> 
> sounds cool....

>> In fact, your change basically makes the numbers obsolete. For
>> example, the forwarder now tells freerouter that it should use 3 for
>> RS FEC and the user can enter it as "rs". Freerouter then translates
>> "rs" to 3 and sends that to freerouter, which immediately translates
>> it to "BF_FEC_TYP_RS". We could simply omit the numbers now and only
>> use the names.
>> 
> from freerouter's point of view, nothing changed... it always used the
> numbers, and should do so.... let's keep the complexity there and not
> in the forwarder...

Well, now it knows the numbers *and* the symbolic names, it just
choses to forget the names after parsing. The numbers are arbitrary
tokens and there is a 1-1 correspondence between them and the
names. We could use the names themselves as the tokens as long as they
are all distinct. I don't see any complexity there.

>> BTW, there is no "auto" FEC. It's either none, rs or fc. The value 0,
>> which is called "auto" is simply mapped to none. We should get rid of
>> it.
>> 
> tofino accepts that value too... maybe it have a different behavior?

Hm, where does it accept that value exactly? The forwarder uses the
$FEC entry in the $PORT table and that only takes these arguments
(srings, not numbers):

  'BF_FEC_TYP_NONE'
  'BF_FEC_TYP_FIRECODE'
  'BF_FEC_TYP_REED_SOLOMON'
  'BF_FEC_TYP_FC'
  'BF_FEC_TYP_RS'

-- 
Alex