[Suggestion] General trex plugins in server side

[egwakim]

There is plugin feature in trex-console side, but, there is no plugins support in trex server side.
I think it'll be easy way to cover general features like tunneling.
https://trex-tgn.cisco.com/youtrack/issue/trex-482

If we do not support dynamic unload plugins, just enabling DPDK Rx/Tx callback and load shared libraries will be enough to support this feature.

For example.

1. In TRex server
   1.1. enable RXTX callback in DPDK library config
   #define RTE_ETHDEV_RXTX_CALLBACKS 1

1.2. Load shared library after device started to be able to use rte_eth_add_tx_callback() API.
device_start();

• load_plugins();
  dump_config(stdout);

void load_plugins( void ) {
dlopen(trex/plugins/*.so);
...

2. In shared library
   Use rte_eth_add_tx_callback() API in constructor function in library.
   It'll be called when dlopen() called in TRex.
   attribute((constructor)) init_func(void)
   {
   rte_eth_add_tx_callback(port_id, queue_id, my_tunnel_func, NULL);
   }
   Copy generated .so to trex/plugins

How about your opinion on this approach?

Best Regards
Gwangmoon

[hhaim]

The tunneling feature is a perfect candidate for plugins.
The main problem is not to have it as a shared object or not.
The problem in implementing such a feature is to define the API and a layer of configuration etc.

[egwakim]

Yes, API layer will be needed.
I think general 'tunnel or plugin' command will be needed.

1. make general tunnel(or plugin) command.
2. In tunnel command, call callback function with 'args' in tunnel command function.
3. make external interface to register callback function for tunnel.

Here is Pseudo RPC command table.

Usage	RPC command	Description
trex>tunnel control -t GTPUv1 args=“add teid=1000, inner-ip=…” trex>tunnel -t GTPUv1 args=“delete teid=1000, inner-ip=…”	{ "method" : "tunnel" "params" : { “name" : “GTPUv1", “cmd” : “control”, “args” : “add teid=1000, inner-ip=…” }	Control tunnel of ‘GTPUv1’.
trex>tunnel status	{“method” : “tunnel” “params” : { “cmd” : “status” } }	Show current tunnel plugin status “Not loaded” or “Loaded ‘GTPUv1’ ....”

Here is Pseudo code

trex_tunnel.h
/* interface to external plugin */
int register_tunnel( char name, int (tunnel_control)(String));

trex_rpc_cmds_common.cpp
TREX_RPC_CMD(TrexRpcCmdTunnel, "tunnel");

trex_rpc_cmd_rc_e
TrexRpcCmdTunnel::_run(const Json::Value &params, Json::Value &result) {
string name = parse_string(params, "name", result);
string args = parse_string(params, "args", result);
(*)(String) tunnel_control = NULL;

if ( (tunnel_control = lookup_tunnel(name)) != NULL )
{
    return tunnel_control(args);
}

return (TREX_RPC_CMD_OK);

}
m_cmds.push_back(new TrexRpcCmdTunnel(this));

[hhaim]

I think it is more complicated than that. Do you want to work on that?

…

On Tue, Mar 19, 2019 at 7:26 AM Gwangmoon Kim ***@***.***> wrote: Yes, API layer will be needed. I think general 'tunnel or plugin' command will be needed. 1. make general tunnel(or plugin) command. 2. In tunnel command, call callback function with 'args' in tunnel command function. 3. make external interface to register callback function for tunnel. Here is Pseudo RPC command table. Usage RPC command Description trex>tunnel control -t GTPUv1 args=“add teid=1000, inner-ip=…” trex>tunnel -t GTPUv1 args=“delete teid=1000, inner-ip=…” { "method" : "tunnel" "params" : { “name" : “GTPUv1", “cmd” : “control”, “args” : “add teid=1000, inner-ip=…” } Control tunnel of ‘GTPUv1’. trex>tunnel status {“method” : “tunnel” “params” : { “cmd” : “status” } } Show current tunnel plugin status “Not loaded” or “Loaded ‘GTPUv1’ ....” Here is Pseudo code trex_tunnel.h /* interface to external plugin */ int register_tunnel( char *name, int (tunnel_control*)(String)); trex_rpc_cmds_common.cpp TREX_RPC_CMD(TrexRpcCmdTunnel, "tunnel"); trex_rpc_cmd_rc_e TrexRpcCmdTunnel::_run(const Json::Value &params, Json::Value &result) { string name = parse_string(params, "name", result); string args = parse_string(params, "args", result); (*)(String) tunnel_control = NULL; if ( (tunnel_control = lookup_tunnel(name)) != NULL ) { return tunnel_control(args); } return (TREX_RPC_CMD_OK); } m_cmds.push_back(new TrexRpcCmdTunnel(this)); — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#207 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMbjvVbuc1CIzTJcrdIXpNcPy125MMXIks5vYHUhgaJpZM4b5F5R> .

-- Hanoh Sent from my iPhone

[egwakim]

Not decided yet. I'm checking feasibility of it.
Do you have plan to do it(trex-482)?

[hhaim]

Not yet, I think there is a backlog of multi-profile support for ASTF and STL let's finish that and then look into more advance features.
I'm working on server side L2 scalable emulations, like IPv6 ND/MLDv2/ARP/IGMP so it would be easier/faster to add clients to ASTF/STL. We have tried to do it in Python side and Linux namespace, but I'm looking into more efficient ways to do the same in scalable way