I'd like we sync up on key elements of the document at the arch call today.
I'd like to restate a few things: - ODP Cloud single binary should support multiple hardware environments through DDF - ODP and ODP applications should accommodate how HW uses memory on the receive side, not the oppsoite - HW should accommodate ODP and ODP applications when ODP wants to form packets for the transmit side (typically OFP) - after transmission, HW1 should be able to "free" a packet that was originally received by HW2 (typically VPP) - DPDK shall be considered as a HW that deals with packets its own way. DPDK can to let the HW manage memory through DPDK external memory manager drivers. Bottom line, there can be a case where memory is controlled by a PMD (through external memory) and used directly by an ODP application. - ODP_CLOUD defines an ODP_MBUF_T structure which is pointed to by an ODP_PACKET_T; the structure remains opaque to ODP applications. - ODP_MBUF_T has the same structure as DPDK RTE_MBUF, we may use some fields differently but all fields are present and at the same offsets as DPDK RTE_MBUF. The presence of other metadata coming from linux-generic may be accepted as interim but performance reviews need to be conducted to ensure we have optimal use of metadata space. And here are a few comments - I expect the metadata to shrink: it's not just about the size but about performance. The first cacheline is used for receive while the second mostly for transmit. Any access to additional meta data on the receive side results in accessing a second cacheline which is just twice the cost of DPDK... - There is a need to have pools common "objects" with pool_ops so allow the chain of control ODP_APP -> ODP -> DPDK -> PMD. which is equivalent to DPDK external memory manager but in ODP. Cordially, FF On 11 July 2017 at 02:11, Honnappa Nagarahalli < honnappa.nagaraha...@linaro.org> wrote: > Hi, > I have updated the document with further details. I am done with > this document. Hopefully, we can discuss and take a decision in the > next cloud call. > > https://docs.google.com/document/d/1ocLcJLeHghkaUG5Lq8Cy0B5DgZoNZ > u1lBMtWCoogPOc/edit?usp=sharing > > Thank you, > Honnappa > -- [image: Linaro] <http://www.linaro.org/> François-Frédéric Ozog | *Director Linaro Networking Group* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
