Inline… From: "[email protected]" <[email protected]> Date: Tuesday, January 15, 2019 at 1:24 AM To: "Alec Hothan (ahothan)" <[email protected]> Cc: "[email protected]" <[email protected]> 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. 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) 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! BR, Alec Regards, Francois Regis Menguy [email protected]<mailto:[email protected]> De : Alec Hothan (ahothan) [mailto:[email protected]] Envoyé : samedi 12 janvier 2019 18:53 À : MENGUY Francois Regis TGI/OLN Cc : [email protected] 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22667): https://lists.opnfv.org/g/opnfv-tech-discuss/message/22667 Mute This Topic: https://lists.opnfv.org/mt/29007935/21656 Mute #nfvbench: https://lists.opnfv.org/mk?hashtag=nfvbench&subid=2783016 Group Owner: [email protected] Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
