On Tue, May 23, 2017 at 10:12 AM, Krishna Garapati < [email protected]> wrote:
> Fallowing are the open issues that requires discussion in odp-cloud > implementation, > > - Currently in odp, pkt pool creation has no knowledge of pktio type as it > would need in case of odp-cloud if it wants to use the platform specific > API's (ex: dpdk) to create the pool through DDF (Driver framework). > As we discussed earlier today, the assumption/hope is that the DPDK external memory manager [1] would be used to allow ODP to provide pool allocation services to DPDK so that ODP pools would not be managed by DPDK. At the time odp_pktio_open() is called for a device that happens to be managed via DPDK, rte_mempool_create_empty() would be called to create a dummy "mempool" for DPDK's use that simply points to the underlying odp_pool_t specified on the odp_pktio_open(). Matias mentioned that he has prototyped this. Matias: Could you post a patch or RFC to outline the approach you took in your prototype? > > - Also, weather odp-cloud runs with dpdk or not, odp library by default all > ways needs to link against dpdk as odp-cloud implementation may require to > include rte_mbuf in order to support dpdk. > > ODP's configure command currently supports --with-dpdk-path to specify where to find an associated DPDK library. In odp-linux, specifying this implicitly enables pktio dpdk support. We should be able to make use of a similar convention to either include the actual rte_mbuf definition in the odp_mbuf_t (a.k.a odp_packet_hdr_t) struct, or else a dummy placeholder that is of the correct size but doesn't require access to the DPDK libraries. Since the rte_mbuf is at this point pretty much locked down, and ODP will be distributed to support a given level of DPDK rather than "any DPDK available" this shouldn't be too much of an issue. > > /Krishna > --- [1] See http://dpdk.org/doc/guides/prog_guide/mempool_lib.html
