Closed JereLeppanen closed 2 years ago
Cool. What about:
@bogdanPricope Possible improvements, but probably not in this PR. ODP and OFP init and term functions have always been separate, and calling the ODP init functions from OFP init functions would probably necessitate passing the parameters through, which would be a bit awkward.
@JereLeppanen I agree that those improvements are not for this PR. I did those and many others in 200+ commits on top OFP (including DHCP and now DNS support). For ODP/OFP init functions my approach was hybrid: caller either provides an ODP instance (configured with ODP init functions, etc.) or a NFP_ODP_INSTANCE_INVALID value (btw ODP_INSTANCE_INVALID is not defined) and ofp will create and manage the ODP instance with some default params.
Btw, what are your plans with OFP? As far I can tell, for whatever you are using it, I can give you a better version with a richer feature set and it will cost less then develop it yourself.
Now that ODP does not necessarily support scheduled queues as IPsec destination queues, ofp_ipsec_init_global() should probably set max_num_sa to zero if inbound_op_mode or outbound_op_mode is async and the queue_type_sched ipsec capability is not set in ODP.
v2:
Update ODP repository links
(Matias)timer: Use odp_timer_pool_param_init() instead of memset()
(Matias)readme: Remove references to travis-ci
ipsec: If op mode is async, check whether scheduled queues are supported
(Janne)Remove ThunderX specific documentation
v3: