OFP doesn't start if ODP doesn't have crypto devices (IPSEC support)

[RadulescuValentin]

sudo ./example/fpm/fpm -i 0 -f ./example/fpm/ofp.cli ... I 0 0:2891137280 ofp_uma.c:45] Creating pool 'udp_inpcb', nitems=1024 size=904 total=925696 I 0 0:2891137280 ofp_uma.c:45] Creating pool 'tcp_inpcb', nitems=2048 size=904 total=1851392 I 0 0:2891137280 ofp_uma.c:45] Creating pool 'tcpcb', nitems=2048 size=784 total=1605632 I 0 0:2891137280 ofp_uma.c:45] Creating pool 'tcptw', nitems=409 size=80 total=32720 I 0 0:2891137280 ofp_uma.c:45] Creating pool 'syncache', nitems=30720 size=168 total=5160960 I 1 0:2891137280 ofp_uma.c:45] Creating pool 'tcpreass', nitems=320 size=48 total=15360 I 1 0:2891137280 ofp_uma.c:45] Creating pool 'sackhole', nitems=65536 size=40 total=2621440 odp_crypto.c:536:odp_crypto_capability():No crypto devices available E 1 0:2891137280 ofp_ipsec.c:179] odp_ipsec_capability failed Error: OFP global init failed. E 1 0:2891137280 ofp_vxlan.c:402] Error: VXLAN port queue not initialized W 2 0:2891137280 ofp_timer.c:476] Timeout already expired or inactive Segmentation fault (core dumped)

[JannePeltonen]

The problem seems to be in the ODP you are using. odp_crypto_capability() is not supposed to fail when IPsec cannot be done but should return the capability struct that tells the fact. OFP currently expects capability query to always work and treats its failure as a fatal error.

[RadulescuValentin]

Hi,

Did a new test using dpdk v17.11.4 (4b6e76eb6e59fc133b3f67e6d5dcd38c864fb894 commit) and odp-dpdk (e9ad0a254722115450199fe4a72942be9b5cf4e1 commit) and the API still fails: I -2102033820 0:3089917952 ofp_uma.c:45] Creating pool 'sackhole', nitems=65536 size=40 total=2621440 odp_crypto.c:557:odp_crypto_capability():No crypto devices available E -2090823328 0:3089917952 ofp_ipsec.c:179] odp_ipsec_capability failed E -2090817028 0:3089917952 app_main.c:351] Error: OFP global init failed.

Also, looking at the odp_crypto_capability() API: https://www.opendataplane.org/api-documentation/master/api/group__odp__crypto.html#ga53075378e866aaa5799a742ca7e7ace8 Return values: <0 on failure

[JannePeltonen]

So odp-dpdk needs a fix since the capability query is not supposed to fail like that. The ODP API validation tests (that are in the linux generic ODP tree) fail if odp_ipsec_capability() fails, indicating that odp-dpdk is not fully compliant with the ODP API.

[RadulescuValentin]

Created https://github.com/Linaro/odp-dpdk/issues/59

[Bill-Fischofer-Linaro]

In odp-dpdk, odp_crypto_capability() calls rte_cryptodev_count() and returns -1 if this call says there are no crypto devices available.

Sounds like OFP needs to take this possibility into account? The odp-dpdk implementation is designed to leverage underlying DPDK capabilities so if these are not there there is no SW backup. The odp-linux implementation provides cryptographic services via OpenSSL (if available) and has a "fallback" of saying only the NULL cipher suite is available if not, so in this implementation odp_crypto_capability() sill always return something, even if that something isn't terribly useful.

Either behavior are correct implementations of the API spec.

[JannePeltonen]

I still disagree. See my comments in the odp-dpdk issue.

Anyway, it would be easy to make OFP more tolerant to what odp_ipsec_capability() returns. That can be done if odp-dpdk behavior is deemed correct and the current api validation test buggy or if we just want to make OFP more tolerant to misbehaving ODP implementations (but since OFP is basically a test app for ODP maybe it should not be that liberal?).

[Bill-Fischofer-Linaro]

Petri has posted a PR that changes the odp-dpdk implementation of odp_crypto_capability() such that it can now return RC = 0 but indicate no crypto devices are actually available in the returned capability struct. Would this work better for OFP? In either case it seems you have to be prepared for a return that says basically the same thing, just in different ways.

[JannePeltonen]

OFP can handle odp_crypto_capability() indicating no IPsec support. It also handles failure of odp_crypto_capability() but treats it as a fatal error. My whole point here is that this issue is caused by odp-dpdk behaving in a way that does not pass ODP's own API validation tests and not by a fault in OFP.