On Mon, Nov 13, 2017 at 9:26 AM, Honnappa Nagarahalli < honnappa.nagaraha...@linaro.org> wrote:
> On 10 November 2017 at 05:35, Dmitry Eremin-Solenikov > <dmitry.ereminsoleni...@linaro.org> wrote: > > Hello, > > > > Historically ODP helper provided protocol-related headers with > > linux-generic ODP implementation using modified private copy of them. > > The main reason for that was, if I remember correctly, that ODP should > > not provide protocol-related definitions. > > > > I'd like to return to that question: > > - I'm now adding more definitions to private protocol headers and I > > would not like for them to be too much out of sync. > > - We started adding more and more protocol-specific handling in form of > > odp_packet_parse, odp packet flags, etc. > > > > I'd propose to put protocol headers (ip.h, tcp.h, udp.h, eth.h) into > > public ODP namespace (to <odp/protocols/FOO.h>) with the following > > phrase specifying them: > > > > ==== > > These headers are not a part of ODP API specification, however they are > > provided to enable applications to use standard definitions for the > > protocol data. While neither of ODP API/ABI headers uses these protocol > > headers, an implementation SHOULD provide them AS IS to ease porting > > applications between ODP implementations. > > ==== > > > > It is clear that these are not part of the ODP API spec. I think we > should create 'protocol' directory at the same level as 'helper' > directory and move the files there. > We already have a platform/linux-generic/include/protocols directory for implementation internal use, so if we need to add things like ESP and AH definitions, they would go there. The reason for this directory was because linux-generic cannot make use of helpers to avoid circular dependencies in packaging. By contrast, the helper/include/odp/helper directory contains (some) headers that are of use to helper functions (and potentially applications as well). I see no problem with ODP offering a set of mappings for the most common headers, but I'm not sure who the intended target is. Most "real world" applications define their own headers direct from the relevant RFCs and defining (and maintaining) an ever-growing collection of headers is really orthogonal to ODP's main purpose. > > > -- > > With best wishes > > Dmitry >
