Rare project developers

[mc36 <>]

hi,

thanks for the quick response... i reply topic by topic...

crc:
just a small footnote that i refactored them again to get back the original 
speeds...
the trick there was that it was a static final table that is, it was common 
for all the
classes, so it was computed only once... now it's true again...:)
not that much happened, just the class instantination parameter changed...

sympy:
after a quick look, it seems to me a huuuge (33mb) symbolic math package...
but in guess you're only using a small subset of that... at least from the 
paper,
my bet is that you only need a class that represents a polynomial, and the
add, sub, div, mul functions over it (as i shown for ellitic curves during 
the vc)
so if that's the case, i would suggest you that simply give me some time and
let me come up with something that can calculate only these over a poly 
class...
if you could shar your current python code could help me to see what you need 
from sympy...
i really love doing such things because it refreshes a bit the things i learnt
during the university classes, and i really like explore and understand 
things...
finally, calling out to external libs are always costy because of the
java-ish overhead that is put by the non-specific libs, and when you
have an unstable network and you have to recompute frequently then it
pays off to have everything in hand that you can fully optimize...
snoopy.vhpc#show platform | include uptime
uptime: since 2021-10-16 10:00:37, for 3d18h
snoopy.vhpc#show ipv4 bgp 1955 bestpath | include change
changes all      15784774
changes now      37
snoopy.vhpc#
it's the worst example i have for the above, it averages to 45 changes / 
second...

reusing segment routing id from routing protocols:
so at the moment it's the quickest way i see to fit the need to populate an 
id->prefix
and prefix->id table on each node in a network... also keep in mind that 
freerouter have
homebrew routing protocols too (http://lsrp.nop.hu/ and 
http://pvrp.nop.hu/)... so if we
need a new value somehow, it can arrive in no time to continue 
experimenting...
but in a longer run, you should consider ietf rfcs to have specific values 
just for polka...

thanks,
cs







On 10/20/21 03:00, Cristina Klippel Dominicini wrote:
> Hi, Csaba,
>
> Thank you very much for this quick response!
>
> Yes! The bmv2 implementation explores predefined tables (code below) for 
> well-known CRC standards and builds the tables for custom polynomials.
> https://github.com/p4lang/behavioral-model/blob/main/src/bm_sim/crc_tables.h
> Their solution was inspired by this code that offers a nice introduction to 
> the CRC calculation: 
> https://barrgroup.com/Embedded-Systems/How-To/CRC-Calculation-C-Code
>
> Your new code seems to fit our requirements perfectly. We will execute some 
> tests with default parameters to double check.
>
> We used CRC16, because the lower the polynomial degree, the better in terms 
> of the bitlength of the routeid. In theory, we could use lower polynomials 
> for small topologies, but we got some errors with CRC8 in our initial tests 
> in Tofino. We will check if we can use CRC8 in Tofino.
>
> Now, we are going to translate our code to provide you with a Java method 
> that performs the routeID computation given the path information (set of the 
> nodeIDs and portIDs). Most of our polynomial computation uses the galoisfield 
> module of the sympy lib 
> (https://docs.sympy.org/latest/modules/polys/index.html). So, I will check if 
> there is a similar library in Java. For the nodeid computation, it is just a 
> matter of calculating a list of irreducible polynomials, so it should suffice 
> to have a fixed list of nodeids for the control plane.
>
> Finally, your suggestion to use BGP/IGP for node discovery and reuse the 
> Segment Routing identifiers seems to be a very elegant solution. We will 
> study that. Thank you!
>
> Best regards,
> Cristina
>
> ________________________________________
> De: mc36 <>
> Enviado: terça-feira, 19 de outubro de 2021 17:21
> Para: Cristina Klippel Dominicini; Cristina Klippel Dominicini; Rafael S. 
> Guimaraes; Rafael S. Guimarães
> Cc: 
> Assunto: Re: custom crc32 library in freerouter
>
> hi,
> sorry for the spam again, but i checked again the polka.patch and found that 
> maybe you're using crc16?
> so here we go, i also parameterized it in freertr: 
> http://src.mchome.nop.hu/src/net/freertr/cry/cryHashCrc16.java
> with this: 
> https://github.com/mc36/freeRouter/commit/4958add8b8fc48f1a35199f6e57deeb5dfe768ac
> i'm never against some good refactoring, afterall... :)
> also, you really should check the last but one vc, we demoed how 
> segment-routing traffic engineering can work...
> that is my intent to reach to that same level with polka, with abusing the 
> already existing igp's and/or bgp's
> segrout.index flooding mechanisms... here is the video: 
> https://www.youtube.com/watch?v=jS6RmHKC4aQ
> regards,
> cs
>
>
> On 10/19/21 21:31, mc36 wrote:
> > hi,
> > sorry for the spam...
> > so i played a bit with my crc32 library and found out that i can calculate 
> > the same values with a single class,
> > just some parameters need to be passed to it become the "ieee ethernet" or the 
> > "sctp rfc" version of the crc code...
> > here is what freertr have now at the moment: 
> > http://sources.nop.hu/src/net/freertr/cry/cryHashCrc32.java
> > (my bad, the url was bad in the previous mail...:) and this is what happened 
> > in the code to reach the single class:
> > https://github.com/mc36/freeRouter/commit/ca58d4fe39f0cd681d6cd21d3a9a2474e07600a8
> > if you still need a parameter or anything around the crypto lib, just let me 
> > know...
> > but hopefully now, it'll be easy for you to come up with the rest, that is:
> >   Â - a method to encode the polka.routeid from "List<Integer> nodes"...
> >   Â - a method to calculate the coefficient (polynominal?) from a single 
> > node id...
> > then we can finally have a pure java forwarder and so on, as we discussed in 
> > the vc...
> > thanks,
> > cs
> >
> >
> >
> > On 10/19/21 17:34, mc36 wrote:
> > > hi
> > >
> > > i've found the crc32_custom magic in bmv2:
> > >
> > > behavioral-model-main/src/bm_sim/crc_map.cpp
> > > behavioral-model-main/src/bm_sim/calculations.cpp
> > >
> > > in the crc_map.cpp for crc32c, they uses the same magic as me at 
> > > http://source.nop.hu/src/net/freertr/cry/cryHashCrc32c.java
> > > and the table calculation in calculations.cpp seems similar that i do too, 
> > > but mine works with fixed magic...
> > >
> > > but they have no parameter called coefficiet, but the magic called 
> > > polynomial...
> > >
> > > my best guess according to 
> > > https://en.wikipedia.org/wiki/Cyclic_redundancy_check is that they're the 
> > > same?
> > > (but again, it's my bad but i'm a bit noob in these math things, i'm much 
> > > more a networker and coder guy:)
> > >
> > > so if that's the case then i'll create a new crc32 class that needs to be 
> > > initialized with the poly paramareter...
> > >
> > > thanks,
> > >
> > > cs
>
>
> ________________________________
>
> Esta mensagem (incluindo anexos) contém informação confidencial destinada 
> a um usuário específico e seu conteúdo é protegido por lei. Se você não 
> é o destinatário correto deve apagar esta mensagem.
>
> O emitente desta mensagem é responsável por seu conteúdo e endereçamento.
> Cabe ao destinatário cuidar quanto ao tratamento adequado. A divulgação, 
> reprodução e/ou distribuição sem a devida autorização ou qualquer outra 
> ação sem conformidade com as normas internas do Ifes são proibidas e 
> passíveis de sanção disciplinar, cível e criminal.