Hello Alec, I’ve committed my work on TRex parameters tuning. Please let me know if you have any question and if you want me to add documentation in the RST files.
I added also some response inline ☺ Regards, Francois Regis Menguy francoisregis.men...@orange.com<mailto:francoisregis.men...@orange.com> De : Alec Hothan (ahothan) [mailto:ahot...@cisco.com] Envoyé : vendredi 18 janvier 2019 16:32 À : MENGUY Francois Regis TGI/OLN Cc : opnfv-tech-discuss@lists.opnfv.org Objet : Re: [opnfv-tech-discuss] #nfvbench Add TRex parameters to tune performance and allocate ressources Inline… From: "francoisregis.men...@orange.com<mailto:francoisregis.men...@orange.com>" <francoisregis.men...@orange.com<mailto:francoisregis.men...@orange.com>> Date: Tuesday, January 15, 2019 at 1:24 AM To: "Alec Hothan (ahothan)" <ahot...@cisco.com<mailto:ahot...@cisco.com>> Cc: "opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>" <opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>> Subject: RE: [opnfv-tech-discuss] #nfvbench Add TRex parameters to tune performance and allocate ressources In fact we had the case with a shared platform during NFVBench tool testing. Ressources such as huge page were completely used by one TRex instance, we were unable to start other NFVBench instance on same compute node. [alec] Yes that is correct, I believe this is actually a behavior if the DPDK library used by Trex. The only workaround I know of is to artificially limit the number of huge pages available on the box before starting Trex. [françois] limit_memory property permit to limit huge pages consumption by TRex process So possible use cases : - Operation: measurement with simultaneous background traffic - Dev: multiple simultaneous tests for dev or config tuning purposes In addition, even if we were on docker container, NFVBench process connect to first TRex process even if it is in another docker container, so localhost IP is not efficient to prevent connecting to another TRex instance from another previous NFVBench process. [alec] This might be because you start your container in network host mode (--net=host), can you try to start in the default bridge mode (just remove –net=host) [françois] I have try without this docker property but still the issue I will test with cgroups if I reproduced the case. Our test on huge pages and platform parameters configuration for TRex subprocess were OK on our side without impact on global server configuration as far as I can see. [alec] Cool! [françois] I was not able to use correctly cgroups for our use cases. Only my work on TRex properties working as expected for me. BR, Alec Regards, Francois Regis Menguy francoisregis.men...@orange.com<mailto:francoisregis.men...@orange.com> De : Alec Hothan (ahothan) [mailto:ahot...@cisco.com] Envoyé : samedi 12 janvier 2019 18:53 À : MENGUY Francois Regis TGI/OLN Cc : opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org> Objet : Re: [opnfv-tech-discuss] #nfvbench Add TRex parameters to tune performance and allocate ressources That is an interesting use case although we need to make clear that running multiple instances on the same server will likely not provide linear performance increase. Can you provide more information about your concurrency target? I.e. how many instances are you planning to run and on what hardware resources (RAM, cores, NIC)? Regarding resource partitioning easiest would be to take advantage of containerization (cgroups) with the goal of being able to run multiple instances of the nfvbench container (each running the nfvbench orchestration and 1 instance of trex). This should take care of the nfvbench to trex communication which stays internal to each container instance (the 127.0.0.1 subnet is specific to each container instance - so no need to have different zmq ports as they will run on distinct subnets - to be confirmed) The externally visible resources across container instances would still need to be solved through container parameters: • Nfvbench REST service port - already supported (if used) • Trex NIC and ports selection – already supported in nfvbench config • Huge pages configuration in Trex might require some tweaking and impact the server overall huge page configuration • Platform latency and master thread id, socket and threads - we will need to check with the trex team how to work out core partitioning across containers Thanks Alec _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22805): https://lists.opnfv.org/g/opnfv-tech-discuss/message/22805 Mute This Topic: https://lists.opnfv.org/mt/29007935/21656 Mute #nfvbench: https://lists.opnfv.org/mk?hashtag=nfvbench&subid=2783016 Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
