ASTF PARSE possibility at the CP core

[jsmoon]

In ASTF, unlike the stream compilation in STL, the PRASE and BUILD works are performed at the DP cores. When the multiple dynamic profiles are used, I think these works disturb the traffic handling works in the DP cores. Especially, since the PARSE work is handled at the DP core 0 only, the load balance among DP cores may not be kept. The profiles are frequently loaded and running, I'd like to avoid this time-consuming work at the DP core. @hhaim, what do you think about the PARSE work done at the CP core?

In addition, during the BUILD work, CAstfDB::get_db_ro() is called once for the same memory socket. In my thought, it also may break the load balance among DP cores. Is there any reason to do this during the BUILD work? Is it possible to do it during the PARSE work?

[hhaim]

@jsmoon there is a reason for that. the DP cores can do very long tasks while CP is event driven and can't stuck for more than 500msec. this reason for are sending the hard work to DP0 etc.

[jsmoon]

@hhaim I'd like to avoid the hard work at DP0 too during it is TRANSMITTING state. Do you know what makes it stuck for a long time? The PARSE work performs topology and profile parsing. I think the profile parsing can be done at CP.

[hhaim]

@jsmoon for a starter the json could be huge and we didn't split the parsing so this is something that can't be done by chunk of work. We have tested huge profile to verify scale and this is the best way to achieve it. moving the work to CP is a very big rewrite of the code (to support the same scale)

[jsmoon]

@hhaim I understood about the huge profile case. Could you please look into this change? It keeps the PARSE work at DP core 0 for the first profile. i.e. when you use a single huge profile, it works the same as before. What do you think about my change?

[egwakim]

Hi @hhaim , This update would be 'big improvement' toward mobile traffic verification for 5G. Dynamic traffic simulation requires frequent multiple dynamic profiles to simulate mobile traffic behaviors, the performance bottleneck of creating new profile is 'parsing' job which is handled by single core. According to the internal test(it depends on traffic profile logic), this update can improve performance up to 5 times(500%) in multiple cores environment. If it does not breaks legacy(backward compatibility with legacy usages), can you please review it again? I think it's valuable enough to review.

[hhaim]

@egwakim @jsmoon Understood. I think you can take the change @jsmoon did and improve it even better doing it even to the first profile. However, just keep everything backward compatible. Meaning by default, all the profiles (first the second, etc.) will do PARSE as at DP0 to support scale.

You can add another field in the profile to mark it as a small/process_at_cp to improve performance. This way you can improve x5 performance for small common profile while the support of huge profile is keep

[jsmoon]

@hhaim the field in the profile is inappropriate because it can be seen after parsing. I prefer user control by the process_at_cp field in the global_cfg. I'll prepare a PR for it.

[hhaim]

@jsmoon agreed. It is even better as long as you have an RPC (new API) to change this mode