On 21/04/15 22:45, Bill Fischofer wrote:
One of the reasons why I was looking to use the rte_mbuf to represent
packet data rather than packets is that ODP has a richer set of packet
manipulation primitives than does DPDK, and this set will only grow over
time. Trying to overload the rte_mbuf to describe both the packet
metadata and the packet data results in the sort of awkward restrictions
Zoltan identifies.
My current approach is a sort of "encapsulation", although I'm not sure
my terminology is correct: rte_mbuf contains an union of
rte_pktmbuf/rte_ctrlmbuf to hold the the packet/control specific data.
Then, our odp_buf_hdr_t contains rte_mbuf as the first member, the rest
of the members contains the ODP buffer specific details. This is alreadt
in the metadata area of DPDK. Then odp_packet_hdr_t contains the
odp_buf_hdr_t as first member, and the rest are packet specific. We can
easily extend that if needed to store something related to a new feature
we want to support. And we can place the ODP metadata right after that.
The DPDK documentation itself admits this but for
their purpose keeping things contiguous made for better benchmarking in
the simple scenarios they want to showcase.
On Fri, Apr 17, 2015 at 6:36 AM, Savolainen, Petri (Nokia - FI/Espoo)
<[email protected] <mailto:[email protected]>> wrote:
> -----Original Message-----
> From: ext Zoltan Kiss [mailto:[email protected]
<mailto:[email protected]>]
> Sent: Friday, April 17, 2015 2:14 PM
> To: Savolainen, Petri (Nokia - FI/Espoo);
[email protected] <mailto:[email protected]>
> Subject: Re: [lng-odp] odp_packet_add/rem_data question
>
>
>
> On 17/04/15 10:46, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> >
> >
> >> -----Original Message-----
> >> From: lng-odp [mailto:[email protected]
<mailto:[email protected]>] On Behalf Of
> ext
> >> Zoltan Kiss
> >> Sent: Thursday, April 16, 2015 9:39 PM
> >> To: [email protected] <mailto:[email protected]>
> >> Subject: [lng-odp] odp_packet_add/rem_data question
> >>
> >> Hi,
> >>
> >> If I add new data area, can I do that at the expense of the actual
> >> segment's tailroom? (by shifting data up into the tailroom to make
> >> space) In other words: does this necessarily increase
> >> odp_packet_buf_len()?
> >> And if I remove data area, do I have to decrease
odp_packet_buf_len()?
> I
> >> hope not, it wouldn't make too much sense, and it wouldn't be
always
> >> possible if you have only fixed sized buffers.
> >>
> >> Zoli
> >
> > As currently defined, add/rem_data are free to use head/tailroom,
> add/remove segments or even allocate a new packet and copy data
there.
>
> So adding/removing data area doesn't meant the underlying buffer
space
> need to be increased/decreased, is that correct?
Yes. In general, user would use add/rem when push/pull would not fit
the current tail/headroom or segment, or to insert/delete data in
the middle.
-Petri
>
>
> >
> > We'll need to develop segmentation / packet manipulation APIs
further
> during the year.
> >
> > -Petri
> >
_______________________________________________
lng-odp mailing list
[email protected] <mailto:[email protected]>
https://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
