Are TNA architecture programs supported?

[pudelkoM]

I tried pushing a pipeline from a TNA P4 program and it just crashed the process. Are other architectures besides v1model even supported in PI?

[antoninbas]

For how to use P4Runtime with TNA P4 programs, you will need to refer to the customer documentation provided by Barefoot. Their implementation may use PI, but this is not covered as part of this repo.

[pudelkoM]

Thank for the info! Just wanted to confirm there is no known limitation in PI.

[antoninbas]

I would say there is no limitation intrinsic to PI but:

• it shouldn't crash so feel free to submit a backtrace
• the PI P4Runtime implementation only handles "standard" objects, which map to the v1model / PSA externs, and not architecture-specific externs (https://github.com/p4lang/p4runtime/blob/v1.1.0/proto/p4/config/v1/p4info.proto#L37). These will just be ignored. And if the P4 compiler for your architecture generates a P4Info message that doesn't try to leverage the standard objects as much as possible, you will only be able to control tables through P4Runtime / PI and pretty much nothing else. So this implementation is only useful to you if the externs in your architecture can be mapped to standard objects, and if your compiler supports doing that mapping for you.

[pudelkoM]

Here's the trace:

bf_switchd: starting warm init for dev_id 0 mode 1 serdes_upgrade 0
Skip diag lib deinit
*** Aborted at 1590616143 (unix time) try "date -d @1590616143" if you are using GNU date ***
PC: @                0x0 (unknown)
*** SIGSEGV (@0x7f001498c800) received by PID 27089 (TID 0x7efffdb30700) from PID 345556992; stack trace: ***
    @     0x7f001c1320e0 (unknown)
    @          0x11d8aaa retrieve_uint32
    @     0x7f001ddbd610 _pi_update_device_start
    @          0x11b0cf5 pi_update_device_start
    @          0x1009091 pi::fe::proto::DeviceMgrImp::pipeline_config_set()
    @          0x1004c6c pi::fe::proto::DeviceMgr::pipeline_config_set()
    @           0xef3e8b stratum::hal::pi::PINode::PushForwardingPipelineConfig()
    @           0x4feaaa stratum::hal::barefoot::BFSwitch::PushForwardingPipelineConfig()
    @           0xca77f6 stratum::hal::P4Service::SetForwardingPipelineConfig()
    @          0x111f14b std::_Mem_fn_base<>::operator()<>()
    @          0x111ef5f std::_Function_handler<>::_M_invoke()
    @          0x11203ef std::function<>::operator()()
    @          0x11201e4 _ZZN9grpc_impl8internal16RpcMethodHandlerIN2p42v19P4Runtime7ServiceENS3_34SetForwardingPipelineConfigRequestENS3_35SetForwardingPipelineConfigResponseEE10RunHandlerERKN4grpc8internal13MethodHandler16HandlerParameterEENKUlvE_clEv
    @          0x111fe84 _ZN9grpc_impl8internal23CatchingFunctionHandlerIZNS0_16RpcMethodHandlerIN2p42v19P4Runtime7ServiceENS4_34SetForwardingPipelineConfigRequestENS4_35SetForwardingPipelineConfigResponseEE10RunHandlerERKN4grpc8internal13MethodHandler16HandlerParameterEEUlvE_EENSA_6StatusEOT_
    @          0x111f5b3 grpc_impl::internal::RpcMethodHandler<>::RunHandler()
    @          0x13970a6 grpc_impl::Server::SyncRequest::CallData::ContinueRunAfterInterception()
    @          0x13969ba grpc_impl::Server::SyncRequest::CallData::Run()
    @          0x1395708 grpc_impl::Server::SyncRequestThreadManager::DoWork()
    @          0x13c35a6 grpc::ThreadManager::MainWorkLoop()
    @          0x13c3292 grpc::ThreadManager::WorkerThread::Run()
    @          0x13c4fc9 grpc::ThreadManager::WorkerThread::WorkerThread()::$_0::operator()()
    @          0x13c4fb9 grpc::ThreadManager::WorkerThread::WorkerThread()::$_0::__invoke()
    @          0x1714987 _ZZN9grpc_core12_GLOBAL__N_120ThreadInternalsPosixC1EPKcPFvPvES4_PbRKNS_6Thread7OptionsEENKUlS4_E_clES4_
    @          0x1714739 _ZZN9grpc_core12_GLOBAL__N_120ThreadInternalsPosixC1EPKcPFvPvES4_PbRKNS_6Thread7OptionsEENUlS4_E_8__invokeES4_
    @     0x7f001c1284a4 start_thread
    @     0x7f001b847d0f clone
    @                0x0 (unknown)

I could prepare a more complete package for reproduction, if needed.

[antoninbas]

I could prepare a more complete package for reproduction, if needed.

I don't think that will be needed. Thanks for sharing this but since the crash happens in the _pi_update_device_start implementation, it will need to be handled by Barefoot folks. If it turns out to be a PI issue, they can submit a patch or open an issue with more details.

(The only thing I can think of is that the binary device config is malformed? You may want to check that whichever code / script you use to build it works for the compiler outputs produced for a TNA program. There may be some subtle differences compared to v1model programs?)

[pudelkoM]

The only thing I can think of is that the binary device config is malformed?

This was the actual issue. P4Runtime-sh seems to pack the p4_device_config differently from your update_config.py scripts. I will investigate that further.

For now I can confirm that (simple) TNA programs can be loaded through PI.