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: "[email protected]" <[email protected]>
Date: Wednesday, February 20, 2019 at 1:21 AM
To: MENGUY Francois Regis TGI/OLN <[email protected]>, "Alec
Hothan (ahothan)" <[email protected]>
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:[email protected]
De : Alec Hothan (ahothan) [mailto:[email protected]]
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: "[email protected]" <[email protected]>
Date: Tuesday, February 19, 2019 at 9:13 AM
To: "Alec Hothan (ahothan)" <[email protected]>
Cc: GRALL Xavier TGI/OLN <[email protected]>
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:[email protected]
_________________________________________________________________________________________________________________________
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 (#22824):
https://lists.opnfv.org/g/opnfv-tech-discuss/message/22824
Mute This Topic: https://lists.opnfv.org/mt/29943793/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]]
-=-=-=-=-=-=-=-=-=-=-=-
