Hi Francois, You are welcome to submit a patch for this,
Thanks Alec From: <opnfv-tech-discuss@lists.opnfv.org> on behalf of François-Régis MENGUY <francoisregis.men...@orange.com> Date: Thursday, February 21, 2019 at 7:37 AM To: "Alec Hothan (ahothan)" <ahot...@cisco.com>, GRALL Xavier TGI/OLN <xavier.gr...@orange.com> Cc: "opnfv-tech-discuss@lists.opnfv.org" <opnfv-tech-discuss@lists.opnfv.org> Subject: Re: [opnfv-tech-discuss] #nfvbench TRex restart Hello Alec, I see much better the impact indeed by this change request. This suggestion looks good to me. I can handle it on my side if it is ok to you. Regards, Francois Regis Menguy -----Message d'origine----- De : Alec Hothan (ahothan) [mailto:ahot...@cisco.com] Envoyé : mercredi 20 février 2019 19:53 À : GRALL Xavier TGI/OLN; MENGUY Francois Regis TGI/OLN Cc : opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org> Objet : Re: #nfvbench TRex restart The detection of config changes requiring Trex restart is ideal but is a bit tricky. Let me try to describe the various ramification of such change. A nfvbench container can operate in 2 modes: cli only or cli + rest server. Most of the code is common between cli and rest, but the bootstrap is different i.e. with cli all new requests always originate from main, while for rest new requests originate from a flask server loop (nfvbenchd.py). The Trex connect/launch/connect logic is done very late (lazy init) in trex.y and will apply for both cli and rest requests (which is good). Nfvbench also supports remote Trex instances (e.g. one that is running on another server). So this restart must only happen when Trex is local. To detect if it is local, the only practical way is to look at the config and check if the ip of the trex host is "127.0.0.1" (or local host name itself to be complete). generator_profile: - name: trex-local tool: TRex ip: 127.0.0.1 The current trex config is always located in /etc/trex_cfg.yaml: # Config generated by NFVbench - port_limit : 2 version : 2 interfaces : ['0a:00.0','0a:00.1'] So a diff between old config and new config should be pretty easy to do. However, on the cli front: ./_t-rex-64 -i -c 4 --iom 0 --no-scapy-server --close-at-end --vlan --mbuf-factor 0.2 --cfg /etc/trex_cfg.yaml The one argument that can change is –vlan. The –vlan argument must be passed when using Intel X520 NIC and if VLAN encaps is used. So if a next nfvbench run does not use vlan, we need to restart Trex (or vice versa - this hack is only needed for X520 unfortunately). To handle that corner case (user has X520 NIC and toggles from vlan to non vlan between runs), I think we will need a new nfvbench option to force Trex restart and by default only restart Trex if the trex config is not identical and trex is started locally. I think best way to restart Trex is to connect to it and issue a release + shutdown call. This will be a lot safer than killing the process (as you could end up with stranded ports that will require a container restart or a server restart). The Trex STLClient python api to release ports and shutdown the server: def server_shutdown (self, force = False): """ Sends the server a request for total shutdown :parameters: force - shutdown server even if some ports are owned by another user :raises: + :exc:`STLError` """ def release (self, ports = None): """ Release ports :parameters: ports : list Ports on which to execute the command :raises: + :exc:`STLError` """ Let me know if the above suggestion makes sense, Thanks Alec From: "xavier.gr...@orange.com<mailto:xavier.gr...@orange.com>" <xavier.gr...@orange.com<mailto:xavier.gr...@orange.com>> Date: Wednesday, February 20, 2019 at 1:21 AM To: MENGUY Francois Regis TGI/OLN <francoisregis.men...@orange.com<mailto:francoisregis.men...@orange.com>>, "Alec Hothan (ahothan)" <ahot...@cisco.com<mailto:ahot...@cisco.com>> Subject: RE: #nfvbench TRex restart Hi, I agree with Francois that the short additional delay to start TRex for each run is not a matter, but imho the best solution would be to restart TRex only when detecting any change in its configuration (rather than providing the possibility to restart or not on demand, especially if the coding effort is the same or bigger). De : MENGUY Francois Regis TGI/OLN Envoyé : mercredi 20 février 2019 10:12 À : Alec Hothan (ahothan) Cc : GRALL Xavier TGI/OLN Objet : RE: #nfvbench TRex restart Hello, I don’t know if stopping TRex each run has an impact on the way NFVBench is used by most users. For us, yes this solution is good enough. Personally, having the possibility to do it on demand is also a good practice. As we have the reuse of ports and networks with NFVBench we can also provide a reuse of TRex if the configuration is equivalent to previous run. If it is not the case and we use a local TRex we can restart it. So we have multiple ways to do it : • CLI • API • Check generator config on each run One use case is Jenkins job calling NFVBench API for multiple tests scenarios with different generator profiles. Regards, Francois Regis Menguy mailto:francoisregis.men...@orange.com De : Alec Hothan (ahothan) [mailto:ahot...@cisco.com] Envoyé : mardi 19 février 2019 19:22 À : MENGUY Francois Regis TGI/OLN Cc : GRALL Xavier TGI/OLN Objet : Re: #nfvbench TRex restart Hi Francois, The current code will keep Trex process around until the container is restarted. There has been requests to be able to restart TRex under various conditions for various reasons – including the one you mention below. I was also very close to allow Trex to be stopped at the end of every run. The only downside is the extra few seconds (5-10 sec) needed to restart TRex every time which I think in the scale of things is relatively small annoyance. Will that radical solution fit your needs? Thanks, Alec From: "francoisregis.men...@orange.com<mailto:francoisregis.men...@orange.com>" <francoisregis.men...@orange.com<mailto:francoisregis.men...@orange.com>> Date: Tuesday, February 19, 2019 at 9:13 AM To: "Alec Hothan (ahothan)" <ahot...@cisco.com<mailto:ahot...@cisco.com>> Cc: GRALL Xavier TGI/OLN <xavier.gr...@orange.com<mailto:xavier.gr...@orange.com>> Subject: #nfvbench TRex restart Hello Alec, We are wondering if NFVBench is able to restart TRex subprocess on-the-fly. For my view of NFVBench code it seems not possible. I am right ? With our test scenarios we had the case to switch generator profile configuration (such as interfaces, CPU, memory …) and each time we need to restart docker process. It will be helpful for us to have the possibility to restart TRex outside NFVBench and even more outside docker through web API. If it is ok for you I can develop an API call to restart TRex process and take account new configuration. Regards, Francois Regis Menguy mailto:francoisregis.men...@orange.com _________________________________________________________________________________________________________________________ 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. _________________________________________________________________________________________________________________________ _________________________________________________________________________________________________________________________ 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 (#22842): https://lists.opnfv.org/g/opnfv-tech-discuss/message/22842 Mute This Topic: https://lists.opnfv.org/mt/29943793/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] -=-=-=-=-=-=-=-=-=-=-=-
