It sounds like what you are asking is an efficient way to transmit a list
of packets rather than having to make multiple calls to transmit packets
individually.  This should be covered later this year when we discuss
traffic shaping and other TX-side APIs.

On Tue, Jan 20, 2015 at 6:20 AM, Savolainen, Petri (NSN - FI/Espoo) <
[email protected]> wrote:

>  Hi,
>
>
>
> Packet chaining and segment manipulation functions will be added later on
> this year.
>
>
>
> Currently, copying is the only way to combine data from two packets.
> Either add data space into pkt1 (odp_packet_add_data()) and copy data from
> pkt2, or allocate pkt3 and copy data from pkt1 and pkt2.
>
>
>
> -Petri
>
>
>
>
>
>
>
> *From:* [email protected] [mailto:
> [email protected]] *On Behalf Of *ext Prashant Upadhyaya
> *Sent:* Tuesday, January 20, 2015 7:28 AM
> *To:* [email protected]
> *Subject:* [lng-odp] Regarding odp_packet_t and buffer chaining
>
>
>
> Hi,
>
>
>
> Suppose I have pkt1 and pk2 which are instances of odp_packet_t.
>
> Now I have two questions –
>
>
>
> 1.      what is the way to chain the buffers of pkt1 and pkt2 into pkt1
> so that from now on I can just use pkt1 for transmission via, say,
> odp_pktio_send API
>
> 2.      if I create a new odp_packet_t pkt3, then how can I take buffers
> out of pkt1 and pk2 and chain them up in pkt3 so that I can send pkt3 via
> odp_pktio_send API
>
>
>
> We can assume that all pkt’s are obtained from the same buffer pool.
>
> If there is a way to chain up pkt’s themselves instead of the buffers
> associated with them, that is also ok by me.
>
>
>
> Unfortunately I am not clear regarding the API calls to be used at the
> application level for this, that is the guidance I am looking for – what is
> the official way in an ODP compliant application to achieve the above
> usecases.
>
>
>
> The ultimate idea ofcourse is to chain up the packets/buffers so that I
> can avoid mem copies to create a single buffer to be sent out. (something
> similar to ‘mbuf chaining’ supported by eg. DPDK)
>
>
>
> Regards
>
> -Prashant
>
>
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or used
> for any purpose other than for what it is intended. If you have received
> this message in error, please notify the originator immediately. If you are
> not the intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of
> this message. Aricent accepts no responsibility for loss or damage arising
> from the use of the information transmitted by this email including damage
> from virus."
>
> _______________________________________________
> lng-odp mailing list
> [email protected]
> http://lists.linaro.org/mailman/listinfo/lng-odp
>
>
_______________________________________________
lng-odp mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/lng-odp

Reply via email to