This patch series could be split into two different parts as Reference and Composite since IMO the Referencing part is straight forward and might not need much discussion and could be be accepted sooner.
Regarding the concept of composite packets it would be appreciable to provide some use-cases for this API. The individual pieces of the composite could be referenced using a different handle than the odp_packet_t in the same way we do for segments. Since the idea is to utilize unique and shared sections these sections could be referred using odp_buffer_t rather than odp_packet_t. Regards, Bala Regards, Bala On 7 January 2016 at 20:20, Bill Fischofer <bill.fischo...@linaro.org> wrote: > Add two new concepts to ODP Packets: References and Composites > > This RFC proposes the addition of two new concepts to the ODP API: References > and Composites. A reference is an alias to packet. References are either > shared or nonshared. Changes to a shared reference are visible to all other > shared reference to the same packet while changes to nonshared references are > unique to that reference. References provide an efficient means of supporting > things like multicast without the explicit use of reference counts, as > underlying packet storage is only freed when the last reference to it is > freed. > > References are intended to be used in conjunction with another new concept: > Composites. A composite is a logical join between two packets that can then > be manipulated as if they are a single packet. The intent of composites is to > provide an efficient and implementation-independent means of creating and > manipulating packets that consist of a combination of unique and shared > sections. Typical use would be to have one or more unique headers prefixed to > a common payload. > > Composites are created by pushing/pulling prefixes and suffixes. These > routines create a new composite packet which has its own handle. Each of the > component parts of composites are themelves ODP packets and continue to be > manipulable via ODP APIs even while they are part of a composite. References > to each part of a composite via its own handle affect that part of the > composite only but are visible when referencing the composite via its handle. > Note that a composite handle is an implied reference to each of its component > parts, so freeing a packet after it has been composited does not release the > underlying storage associated with that part until the composite itself is > freed or the freed part is removed from the composite. > > Bill Fischofer (1): > api: packet: add packet references and composites > > include/odp/api/packet.h | 98 > ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 98 insertions(+) > > -- > 2.5.0 > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
