Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
Hi, This patch will have to be modified as we have decided to move the segmentation support in packet header file. I will provide an updated patch for the same. Regards, Bala On 31 October 2014 20:24, Bill Fischofer wrote: > This patch does not apply to the current repository. Is there a revised > version available? > > Thanks. > > Bill > > On Wed, Oct 22, 2014 at 8:47 AM, Bill Fischofer > wrote: > >> I had previously detailed some of the problems that arise if we remove >> segmentation support from buffers while trying to keep it as part of >> packets. I'd still like to see a response to these questions. Given that >> we support unsegmented buffers I don't see what the objection is here. >> Those that don't want to deal with segments need not deal with them at >> all. That may limit the platforms they can run on, but applications will >> always choose which implementations are best suited to their needs. >> >> Bill >> >> On Wed, Oct 22, 2014 at 7:27 AM, Savolainen, Petri (NSN - FI/Espoo) < >> petri.savolai...@nsn.com> wrote: >> >>> Hi, >>> >>> In short, I think we must not bring segmentation support to the buffer >>> level "just in case" someone would need it there. Real use cases for >>> segmentation are on packet level (large packets, packet >>> fragmentation/reassembly, etc), so the feature should be implemented there. >>> >>> -Petri >>> >>> > -Original Message- >>> > From: ext Ciprian Barbu [mailto:ciprian.ba...@linaro.org] >>> > Sent: Wednesday, October 22, 2014 3:00 PM >>> > To: Bill Fischofer >>> > Cc: Ola Liljedahl; Savolainen, Petri (NSN - FI/Espoo); lng- >>> > o...@lists.linaro.org >>> > Subject: Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API >>> > >>> > On Wed, Oct 22, 2014 at 2:47 PM, Ciprian Barbu < >>> ciprian.ba...@linaro.org> >>> > wrote: >>> > > This thread has been cold for 5 days, so the assumption is that we >>> can >>> > > go forward with the design right now. This patch series proposed by >>> > > Bala updates some part of the API to the final form of the Buffer >>> > > Design Document, we should have it merged if there are no more >>> > > objections. For that more people with the right expertise should have >>> > > a look at it and get the thread back on track. >>> > > >>> > > I for example have observed the following issue. All the examples >>> > > create buffer pools over shared memory, which doesn't make sense for >>> > > some platforms, linux-dpdk for example, which ignores the base_addr >>> > > argument altogether. I think we need more clarity on this subject, >>> for >>> > > sure the creation of buffer pools will differ from platform to >>> > > platform, which migrates to the application responsibility. >>> > > >>> > > I think we should have a helper function to easily create buffer >>> pools >>> > > without worrying too much about the difference in buffer management >>> > > between platforms, so that one can write a simple portable >>> application >>> > > with no sweat. For the hardcore programmers the API still gives fine >>> > > control to buffer management that depending on the platform could >>> > > involve additional prerequisites, like creating a shared memory >>> > > segment to hold the buffer pool. >>> > >>> > Ok, so I had another look at the Buffer Management final design. I now >>> > see that the option of creating buffer pools from regions has been >>> > removed, so in this case things will be simpler for the applications. >>> > In other words we should really start working on the full >>> > implementation of the API because from there the problem I just stated >>> > above (having to create shared memory segments) will disappear. >>> > >>> > > >>> > > On Fri, Oct 17, 2014 at 4:33 PM, Bill Fischofer >>> > > wrote: >>> > >> Let's consider the implications of removing segmentation support >>> from >>> > >> buffers and only having that concept be part of packets. >>> > >> >>> > >> The first question that arises is what is the relationship between >>> the >>> > >> abstract types odp
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
This patch does not apply to the current repository. Is there a revised version available? Thanks. Bill On Wed, Oct 22, 2014 at 8:47 AM, Bill Fischofer wrote: > I had previously detailed some of the problems that arise if we remove > segmentation support from buffers while trying to keep it as part of > packets. I'd still like to see a response to these questions. Given that > we support unsegmented buffers I don't see what the objection is here. > Those that don't want to deal with segments need not deal with them at > all. That may limit the platforms they can run on, but applications will > always choose which implementations are best suited to their needs. > > Bill > > On Wed, Oct 22, 2014 at 7:27 AM, Savolainen, Petri (NSN - FI/Espoo) < > petri.savolai...@nsn.com> wrote: > >> Hi, >> >> In short, I think we must not bring segmentation support to the buffer >> level "just in case" someone would need it there. Real use cases for >> segmentation are on packet level (large packets, packet >> fragmentation/reassembly, etc), so the feature should be implemented there. >> >> -Petri >> >> > -Original Message- >> > From: ext Ciprian Barbu [mailto:ciprian.ba...@linaro.org] >> > Sent: Wednesday, October 22, 2014 3:00 PM >> > To: Bill Fischofer >> > Cc: Ola Liljedahl; Savolainen, Petri (NSN - FI/Espoo); lng- >> > o...@lists.linaro.org >> > Subject: Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API >> > >> > On Wed, Oct 22, 2014 at 2:47 PM, Ciprian Barbu < >> ciprian.ba...@linaro.org> >> > wrote: >> > > This thread has been cold for 5 days, so the assumption is that we can >> > > go forward with the design right now. This patch series proposed by >> > > Bala updates some part of the API to the final form of the Buffer >> > > Design Document, we should have it merged if there are no more >> > > objections. For that more people with the right expertise should have >> > > a look at it and get the thread back on track. >> > > >> > > I for example have observed the following issue. All the examples >> > > create buffer pools over shared memory, which doesn't make sense for >> > > some platforms, linux-dpdk for example, which ignores the base_addr >> > > argument altogether. I think we need more clarity on this subject, for >> > > sure the creation of buffer pools will differ from platform to >> > > platform, which migrates to the application responsibility. >> > > >> > > I think we should have a helper function to easily create buffer pools >> > > without worrying too much about the difference in buffer management >> > > between platforms, so that one can write a simple portable application >> > > with no sweat. For the hardcore programmers the API still gives fine >> > > control to buffer management that depending on the platform could >> > > involve additional prerequisites, like creating a shared memory >> > > segment to hold the buffer pool. >> > >> > Ok, so I had another look at the Buffer Management final design. I now >> > see that the option of creating buffer pools from regions has been >> > removed, so in this case things will be simpler for the applications. >> > In other words we should really start working on the full >> > implementation of the API because from there the problem I just stated >> > above (having to create shared memory segments) will disappear. >> > >> > > >> > > On Fri, Oct 17, 2014 at 4:33 PM, Bill Fischofer >> > > wrote: >> > >> Let's consider the implications of removing segmentation support from >> > >> buffers and only having that concept be part of packets. >> > >> >> > >> The first question that arises is what is the relationship between >> the >> > >> abstract types odp_packet_t and odp_buffer_t? This is important >> because >> > >> currently we say that packets are allocated from ODP buffer pools, >> not >> > from >> > >> packet pools. Do we need a separate odp_packet_pool_t that is used >> for >> > >> packets? >> > >> >> > >> Today, when I allocate a packet I'm allocating a single object that >> > happens >> > >> to be a single buffer object of type ODP_BUFFER_TYPE_PACKET. But >> that >> > only >> > >> works if the two obj
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
I had previously detailed some of the problems that arise if we remove segmentation support from buffers while trying to keep it as part of packets. I'd still like to see a response to these questions. Given that we support unsegmented buffers I don't see what the objection is here. Those that don't want to deal with segments need not deal with them at all. That may limit the platforms they can run on, but applications will always choose which implementations are best suited to their needs. Bill On Wed, Oct 22, 2014 at 7:27 AM, Savolainen, Petri (NSN - FI/Espoo) < petri.savolai...@nsn.com> wrote: > Hi, > > In short, I think we must not bring segmentation support to the buffer > level "just in case" someone would need it there. Real use cases for > segmentation are on packet level (large packets, packet > fragmentation/reassembly, etc), so the feature should be implemented there. > > -Petri > > > -Original Message- > > From: ext Ciprian Barbu [mailto:ciprian.ba...@linaro.org] > > Sent: Wednesday, October 22, 2014 3:00 PM > > To: Bill Fischofer > > Cc: Ola Liljedahl; Savolainen, Petri (NSN - FI/Espoo); lng- > > o...@lists.linaro.org > > Subject: Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API > > > > On Wed, Oct 22, 2014 at 2:47 PM, Ciprian Barbu > > > wrote: > > > This thread has been cold for 5 days, so the assumption is that we can > > > go forward with the design right now. This patch series proposed by > > > Bala updates some part of the API to the final form of the Buffer > > > Design Document, we should have it merged if there are no more > > > objections. For that more people with the right expertise should have > > > a look at it and get the thread back on track. > > > > > > I for example have observed the following issue. All the examples > > > create buffer pools over shared memory, which doesn't make sense for > > > some platforms, linux-dpdk for example, which ignores the base_addr > > > argument altogether. I think we need more clarity on this subject, for > > > sure the creation of buffer pools will differ from platform to > > > platform, which migrates to the application responsibility. > > > > > > I think we should have a helper function to easily create buffer pools > > > without worrying too much about the difference in buffer management > > > between platforms, so that one can write a simple portable application > > > with no sweat. For the hardcore programmers the API still gives fine > > > control to buffer management that depending on the platform could > > > involve additional prerequisites, like creating a shared memory > > > segment to hold the buffer pool. > > > > Ok, so I had another look at the Buffer Management final design. I now > > see that the option of creating buffer pools from regions has been > > removed, so in this case things will be simpler for the applications. > > In other words we should really start working on the full > > implementation of the API because from there the problem I just stated > > above (having to create shared memory segments) will disappear. > > > > > > > > On Fri, Oct 17, 2014 at 4:33 PM, Bill Fischofer > > > wrote: > > >> Let's consider the implications of removing segmentation support from > > >> buffers and only having that concept be part of packets. > > >> > > >> The first question that arises is what is the relationship between the > > >> abstract types odp_packet_t and odp_buffer_t? This is important > because > > >> currently we say that packets are allocated from ODP buffer pools, not > > from > > >> packet pools. Do we need a separate odp_packet_pool_t that is used > for > > >> packets? > > >> > > >> Today, when I allocate a packet I'm allocating a single object that > > happens > > >> to be a single buffer object of type ODP_BUFFER_TYPE_PACKET. But that > > only > > >> works if the two objects have compatible semantics (including > > segmentation). > > >> If the semantics are not compatible, then an odp_packet_t may in fact > > be > > >> composed of multiple odp_buffer_t's because the packet may consist of > > >> multiple segments and buffers no longer recognize the concept of > > segments so > > >> a single buffer can only be a single segment. > > >> > > >> So now an odp_packet_segment_t may be an odp_buffer_t but an > > odp_packet_t in &
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
Thanks for clarification. Regarding the sharing, is 0 specifying that the application does not require sharing or is a requirement for that segment to be private? Alex On 22 October 2014 16:18, Savolainen, Petri (NSN - FI/Espoo) < petri.savolai...@nsn.com> wrote: > 0 is the default => with current flag definitions: both SW + HW can > access, not shared with external processes. > > > > -Petri > > > > *From:* ext Alexandru Badicioiu [mailto:alexandru.badici...@linaro.org] > *Sent:* Wednesday, October 22, 2014 4:01 PM > *To:* Ciprian Barbu > *Cc:* Bill Fischofer; Savolainen, Petri (NSN - FI/Espoo); > lng-odp@lists.linaro.org > > *Subject:* Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API > > > > The option of creating buffer pools out of memory regions does not solve > existing applications portability problem. The odp_pktio application > expects packets to be allocated in shared memory regions. Is this a > semantic that should be satisfied by all platforms? > > odp_shm_create takes a flag argument which has two values for > linux-generic: > > /* > > * Shared memory flags > > */ > > > > /* Share level */ > > #define ODP_SHM_SW_ONLY 0x1 /**< Application SW only, no HW access */ > > #define ODP_SHM_PROC0x2 /**< Share with external processes */ > > > > but odp_pktio uses 0. Could we assume that this value has a kind of > ODP_SHM_PACKET meaning? > > We could also explicitly extend this flag list to work across platforms. > > > > Alex > > > > > > > > > > > > On 22 October 2014 14:59, Ciprian Barbu wrote: > > On Wed, Oct 22, 2014 at 2:47 PM, Ciprian Barbu > wrote: > > This thread has been cold for 5 days, so the assumption is that we can > > go forward with the design right now. This patch series proposed by > > Bala updates some part of the API to the final form of the Buffer > > Design Document, we should have it merged if there are no more > > objections. For that more people with the right expertise should have > > a look at it and get the thread back on track. > > > > I for example have observed the following issue. All the examples > > create buffer pools over shared memory, which doesn't make sense for > > some platforms, linux-dpdk for example, which ignores the base_addr > > argument altogether. I think we need more clarity on this subject, for > > sure the creation of buffer pools will differ from platform to > > platform, which migrates to the application responsibility. > > > > I think we should have a helper function to easily create buffer pools > > without worrying too much about the difference in buffer management > > between platforms, so that one can write a simple portable application > > with no sweat. For the hardcore programmers the API still gives fine > > control to buffer management that depending on the platform could > > involve additional prerequisites, like creating a shared memory > > segment to hold the buffer pool. > > Ok, so I had another look at the Buffer Management final design. I now > see that the option of creating buffer pools from regions has been > removed, so in this case things will be simpler for the applications. > In other words we should really start working on the full > implementation of the API because from there the problem I just stated > above (having to create shared memory segments) will disappear. > > > > > > On Fri, Oct 17, 2014 at 4:33 PM, Bill Fischofer > > wrote: > >> Let's consider the implications of removing segmentation support from > >> buffers and only having that concept be part of packets. > >> > >> The first question that arises is what is the relationship between the > >> abstract types odp_packet_t and odp_buffer_t? This is important because > >> currently we say that packets are allocated from ODP buffer pools, not > from > >> packet pools. Do we need a separate odp_packet_pool_t that is used for > >> packets? > >> > >> Today, when I allocate a packet I'm allocating a single object that > happens > >> to be a single buffer object of type ODP_BUFFER_TYPE_PACKET. But that > only > >> works if the two objects have compatible semantics (including > segmentation). > >> If the semantics are not compatible, then an odp_packet_t may in fact be > >> composed of multiple odp_buffer_t's because the packet may consist of > >> multiple segments and buffers no longer recognize the concept of > segments so > >> a single buffer can only be a single segment. > >> >
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
doesn't work since an odp_packet_t may > >> consist of multiple underlying odp_buffer_ts, one for each > >> odp_packet_segment_t. Is the packet meta data duplicated in each > segment? > >> Is the first segment of a packet special (odp_packet_first_segment_t)? > And > >> what about user meta data, since this is of potentially variable size? > >> > >> I submit that there are a lot of implications to this that need to be > fully > >> thought through, which is why I believe it's simpler to keep > segmentation as > >> part of buffers that (for now) only happens to be used by a particular > type > >> of buffer, namely packets. > >> > >> Bill > >> > >> On Fri, Oct 17, 2014 at 8:05 AM, Ola Liljedahl < > ola.liljed...@linaro.org> > >> wrote: > >>> > >>> Personally I don't see any need for segmentation support in buffers. I > am > >>> just trying to shoot down what I think is flawed reasoning. > >>> > >>> -- Ola#1 > >>> > >>> On 17 October 2014 15:03, Ola Liljedahl > wrote: > >>>> > >>>> But segmentation is already needed in a current and known subclass > (i.e. > >>>> packets). We are not talking about some other feature which we don't > know if > >>>> it will be needed. So this is not a case of "just in case". > >>>> > >>>> -- Ola#1 > >>>> > >>>> > >>>> On 17 October 2014 14:45, Ola Dahl wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> I do not think it is wise to put features in the base class "just in > >>>>> case" they would be needed in some future (not yet known) subclass. > >>>>> > >>>>> So if the concept of segmentation is relevant for packets but not for > >>>>> timers then I think it should be implemented as a feature of packets. > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Ola D > >>>>> > >>>>> On Fri, Oct 17, 2014 at 2:33 PM, Bill Fischofer > >>>>> wrote: > >>>>>> > >>>>>> I agree that packets are the buffer type that most likely uses > >>>>>> segments, however there are many advantages to putting this support > in the > >>>>>> base class rather than the subclass independent of the number of > buffer > >>>>>> subclasses that will use this support today. > >>>>>> > >>>>>> It's simpler > >>>>>> It's more extensible > >>>>>> It results in cleaner and more efficient application code > >>>>>> > >>>>>> Allow me to expand on these points. First simplicity. Call the > work > >>>>>> required to support segmentation in the implementation X. That X > is going > >>>>>> to be pretty much constant no matter where it is done. But if the > >>>>>> implementation has a choice between doing X at a low level vs. > doing it at a > >>>>>> high level then it's simpler for the implementation to do it once > and be > >>>>>> done with it. If the implementation does it at a higher level then > it is > >>>>>> either constrained to map that higher-level implementation to be > built on a > >>>>>> set of lower-level functions that may or may not be appropriate or > else it > >>>>>> needs to do a completely parallel implementation that is optimal > but highly > >>>>>> duplicative. > >>>>>> > >>>>>> Extensibility should be clear. If at some future point we decide > >>>>>> segmentation would be useful for some new buffer type (e.g., IPC) > then > >>>>>> that's trivial to do if the base class supports it and awkward if > it's only > >>>>>> part of packets. > >>>>>> > >>>>>> From an application standpoint, it's cleaner because the packet APIs > >>>>>> are just wrappers around their corresponding buffer APIs and can be > mapped > >>>>>> directly. Otherwise we have a set of APIs that don't map and are > not easily > >>>>>> translatable. > >>>>>>
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
Hi, In short, I think we must not bring segmentation support to the buffer level "just in case" someone would need it there. Real use cases for segmentation are on packet level (large packets, packet fragmentation/reassembly, etc), so the feature should be implemented there. -Petri > -Original Message- > From: ext Ciprian Barbu [mailto:ciprian.ba...@linaro.org] > Sent: Wednesday, October 22, 2014 3:00 PM > To: Bill Fischofer > Cc: Ola Liljedahl; Savolainen, Petri (NSN - FI/Espoo); lng- > o...@lists.linaro.org > Subject: Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API > > On Wed, Oct 22, 2014 at 2:47 PM, Ciprian Barbu > wrote: > > This thread has been cold for 5 days, so the assumption is that we can > > go forward with the design right now. This patch series proposed by > > Bala updates some part of the API to the final form of the Buffer > > Design Document, we should have it merged if there are no more > > objections. For that more people with the right expertise should have > > a look at it and get the thread back on track. > > > > I for example have observed the following issue. All the examples > > create buffer pools over shared memory, which doesn't make sense for > > some platforms, linux-dpdk for example, which ignores the base_addr > > argument altogether. I think we need more clarity on this subject, for > > sure the creation of buffer pools will differ from platform to > > platform, which migrates to the application responsibility. > > > > I think we should have a helper function to easily create buffer pools > > without worrying too much about the difference in buffer management > > between platforms, so that one can write a simple portable application > > with no sweat. For the hardcore programmers the API still gives fine > > control to buffer management that depending on the platform could > > involve additional prerequisites, like creating a shared memory > > segment to hold the buffer pool. > > Ok, so I had another look at the Buffer Management final design. I now > see that the option of creating buffer pools from regions has been > removed, so in this case things will be simpler for the applications. > In other words we should really start working on the full > implementation of the API because from there the problem I just stated > above (having to create shared memory segments) will disappear. > > > > > On Fri, Oct 17, 2014 at 4:33 PM, Bill Fischofer > > wrote: > >> Let's consider the implications of removing segmentation support from > >> buffers and only having that concept be part of packets. > >> > >> The first question that arises is what is the relationship between the > >> abstract types odp_packet_t and odp_buffer_t? This is important because > >> currently we say that packets are allocated from ODP buffer pools, not > from > >> packet pools. Do we need a separate odp_packet_pool_t that is used for > >> packets? > >> > >> Today, when I allocate a packet I'm allocating a single object that > happens > >> to be a single buffer object of type ODP_BUFFER_TYPE_PACKET. But that > only > >> works if the two objects have compatible semantics (including > segmentation). > >> If the semantics are not compatible, then an odp_packet_t may in fact > be > >> composed of multiple odp_buffer_t's because the packet may consist of > >> multiple segments and buffers no longer recognize the concept of > segments so > >> a single buffer can only be a single segment. > >> > >> So now an odp_packet_segment_t may be an odp_buffer_t but an > odp_packet_t in > >> fact is some meta-object that is constructed (by whom?) from multiple > >> odp_packet_segment_ts that are themselves odp_buffer_ts. So > >> odp_packet_to_buffer() no longer makes sense since there is no longer a > >> one-to-one correspondence between packets and buffers. We could have > an > >> odp_packet_segment_to_buffer() routine instead. > >> > >> Next question: What about meta data? If an odp_packet_t is a type of > an > >> odp_buffer_t then this is very straightforward since all buffer meta > data is > >> reusable as packet meta data and the packet type can just add its own > >> specific meta data to this set. But if an odp_packet_t is now a > separate > >> object then where does the storage for its meta data come from? If we > try to > >> map it into an odp_buffer_t that doesn't work since an odp_packet_t may > >> consist of multiple underlying odp_b
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
eded in a current and known subclass (i.e. >>>> packets). We are not talking about some other feature which we don't know >>>> if >>>> it will be needed. So this is not a case of "just in case". >>>> >>>> -- Ola#1 >>>> >>>> >>>> On 17 October 2014 14:45, Ola Dahl wrote: >>>>> >>>>> Hi, >>>>> >>>>> I do not think it is wise to put features in the base class "just in >>>>> case" they would be needed in some future (not yet known) subclass. >>>>> >>>>> So if the concept of segmentation is relevant for packets but not for >>>>> timers then I think it should be implemented as a feature of packets. >>>>> >>>>> Best regards, >>>>> >>>>> Ola D >>>>> >>>>> On Fri, Oct 17, 2014 at 2:33 PM, Bill Fischofer >>>>> wrote: >>>>>> >>>>>> I agree that packets are the buffer type that most likely uses >>>>>> segments, however there are many advantages to putting this support in >>>>>> the >>>>>> base class rather than the subclass independent of the number of buffer >>>>>> subclasses that will use this support today. >>>>>> >>>>>> It's simpler >>>>>> It's more extensible >>>>>> It results in cleaner and more efficient application code >>>>>> >>>>>> Allow me to expand on these points. First simplicity. Call the work >>>>>> required to support segmentation in the implementation X. That X is >>>>>> going >>>>>> to be pretty much constant no matter where it is done. But if the >>>>>> implementation has a choice between doing X at a low level vs. doing it >>>>>> at a >>>>>> high level then it's simpler for the implementation to do it once and be >>>>>> done with it. If the implementation does it at a higher level then it is >>>>>> either constrained to map that higher-level implementation to be built >>>>>> on a >>>>>> set of lower-level functions that may or may not be appropriate or else >>>>>> it >>>>>> needs to do a completely parallel implementation that is optimal but >>>>>> highly >>>>>> duplicative. >>>>>> >>>>>> Extensibility should be clear. If at some future point we decide >>>>>> segmentation would be useful for some new buffer type (e.g., IPC) then >>>>>> that's trivial to do if the base class supports it and awkward if it's >>>>>> only >>>>>> part of packets. >>>>>> >>>>>> From an application standpoint, it's cleaner because the packet APIs >>>>>> are just wrappers around their corresponding buffer APIs and can be >>>>>> mapped >>>>>> directly. Otherwise we have a set of APIs that don't map and are not >>>>>> easily >>>>>> translatable. >>>>>> >>>>>> With regard to efficient segment access, that's what the >>>>>> odp_packet_addr() routine provides--one-step fast-path addressability to >>>>>> the >>>>>> first segment of a packet. An odp_packet_t is an abstract opaque type. >>>>>> It >>>>>> is not, and cannot be treated as an address by the application. >>>>>> >>>>>> Does that make sense? >>>>>> >>>>>> Bill >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Oct 17, 2014 at 5:37 AM, Savolainen, Petri (NSN - FI/Espoo) >>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> >>>>>>> 1. The only segmentation use case is for segmented packet, not for >>>>>>> segmented buffers. >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2. Common case for packets is that everything application needs is in >>>>>>> the first segment. Odp_packet_t could refer always into that “first >>>>>>> segme
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
;>>> Best regards, >>>> >>>> Ola D >>>> >>>> On Fri, Oct 17, 2014 at 2:33 PM, Bill Fischofer >>>> wrote: >>>>> >>>>> I agree that packets are the buffer type that most likely uses >>>>> segments, however there are many advantages to putting this support in the >>>>> base class rather than the subclass independent of the number of buffer >>>>> subclasses that will use this support today. >>>>> >>>>> It's simpler >>>>> It's more extensible >>>>> It results in cleaner and more efficient application code >>>>> >>>>> Allow me to expand on these points. First simplicity. Call the work >>>>> required to support segmentation in the implementation X. That X is going >>>>> to be pretty much constant no matter where it is done. But if the >>>>> implementation has a choice between doing X at a low level vs. doing it >>>>> at a >>>>> high level then it's simpler for the implementation to do it once and be >>>>> done with it. If the implementation does it at a higher level then it is >>>>> either constrained to map that higher-level implementation to be built on >>>>> a >>>>> set of lower-level functions that may or may not be appropriate or else it >>>>> needs to do a completely parallel implementation that is optimal but >>>>> highly >>>>> duplicative. >>>>> >>>>> Extensibility should be clear. If at some future point we decide >>>>> segmentation would be useful for some new buffer type (e.g., IPC) then >>>>> that's trivial to do if the base class supports it and awkward if it's >>>>> only >>>>> part of packets. >>>>> >>>>> From an application standpoint, it's cleaner because the packet APIs >>>>> are just wrappers around their corresponding buffer APIs and can be mapped >>>>> directly. Otherwise we have a set of APIs that don't map and are not >>>>> easily >>>>> translatable. >>>>> >>>>> With regard to efficient segment access, that's what the >>>>> odp_packet_addr() routine provides--one-step fast-path addressability to >>>>> the >>>>> first segment of a packet. An odp_packet_t is an abstract opaque type. >>>>> It >>>>> is not, and cannot be treated as an address by the application. >>>>> >>>>> Does that make sense? >>>>> >>>>> Bill >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Oct 17, 2014 at 5:37 AM, Savolainen, Petri (NSN - FI/Espoo) >>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> 1. The only segmentation use case is for segmented packet, not for >>>>>> segmented buffers. >>>>>> >>>>>> >>>>>> >>>>>> 2. Common case for packets is that everything application needs is in >>>>>> the first segment. Odp_packet_t could refer always into that “first >>>>>> segment”, so that application (in the common case) would not need to use >>>>>> odp_packet_seg_xxx() calls at all – only odp_packet_xxx() calls. >>>>>> >>>>>> >>>>>> >>>>>> When buffer level features are minimized, the need for >>>>>> odp_buffer_xxx(odp_packet_to_buffer(pkt),...) is minimized. All packet >>>>>> manipulation should happen through odp_packet_xxx(pkt, …) calls. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -Petri >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> From: ext Bill Fischofer [mailto:bill.fischo...@linaro.org] >>>>>> Sent: Friday, October 17, 2014 1:17 PM >>>>>> To: Savolainen, Petri (NSN - FI/Espoo) >>>>>> Cc: ext Jacob, Jerin; lng-odp@lists.linaro.org >>>>>> >>>>>> >>>>>> Subject: Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API >>>>>> >>>>>> &g
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
xtensibility should be clear. If at some future point we decide >>>> segmentation would be useful for some new buffer type (e.g., IPC) then >>>> that's trivial to do if the base class supports it and awkward if it's only >>>> part of packets. >>>> >>>> From an application standpoint, it's cleaner because the packet APIs >>>> are just wrappers around their corresponding buffer APIs and can be mapped >>>> directly. Otherwise we have a set of APIs that don't map and are not >>>> easily translatable. >>>> >>>> With regard to efficient segment access, that's what the >>>> odp_packet_addr() routine provides--one-step fast-path addressability to >>>> the first segment of a packet. An odp_packet_t is an abstract opaque >>>> type. It is not, and cannot be treated as an address by the application. >>>> >>>> Does that make sense? >>>> >>>> Bill >>>> >>>> >>>> >>>> >>>> On Fri, Oct 17, 2014 at 5:37 AM, Savolainen, Petri (NSN - FI/Espoo) < >>>> petri.savolai...@nsn.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> 1. The only segmentation use case is for segmented packet, not for >>>>> segmented buffers. >>>>> >>>>> >>>>> >>>>> 2. Common case for packets is that everything application needs is in >>>>> the first segment. Odp_packet_t could refer always into that “first >>>>> segment”, so that application (in the common case) would not need to use >>>>> odp_packet_seg_xxx() calls at all – only odp_packet_xxx() calls. >>>>> >>>>> >>>>> >>>>> When buffer level features are minimized, the need for >>>>> odp_buffer_xxx(odp_packet_to_buffer(pkt),...) is minimized. All packet >>>>> manipulation should happen through odp_packet_xxx(pkt, …) calls. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -Petri >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* ext Bill Fischofer [mailto:bill.fischo...@linaro.org] >>>>> *Sent:* Friday, October 17, 2014 1:17 PM >>>>> *To:* Savolainen, Petri (NSN - FI/Espoo) >>>>> *Cc:* ext Jacob, Jerin; lng-odp@lists.linaro.org >>>>> >>>>> *Subject:* Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API >>>>> >>>>> >>>>> >>>>> I'm not sure how to understand these two statements: >>>>> >>>>> >>>>> >>>>> 1. There's no use case for segmented buffers >>>>> >>>>> 2. We should optimize for the common case (with segments) >>>>> >>>>> >>>>> >>>>> These seem contradictory. >>>>> >>>>> >>>>> >>>>> The use case for segmented buffers is that some platforms have a >>>>> HW-defined and managed segmented buffer model. If we insist that the >>>>> application be able to specify and control packet segment sizes we are >>>>> making the decision to exclude such platforms from supporting ODP. The >>>>> optimization suggested is precisely what is being proposed here. By >>>>> default packets are assumed to be contained in implementation-managed >>>>> segmented buffers and the first segment will be large enough to contain >>>>> all >>>>> packet headers for non-pathological cases. The case where the application >>>>> wishes to traverse the entire packet in SW is expected to be rare because >>>>> in the data plane you simply do not have the cycles to do this at line >>>>> rate >>>>> for all packets. >>>>> >>>>> >>>>> >>>>> As for having both odp_buffer_xxx() and odp_packet_xxx() APIs, this is >>>>> simply syntax to avoid the constant need for explicit conversion functions >>>>> since unlike C++, C does not support generic functions. So you cannot >>>>> pass >>>>> an odp_packet_t to a function that expects an odp_buffer_t argument >>>>> without >>>>> a conversion call. Do we really want to
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
On 17 October 2014 15:03, Ola Liljedahl wrote: > But segmentation is already needed in a current and known subclass (i.e. > packets). We are not talking about some other feature which we don't know > if it will be needed. So this is not a case of "just in case". > I agree with Petri, that it should be in the packet and not in the buffer. Why put stuff in the buffer when it only belongs to one subclass (packets) as of today? Cheers, Anders > > -- Ola#1 > > > On 17 October 2014 14:45, Ola Dahl wrote: > >> Hi, >> >> I do not think it is wise to put features in the base class "just in >> case" they would be needed in some future (not yet known) subclass. >> >> So if the concept of segmentation is relevant for packets but not for >> timers then I think it should be implemented as a feature of packets. >> >> Best regards, >> >> Ola D >> >> On Fri, Oct 17, 2014 at 2:33 PM, Bill Fischofer < >> bill.fischo...@linaro.org> wrote: >> >>> I agree that packets are the buffer type that most likely uses segments, >>> however there are many advantages to putting this support in the base class >>> rather than the subclass independent of the number of buffer subclasses >>> that will use this support today. >>> >>>- It's simpler >>>- It's more extensible >>>- It results in cleaner and more efficient application code >>> >>> Allow me to expand on these points. First simplicity. Call the work >>> required to support segmentation in the implementation X. That X is going >>> to be pretty much constant no matter where it is done. But if the >>> implementation has a choice between doing X at a low level vs. doing it at >>> a high level then it's simpler for the implementation to do it once and be >>> done with it. If the implementation does it at a higher level then it is >>> either constrained to map that higher-level implementation to be built on a >>> set of lower-level functions that may or may not be appropriate or else it >>> needs to do a completely parallel implementation that is optimal but highly >>> duplicative. >>> >>> Extensibility should be clear. If at some future point we decide >>> segmentation would be useful for some new buffer type (e.g., IPC) then >>> that's trivial to do if the base class supports it and awkward if it's only >>> part of packets. >>> >>> From an application standpoint, it's cleaner because the packet APIs are >>> just wrappers around their corresponding buffer APIs and can be mapped >>> directly. Otherwise we have a set of APIs that don't map and are not >>> easily translatable. >>> >>> With regard to efficient segment access, that's what the >>> odp_packet_addr() routine provides--one-step fast-path addressability to >>> the first segment of a packet. An odp_packet_t is an abstract opaque >>> type. It is not, and cannot be treated as an address by the application. >>> >>> Does that make sense? >>> >>> Bill >>> >>> >>> >>> >>> On Fri, Oct 17, 2014 at 5:37 AM, Savolainen, Petri (NSN - FI/Espoo) < >>> petri.savolai...@nsn.com> wrote: >>> >>>> Hi, >>>> >>>> >>>> >>>> 1. The only segmentation use case is for segmented packet, not for >>>> segmented buffers. >>>> >>>> >>>> >>>> 2. Common case for packets is that everything application needs is in >>>> the first segment. Odp_packet_t could refer always into that “first >>>> segment”, so that application (in the common case) would not need to use >>>> odp_packet_seg_xxx() calls at all – only odp_packet_xxx() calls. >>>> >>>> >>>> >>>> When buffer level features are minimized, the need for >>>> odp_buffer_xxx(odp_packet_to_buffer(pkt),...) is minimized. All packet >>>> manipulation should happen through odp_packet_xxx(pkt, …) calls. >>>> >>>> >>>> >>>> >>>> >>>> -Petri >>>> >>>> >>>> >>>> >>>> >>>> *From:* ext Bill Fischofer [mailto:bill.fischo...@linaro.org] >>>> *Sent:* Friday, October 17, 2014 1:17 PM >>>> *To:* Savolainen, Petri (NSN - FI/Espoo) >>>> *Cc:* ext Jacob, Jerin; lng-odp@lists.linaro.org >>>> >&g
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
Personally I don't see any need for segmentation support in buffers. I am just trying to shoot down what I think is flawed reasoning. -- Ola#1 On 17 October 2014 15:03, Ola Liljedahl wrote: > But segmentation is already needed in a current and known subclass (i.e. > packets). We are not talking about some other feature which we don't know > if it will be needed. So this is not a case of "just in case". > > -- Ola#1 > > > On 17 October 2014 14:45, Ola Dahl wrote: > >> Hi, >> >> I do not think it is wise to put features in the base class "just in >> case" they would be needed in some future (not yet known) subclass. >> >> So if the concept of segmentation is relevant for packets but not for >> timers then I think it should be implemented as a feature of packets. >> >> Best regards, >> >> Ola D >> >> On Fri, Oct 17, 2014 at 2:33 PM, Bill Fischofer < >> bill.fischo...@linaro.org> wrote: >> >>> I agree that packets are the buffer type that most likely uses segments, >>> however there are many advantages to putting this support in the base class >>> rather than the subclass independent of the number of buffer subclasses >>> that will use this support today. >>> >>>- It's simpler >>>- It's more extensible >>>- It results in cleaner and more efficient application code >>> >>> Allow me to expand on these points. First simplicity. Call the work >>> required to support segmentation in the implementation X. That X is going >>> to be pretty much constant no matter where it is done. But if the >>> implementation has a choice between doing X at a low level vs. doing it at >>> a high level then it's simpler for the implementation to do it once and be >>> done with it. If the implementation does it at a higher level then it is >>> either constrained to map that higher-level implementation to be built on a >>> set of lower-level functions that may or may not be appropriate or else it >>> needs to do a completely parallel implementation that is optimal but highly >>> duplicative. >>> >>> Extensibility should be clear. If at some future point we decide >>> segmentation would be useful for some new buffer type (e.g., IPC) then >>> that's trivial to do if the base class supports it and awkward if it's only >>> part of packets. >>> >>> From an application standpoint, it's cleaner because the packet APIs are >>> just wrappers around their corresponding buffer APIs and can be mapped >>> directly. Otherwise we have a set of APIs that don't map and are not >>> easily translatable. >>> >>> With regard to efficient segment access, that's what the >>> odp_packet_addr() routine provides--one-step fast-path addressability to >>> the first segment of a packet. An odp_packet_t is an abstract opaque >>> type. It is not, and cannot be treated as an address by the application. >>> >>> Does that make sense? >>> >>> Bill >>> >>> >>> >>> >>> On Fri, Oct 17, 2014 at 5:37 AM, Savolainen, Petri (NSN - FI/Espoo) < >>> petri.savolai...@nsn.com> wrote: >>> >>>> Hi, >>>> >>>> >>>> >>>> 1. The only segmentation use case is for segmented packet, not for >>>> segmented buffers. >>>> >>>> >>>> >>>> 2. Common case for packets is that everything application needs is in >>>> the first segment. Odp_packet_t could refer always into that “first >>>> segment”, so that application (in the common case) would not need to use >>>> odp_packet_seg_xxx() calls at all – only odp_packet_xxx() calls. >>>> >>>> >>>> >>>> When buffer level features are minimized, the need for >>>> odp_buffer_xxx(odp_packet_to_buffer(pkt),...) is minimized. All packet >>>> manipulation should happen through odp_packet_xxx(pkt, …) calls. >>>> >>>> >>>> >>>> >>>> >>>> -Petri >>>> >>>> >>>> >>>> >>>> >>>> *From:* ext Bill Fischofer [mailto:bill.fischo...@linaro.org] >>>> *Sent:* Friday, October 17, 2014 1:17 PM >>>> *To:* Savolainen, Petri (NSN - FI/Espoo) >>>> *Cc:* ext Jacob, Jerin; lng-odp@lists.linaro.org >>>> >>>> *Subject:* Re: [lng-odp] [ODP/PAT
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
But segmentation is already needed in a current and known subclass (i.e. packets). We are not talking about some other feature which we don't know if it will be needed. So this is not a case of "just in case". -- Ola#1 On 17 October 2014 14:45, Ola Dahl wrote: > Hi, > > I do not think it is wise to put features in the base class "just in case" > they would be needed in some future (not yet known) subclass. > > So if the concept of segmentation is relevant for packets but not for > timers then I think it should be implemented as a feature of packets. > > Best regards, > > Ola D > > On Fri, Oct 17, 2014 at 2:33 PM, Bill Fischofer > wrote: > >> I agree that packets are the buffer type that most likely uses segments, >> however there are many advantages to putting this support in the base class >> rather than the subclass independent of the number of buffer subclasses >> that will use this support today. >> >>- It's simpler >>- It's more extensible >>- It results in cleaner and more efficient application code >> >> Allow me to expand on these points. First simplicity. Call the work >> required to support segmentation in the implementation X. That X is going >> to be pretty much constant no matter where it is done. But if the >> implementation has a choice between doing X at a low level vs. doing it at >> a high level then it's simpler for the implementation to do it once and be >> done with it. If the implementation does it at a higher level then it is >> either constrained to map that higher-level implementation to be built on a >> set of lower-level functions that may or may not be appropriate or else it >> needs to do a completely parallel implementation that is optimal but highly >> duplicative. >> >> Extensibility should be clear. If at some future point we decide >> segmentation would be useful for some new buffer type (e.g., IPC) then >> that's trivial to do if the base class supports it and awkward if it's only >> part of packets. >> >> From an application standpoint, it's cleaner because the packet APIs are >> just wrappers around their corresponding buffer APIs and can be mapped >> directly. Otherwise we have a set of APIs that don't map and are not >> easily translatable. >> >> With regard to efficient segment access, that's what the >> odp_packet_addr() routine provides--one-step fast-path addressability to >> the first segment of a packet. An odp_packet_t is an abstract opaque >> type. It is not, and cannot be treated as an address by the application. >> >> Does that make sense? >> >> Bill >> >> >> >> >> On Fri, Oct 17, 2014 at 5:37 AM, Savolainen, Petri (NSN - FI/Espoo) < >> petri.savolai...@nsn.com> wrote: >> >>> Hi, >>> >>> >>> >>> 1. The only segmentation use case is for segmented packet, not for >>> segmented buffers. >>> >>> >>> >>> 2. Common case for packets is that everything application needs is in >>> the first segment. Odp_packet_t could refer always into that “first >>> segment”, so that application (in the common case) would not need to use >>> odp_packet_seg_xxx() calls at all – only odp_packet_xxx() calls. >>> >>> >>> >>> When buffer level features are minimized, the need for >>> odp_buffer_xxx(odp_packet_to_buffer(pkt),...) is minimized. All packet >>> manipulation should happen through odp_packet_xxx(pkt, …) calls. >>> >>> >>> >>> >>> >>> -Petri >>> >>> >>> >>> >>> >>> *From:* ext Bill Fischofer [mailto:bill.fischo...@linaro.org] >>> *Sent:* Friday, October 17, 2014 1:17 PM >>> *To:* Savolainen, Petri (NSN - FI/Espoo) >>> *Cc:* ext Jacob, Jerin; lng-odp@lists.linaro.org >>> >>> *Subject:* Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API >>> >>> >>> >>> I'm not sure how to understand these two statements: >>> >>> >>> >>> 1. There's no use case for segmented buffers >>> >>> 2. We should optimize for the common case (with segments) >>> >>> >>> >>> These seem contradictory. >>> >>> >>> >>> The use case for segmented buffers is that some platforms have a >>> HW-defined and managed segmented buffer model. If we insist that the >>> application be able to spec
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
Hi, I do not think it is wise to put features in the base class "just in case" they would be needed in some future (not yet known) subclass. So if the concept of segmentation is relevant for packets but not for timers then I think it should be implemented as a feature of packets. Best regards, Ola D On Fri, Oct 17, 2014 at 2:33 PM, Bill Fischofer wrote: > I agree that packets are the buffer type that most likely uses segments, > however there are many advantages to putting this support in the base class > rather than the subclass independent of the number of buffer subclasses > that will use this support today. > >- It's simpler >- It's more extensible >- It results in cleaner and more efficient application code > > Allow me to expand on these points. First simplicity. Call the work > required to support segmentation in the implementation X. That X is going > to be pretty much constant no matter where it is done. But if the > implementation has a choice between doing X at a low level vs. doing it at > a high level then it's simpler for the implementation to do it once and be > done with it. If the implementation does it at a higher level then it is > either constrained to map that higher-level implementation to be built on a > set of lower-level functions that may or may not be appropriate or else it > needs to do a completely parallel implementation that is optimal but highly > duplicative. > > Extensibility should be clear. If at some future point we decide > segmentation would be useful for some new buffer type (e.g., IPC) then > that's trivial to do if the base class supports it and awkward if it's only > part of packets. > > From an application standpoint, it's cleaner because the packet APIs are > just wrappers around their corresponding buffer APIs and can be mapped > directly. Otherwise we have a set of APIs that don't map and are not > easily translatable. > > With regard to efficient segment access, that's what the odp_packet_addr() > routine provides--one-step fast-path addressability to the first segment of > a packet. An odp_packet_t is an abstract opaque type. It is not, and > cannot be treated as an address by the application. > > Does that make sense? > > Bill > > > > > On Fri, Oct 17, 2014 at 5:37 AM, Savolainen, Petri (NSN - FI/Espoo) < > petri.savolai...@nsn.com> wrote: > >> Hi, >> >> >> >> 1. The only segmentation use case is for segmented packet, not for >> segmented buffers. >> >> >> >> 2. Common case for packets is that everything application needs is in the >> first segment. Odp_packet_t could refer always into that “first segment”, >> so that application (in the common case) would not need to use >> odp_packet_seg_xxx() calls at all – only odp_packet_xxx() calls. >> >> >> >> When buffer level features are minimized, the need for >> odp_buffer_xxx(odp_packet_to_buffer(pkt),...) is minimized. All packet >> manipulation should happen through odp_packet_xxx(pkt, …) calls. >> >> >> >> >> >> -Petri >> >> >> >> >> >> *From:* ext Bill Fischofer [mailto:bill.fischo...@linaro.org] >> *Sent:* Friday, October 17, 2014 1:17 PM >> *To:* Savolainen, Petri (NSN - FI/Espoo) >> *Cc:* ext Jacob, Jerin; lng-odp@lists.linaro.org >> >> *Subject:* Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API >> >> >> >> I'm not sure how to understand these two statements: >> >> >> >> 1. There's no use case for segmented buffers >> >> 2. We should optimize for the common case (with segments) >> >> >> >> These seem contradictory. >> >> >> >> The use case for segmented buffers is that some platforms have a >> HW-defined and managed segmented buffer model. If we insist that the >> application be able to specify and control packet segment sizes we are >> making the decision to exclude such platforms from supporting ODP. The >> optimization suggested is precisely what is being proposed here. By >> default packets are assumed to be contained in implementation-managed >> segmented buffers and the first segment will be large enough to contain all >> packet headers for non-pathological cases. The case where the application >> wishes to traverse the entire packet in SW is expected to be rare because >> in the data plane you simply do not have the cycles to do this at line rate >> for all packets. >> >> >> >> As for having both odp_buffer_xxx() and odp_packet_xxx() APIs, this is >
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
I agree that packets are the buffer type that most likely uses segments, however there are many advantages to putting this support in the base class rather than the subclass independent of the number of buffer subclasses that will use this support today. - It's simpler - It's more extensible - It results in cleaner and more efficient application code Allow me to expand on these points. First simplicity. Call the work required to support segmentation in the implementation X. That X is going to be pretty much constant no matter where it is done. But if the implementation has a choice between doing X at a low level vs. doing it at a high level then it's simpler for the implementation to do it once and be done with it. If the implementation does it at a higher level then it is either constrained to map that higher-level implementation to be built on a set of lower-level functions that may or may not be appropriate or else it needs to do a completely parallel implementation that is optimal but highly duplicative. Extensibility should be clear. If at some future point we decide segmentation would be useful for some new buffer type (e.g., IPC) then that's trivial to do if the base class supports it and awkward if it's only part of packets. >From an application standpoint, it's cleaner because the packet APIs are just wrappers around their corresponding buffer APIs and can be mapped directly. Otherwise we have a set of APIs that don't map and are not easily translatable. With regard to efficient segment access, that's what the odp_packet_addr() routine provides--one-step fast-path addressability to the first segment of a packet. An odp_packet_t is an abstract opaque type. It is not, and cannot be treated as an address by the application. Does that make sense? Bill On Fri, Oct 17, 2014 at 5:37 AM, Savolainen, Petri (NSN - FI/Espoo) < petri.savolai...@nsn.com> wrote: > Hi, > > > > 1. The only segmentation use case is for segmented packet, not for > segmented buffers. > > > > 2. Common case for packets is that everything application needs is in the > first segment. Odp_packet_t could refer always into that “first segment”, > so that application (in the common case) would not need to use > odp_packet_seg_xxx() calls at all – only odp_packet_xxx() calls. > > > > When buffer level features are minimized, the need for > odp_buffer_xxx(odp_packet_to_buffer(pkt),...) is minimized. All packet > manipulation should happen through odp_packet_xxx(pkt, …) calls. > > > > > > -Petri > > > > > > *From:* ext Bill Fischofer [mailto:bill.fischo...@linaro.org] > *Sent:* Friday, October 17, 2014 1:17 PM > *To:* Savolainen, Petri (NSN - FI/Espoo) > *Cc:* ext Jacob, Jerin; lng-odp@lists.linaro.org > > *Subject:* Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API > > > > I'm not sure how to understand these two statements: > > > > 1. There's no use case for segmented buffers > > 2. We should optimize for the common case (with segments) > > > > These seem contradictory. > > > > The use case for segmented buffers is that some platforms have a > HW-defined and managed segmented buffer model. If we insist that the > application be able to specify and control packet segment sizes we are > making the decision to exclude such platforms from supporting ODP. The > optimization suggested is precisely what is being proposed here. By > default packets are assumed to be contained in implementation-managed > segmented buffers and the first segment will be large enough to contain all > packet headers for non-pathological cases. The case where the application > wishes to traverse the entire packet in SW is expected to be rare because > in the data plane you simply do not have the cycles to do this at line rate > for all packets. > > > > As for having both odp_buffer_xxx() and odp_packet_xxx() APIs, this is > simply syntax to avoid the constant need for explicit conversion functions > since unlike C++, C does not support generic functions. So you cannot pass > an odp_packet_t to a function that expects an odp_buffer_t argument without > a conversion call. Do we really want to force applications to constantly > be writing code like: > > > > odp_buffer_xxx(odp_packet_to_buffer(pkt),...) > > > > rather than > > > > odp_packet_xxx(pkt,...) > > > > Not only is this awkward, it is also inefficient. By having the explicit > odp_packet_xxx() calls, the implementation is free to optimize these > references in whatever manner is appropriate to that implementation. For > some this may be a simple preprocessor-type expansion while for others > there may be more sophisticated handling
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
Hi, 1. The only segmentation use case is for segmented packet, not for segmented buffers. 2. Common case for packets is that everything application needs is in the first segment. Odp_packet_t could refer always into that “first segment”, so that application (in the common case) would not need to use odp_packet_seg_xxx() calls at all – only odp_packet_xxx() calls. When buffer level features are minimized, the need for odp_buffer_xxx(odp_packet_to_buffer(pkt),...) is minimized. All packet manipulation should happen through odp_packet_xxx(pkt, …) calls. -Petri From: ext Bill Fischofer [mailto:bill.fischo...@linaro.org] Sent: Friday, October 17, 2014 1:17 PM To: Savolainen, Petri (NSN - FI/Espoo) Cc: ext Jacob, Jerin; lng-odp@lists.linaro.org Subject: Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API I'm not sure how to understand these two statements: 1. There's no use case for segmented buffers 2. We should optimize for the common case (with segments) These seem contradictory. The use case for segmented buffers is that some platforms have a HW-defined and managed segmented buffer model. If we insist that the application be able to specify and control packet segment sizes we are making the decision to exclude such platforms from supporting ODP. The optimization suggested is precisely what is being proposed here. By default packets are assumed to be contained in implementation-managed segmented buffers and the first segment will be large enough to contain all packet headers for non-pathological cases. The case where the application wishes to traverse the entire packet in SW is expected to be rare because in the data plane you simply do not have the cycles to do this at line rate for all packets. As for having both odp_buffer_xxx() and odp_packet_xxx() APIs, this is simply syntax to avoid the constant need for explicit conversion functions since unlike C++, C does not support generic functions. So you cannot pass an odp_packet_t to a function that expects an odp_buffer_t argument without a conversion call. Do we really want to force applications to constantly be writing code like: odp_buffer_xxx(odp_packet_to_buffer(pkt),...) rather than odp_packet_xxx(pkt,...) Not only is this awkward, it is also inefficient. By having the explicit odp_packet_xxx() calls, the implementation is free to optimize these references in whatever manner is appropriate to that implementation. For some this may be a simple preprocessor-type expansion while for others there may be more sophisticated handling. But the application should neither know nor care about how the implementation chooses to do this. On Fri, Oct 17, 2014 at 2:27 AM, Savolainen, Petri (NSN - FI/Espoo) mailto:petri.savolai...@nsn.com>> wrote: Hi, This is also my opinion. There’s no use case for segmented buffers in v1.0 - so let’s keep it simple and define that buffers (and thus buffer pools) are always unsegmented. Segmentation comes into play only with packets (and only with those packets that cannot fit into a single buffer). For example, if implementation has max buffer size 256, any packets larger than that are segmented and segments are handled with packet_seg_xxx calls. Also, I’d propose that we optimize for the common case (with segments) - so that the odp_packet_t handle would refer always to the head of packet segment. If the first segment (data/data_len pointed by the odp_packet_t) carries all data application is interested in (=protocol headers), the application would not have to use the segment API at all. Most applications would not see any difference between small/large or segmented/unsegmented packets as long as all headers fit into the first segment. -Petri From: lng-odp-boun...@lists.linaro.org<mailto:lng-odp-boun...@lists.linaro.org> [mailto:lng-odp-boun...@lists.linaro.org<mailto:lng-odp-boun...@lists.linaro.org>] On Behalf Of ext Jacob, Jerin Sent: Friday, October 17, 2014 9:34 AM To: Bill Fischofer Cc: lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> Subject: Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API The need for segment API infrastructure is very clear.The question is, Do we need separate APIs for segment management at odp_buffer_segment* AND odp_packet_segment* levels ? as ODP_BUFFER_TYPE_TIMEOUT and ODP_BUFFER_TYPE_RAW will be always unsegmented and if there is a API for odp_packet_segement* then there will be not be any consumer for odp_buffer_segment* API for 1.0 From: Bill Fischofer mailto:bill.fischo...@linaro.org>> Sent: Thursday, October 16, 2014 9:08 PM To: Jacob, Jerin Cc: Ola Liljedahl; Balasubramanian Manoharan; lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> Subject: Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API From the buffer design doc (p. 8-9): Buffer Pool Options The odp_buffer_opts_e enum is used to specify a
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
I'm not sure how to understand these two statements: 1. There's no use case for segmented buffers 2. We should optimize for the common case (with segments) These seem contradictory. The use case for segmented buffers is that some platforms have a HW-defined and managed segmented buffer model. If we insist that the application be able to specify and control packet segment sizes we are making the decision to exclude such platforms from supporting ODP. The optimization suggested is precisely what is being proposed here. By default packets are assumed to be contained in implementation-managed segmented buffers and the first segment will be large enough to contain all packet headers for non-pathological cases. The case where the application wishes to traverse the entire packet in SW is expected to be rare because in the data plane you simply do not have the cycles to do this at line rate for all packets. As for having both odp_buffer_xxx() and odp_packet_xxx() APIs, this is simply syntax to avoid the constant need for explicit conversion functions since unlike C++, C does not support generic functions. So you cannot pass an odp_packet_t to a function that expects an odp_buffer_t argument without a conversion call. Do we really want to force applications to constantly be writing code like: odp_buffer_xxx(odp_packet_to_buffer(pkt),...) rather than odp_packet_xxx(pkt,...) Not only is this awkward, it is also inefficient. By having the explicit odp_packet_xxx() calls, the implementation is free to optimize these references in whatever manner is appropriate to that implementation. For some this may be a simple preprocessor-type expansion while for others there may be more sophisticated handling. But the application should neither know nor care about how the implementation chooses to do this. On Fri, Oct 17, 2014 at 2:27 AM, Savolainen, Petri (NSN - FI/Espoo) < petri.savolai...@nsn.com> wrote: > Hi, > > > > This is also my opinion. There’s no use case for segmented buffers in v1.0 > - so let’s keep it simple and define that buffers (and thus buffer pools) > are always unsegmented. Segmentation comes into play only with packets (and > only with those packets that cannot fit into a single buffer). For example, > if implementation has max buffer size 256, any packets larger than that are > segmented and segments are handled with packet_seg_xxx calls. > > > > Also, I’d propose that we optimize for the common case (with segments) - > so that the odp_packet_t handle would refer always to the head of packet > segment. If the first segment (data/data_len pointed by the odp_packet_t) > carries all data application is interested in (=protocol headers), the > application would not have to use the segment API at all. Most applications > would not see any difference between small/large or segmented/unsegmented > packets as long as all headers fit into the first segment. > > > > -Petri > > > > > > *From:* lng-odp-boun...@lists.linaro.org [mailto: > lng-odp-boun...@lists.linaro.org] *On Behalf Of *ext Jacob, Jerin > *Sent:* Friday, October 17, 2014 9:34 AM > *To:* Bill Fischofer > *Cc:* lng-odp@lists.linaro.org > *Subject:* Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API > > > > The need for segment API infrastructure is very clear.The question is, Do > we need separate APIs for > > segment management at odp_buffer_segment* AND odp_packet_segment* levels ? > > as ODP_BUFFER_TYPE_TIMEOUT and ODP_BUFFER_TYPE_RAW will be always > unsegmented and if there is a > > API for odp_packet_segement* then there will be not be any consumer for > odp_buffer_segment* API for 1.0 > > > -- > > *From:* Bill Fischofer > *Sent:* Thursday, October 16, 2014 9:08 PM > *To:* Jacob, Jerin > *Cc:* Ola Liljedahl; Balasubramanian Manoharan; lng-odp@lists.linaro.org > *Subject:* Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API > > > > From the buffer design doc (p. 8-9): > *Buffer Pool Options* > > The *odp_buffer_opts_e* enum is used to specify additional options > relating to the buffer pool. Buffer pool options defined are: > > > · ODP_BUFFER_OPTS_NONE > > · ODP_BUFFER_OPTS_UNSEGMENTED > > > These options are additive so an application can simply specify a buf_opts > by ORing together the options needed. Note that buffer pool options are > themselves OPTIONAL and a given implementation MAY fail the buffer pool > creation request with an appropriate *errno* if the requested option is > not supported by the underlying ODP implementation, with the exception that > UNSEGMENTED pools MUST be supported for non-packet types and for packet > types as long as the requested size is less than the implementation-defined > nati
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
Hi, This is also my opinion. There’s no use case for segmented buffers in v1.0 - so let’s keep it simple and define that buffers (and thus buffer pools) are always unsegmented. Segmentation comes into play only with packets (and only with those packets that cannot fit into a single buffer). For example, if implementation has max buffer size 256, any packets larger than that are segmented and segments are handled with packet_seg_xxx calls. Also, I’d propose that we optimize for the common case (with segments) - so that the odp_packet_t handle would refer always to the head of packet segment. If the first segment (data/data_len pointed by the odp_packet_t) carries all data application is interested in (=protocol headers), the application would not have to use the segment API at all. Most applications would not see any difference between small/large or segmented/unsegmented packets as long as all headers fit into the first segment. -Petri From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext Jacob, Jerin Sent: Friday, October 17, 2014 9:34 AM To: Bill Fischofer Cc: lng-odp@lists.linaro.org Subject: Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API The need for segment API infrastructure is very clear.The question is, Do we need separate APIs for segment management at odp_buffer_segment* AND odp_packet_segment* levels ? as ODP_BUFFER_TYPE_TIMEOUT and ODP_BUFFER_TYPE_RAW will be always unsegmented and if there is a API for odp_packet_segement* then there will be not be any consumer for odp_buffer_segment* API for 1.0 From: Bill Fischofer mailto:bill.fischo...@linaro.org>> Sent: Thursday, October 16, 2014 9:08 PM To: Jacob, Jerin Cc: Ola Liljedahl; Balasubramanian Manoharan; lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> Subject: Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API From the buffer design doc (p. 8-9): Buffer Pool Options The odp_buffer_opts_e enum is used to specify additional options relating to the buffer pool. Buffer pool options defined are: · ODP_BUFFER_OPTS_NONE · ODP_BUFFER_OPTS_UNSEGMENTED These options are additive so an application can simply specify a buf_opts by ORing together the options needed. Note that buffer pool options are themselves OPTIONAL and a given implementation MAY fail the buffer pool creation request with an appropriate errno if the requested option is not supported by the underlying ODP implementation, with the exception that UNSEGMENTED pools MUST be supported for non-packet types and for packet types as long as the requested size is less than the implementation-defined native packet segment size. Use ODP_BUFFER_OPTS_NONE to specify default buffer pool options with no additions. The ODP_BUFFER_OPTS_UNSEGMENTED option specifies that the buffer pool should be unsegmented. So unsegmented buffer pool support is available. As far as RAW buffers go, again from the doc (p. 14): ODP_BUFFER_TYPE_RAW This is the “basic” buffer type which simply consists of a single fixed-sized block of contiguous memory. Buffers of this type do not support user meta data and the only built-in meta data supported for this type of buffer are those that are statically computable, such as pool and size. This type of buffer is entirely under application control and most of the buffer APIs defined in this document are not available. APIs for this type of buffer are described in this document. So RAW buffers are always unsegmented. The intent is that Packets are by default segmented but can be unsegmented while the other buffer types are by default unsegmented but (with the exception of RAW buffers) can be made segmented. This is because all buffers start out as a single segment and hence are unsegmented until they are expanded to overflow that single segment. Hope that clarifies things. Again, this is all very straightforward and only comes into play when actually needed. On Wed, Oct 8, 2014 at 4:03 AM, Jacob, Jerin mailto:jerin.ja...@caviumnetworks.com>> wrote: If there is no valid use case for supporting segmentation for raw buffers then lets drop it. At least it will reduce the effort of implementing and testing/verification buffer APIs on different platforms. From: lng-odp-boun...@lists.linaro.org<mailto:lng-odp-boun...@lists.linaro.org> mailto:lng-odp-boun...@lists.linaro.org>> on behalf of Ola Liljedahl mailto:ola.liljed...@linaro.org>> Sent: Wednesday, October 8, 2014 1:37 PM To: Balasubramanian Manoharan Cc: lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> Subject: Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API As I wrote in my comment to the architecture discussion yesterday, I am against segmentation for buffers. Or at least there must be the possibility to create a buffer pool with g
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
The need for segment API infrastructure is very clear.The question is, Do we need separate APIs for segment management at odp_buffer_segment* AND odp_packet_segment* levels ? as ODP_BUFFER_TYPE_TIMEOUT and ODP_BUFFER_TYPE_RAW will be always unsegmented and if there is a API for odp_packet_segement* then there will be not be any consumer for odp_buffer_segment* API for 1.0 From: Bill Fischofer Sent: Thursday, October 16, 2014 9:08 PM To: Jacob, Jerin Cc: Ola Liljedahl; Balasubramanian Manoharan; lng-odp@lists.linaro.org Subject: Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API From the buffer design doc (p. 8-9): Buffer Pool Options The odp_buffer_opts_e enum is used to specify additional options relating to the buffer pool. Buffer pool options defined are: * ODP_BUFFER_OPTS_NONE * ODP_BUFFER_OPTS_UNSEGMENTED These options are additive so an application can simply specify a buf_opts by ORing together the options needed. Note that buffer pool options are themselves OPTIONAL and a given implementation MAY fail the buffer pool creation request with an appropriate errno if the requested option is not supported by the underlying ODP implementation, with the exception that UNSEGMENTED pools MUST be supported for non-packet types and for packet types as long as the requested size is less than the implementation-defined native packet segment size. Use ODP_BUFFER_OPTS_NONE to specify default buffer pool options with no additions. The ODP_BUFFER_OPTS_UNSEGMENTED option specifies that the buffer pool should be unsegmented. So unsegmented buffer pool support is available. As far as RAW buffers go, again from the doc (p. 14): ODP_BUFFER_TYPE_RAW This is the “basic” buffer type which simply consists of a single fixed-sized block of contiguous memory. Buffers of this type do not support user meta data and the only built-in meta data supported for this type of buffer are those that are statically computable, such as pool and size. This type of buffer is entirely under application control and most of the buffer APIs defined in this document are not available. APIs for this type of buffer are described in this document. So RAW buffers are always unsegmented. The intent is that Packets are by default segmented but can be unsegmented while the other buffer types are by default unsegmented but (with the exception of RAW buffers) can be made segmented. This is because all buffers start out as a single segment and hence are unsegmented until they are expanded to overflow that single segment. Hope that clarifies things. Again, this is all very straightforward and only comes into play when actually needed. On Wed, Oct 8, 2014 at 4:03 AM, Jacob, Jerin mailto:jerin.ja...@caviumnetworks.com>> wrote: If there is no valid use case for supporting segmentation for raw buffers then lets drop it. At least it will reduce the effort of implementing and testing/verification buffer APIs on different platforms. From: lng-odp-boun...@lists.linaro.org<mailto:lng-odp-boun...@lists.linaro.org> mailto:lng-odp-boun...@lists.linaro.org>> on behalf of Ola Liljedahl mailto:ola.liljed...@linaro.org>> Sent: Wednesday, October 8, 2014 1:37 PM To: Balasubramanian Manoharan Cc: lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> Subject: Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API As I wrote in my comment to the architecture discussion yesterday, I am against segmentation for buffers. Or at least there must be the possibility to create a buffer pool with guaranteed non-segmented buffers. Segmented packets are OK but not all usages for buffers relate to packets. A lot of internal usages (timeouts, SW messages, internal data structures) will not be able to handle segmented buffers so you must be able to force the creation of buffer pools with non-segmented buffers. -- Ola On 8 October 2014 09:50, Balasubramanian Manoharan mailto:bala.manoha...@linaro.org>> wrote: This patch contains ODP Buffer Management missing APIs The intent of this patch is to port the missing APIs from Buffer Management design document into Linux-generic repo. The dummy functions will be replaced during linux-generic implementation. Signed-off-by: Balasubramanian Manoharan mailto:bala.manoha...@linaro.org>> --- platform/linux-generic/include/api/odp_buffer.h| 203 - .../linux-generic/include/api/odp_buffer_pool.h| 30 +++ platform/linux-generic/odp_buffer.c| 120 platform/linux-generic/odp_buffer_pool.c | 7 + 4 files changed, 351 insertions(+), 9 deletions(-) diff --git a/platform/linux-generic/include/api/odp_buffer.h b/platform/linux-generic/include/api/odp_buffer.h index d8577fd..aeb75ed 100644 --- a/platform/linux-generic/include/api/odp_buffer.h +++ b/platform/linux-generic/include/api
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
Reviewed but need the following changes:
1. odp_buffer_copy() - Add 2nd argument to reflect target buffer pool.
Syntax should be: odp_buffer_t odp_buffer_copy(odp_buffer_t buf,
odp_buffer_pool_t pool);
Thanks.
Bill
On Wed, Oct 8, 2014 at 2:50 AM, Balasubramanian Manoharan <
bala.manoha...@linaro.org> wrote:
> This patch contains ODP Buffer Management missing APIs
> The intent of this patch is to port the missing APIs from Buffer
> Management design document into Linux-generic repo.
> The dummy functions will be replaced during linux-generic implementation.
>
> Signed-off-by: Balasubramanian Manoharan
>
Reviewed-by: Bill Fischofer
> ---
> platform/linux-generic/include/api/odp_buffer.h| 203
> -
> .../linux-generic/include/api/odp_buffer_pool.h| 30 +++
> platform/linux-generic/odp_buffer.c| 120
> platform/linux-generic/odp_buffer_pool.c | 7 +
> 4 files changed, 351 insertions(+), 9 deletions(-)
>
> diff --git a/platform/linux-generic/include/api/odp_buffer.h
> b/platform/linux-generic/include/api/odp_buffer.h
> index d8577fd..aeb75ed 100644
> --- a/platform/linux-generic/include/api/odp_buffer.h
> +++ b/platform/linux-generic/include/api/odp_buffer.h
> @@ -28,8 +28,34 @@ extern "C" {
> */
> typedef uint32_t odp_buffer_t;
>
> -#define ODP_BUFFER_INVALID (0x) /**< Invalid buffer */
> +/**
> +* ODP buffer segment
> +*/
> +typedef uint32_t odp_buffer_segment_t;
>
> +/**
> +* ODP buffer type
> +*/
> +typedef enum odp_buffer_type {
> + ODP_BUFFER_TYPE_INVALID = -1, /**< Buffer type invalid */
> + ODP_BUFFER_TYPE_ANY = 0,/**< Buffer that can hold any other
> + buffer type */
> + ODP_BUFFER_TYPE_RAW = 1,/**< Raw buffer,
> + no additional metadata */
> + ODP_BUFFER_TYPE_PACKET = 2, /**< Packet buffer */
> + ODP_BUFFER_TYPE_TIMEOUT = 3 /**< Timeout buffer */
> +} odp_buffer_type_e;
> +
> +/**
> +* ODP buffer options
> +*/
> +typedef enum odp_buffer_opts {
> + ODP_BUFFER_OPTS_NONE,
> + ODP_BUFFER_OPTS_UNSEGMENTED
> +} odp_buffer_opts_e;
> +
> +#define ODP_BUFFER_INVALID (0x) /**< Invalid buffer */
> +#define ODP_SEGMENT_INVALID (0x) /**< Invalid segment */
>
> /**
> * Buffer start address
> @@ -58,14 +84,6 @@ size_t odp_buffer_size(odp_buffer_t buf);
> */
> int odp_buffer_type(odp_buffer_t buf);
>
> -#define ODP_BUFFER_TYPE_INVALID (-1) /**< Buffer type invalid */
> -#define ODP_BUFFER_TYPE_ANY 0 /**< Buffer that can hold any other
> - buffer type */
> -#define ODP_BUFFER_TYPE_RAW 1 /**< Raw buffer, no additional
> metadata */
> -#define ODP_BUFFER_TYPE_PACKET2 /**< Packet buffer */
> -#define ODP_BUFFER_TYPE_TIMEOUT 3 /**< Timeout buffer */
> -
> -
> /**
> * Tests if buffer is valid
> *
> @@ -76,6 +94,110 @@ int odp_buffer_type(odp_buffer_t buf);
> int odp_buffer_is_valid(odp_buffer_t buf);
>
> /**
> + * Tests if buffer is segmented
> + *
> + * @param[in] buf Buffer handle
> + *
> + * @return 1 if buffer has more than one segment,
> + * otherwise 0
> + */
> +
> +int odp_buffer_is_segmented(odp_buffer_t buf);
> +
> +/**
> + * Get address and size of user meta data associated with a buffer
> + *
> + * @param[in] buf Buffer handle
> + * @param[out] udata_size Number of bytes of user meta data available
> + * at the returned address
> + * @return Address of the user meta data for this
> buffer
> + * or NULL if the buffer has no user meta
> data.
> + */
> +void *odp_buffer_udata(odp_buffer_t buf, size_t *udata_size);
> +
> +/**
> + * Get address of user meta data associated with a buffer
> + *
> + * @param[in] buf Buffer handle
> + *
> + * @return Address of the user meta data for this buffer
> + * or NULL if the buffer has no user meta data.
> + */
> +void *odp_buffer_udata_addr(odp_buffer_t buf);
> +
> +/**
> + * Get count of number of segments in a buffer
> + *
> + * @param[in] buf Buffer handle
> + *
> + * @return Count of the number of segments in buf
> + */
> +size_t odp_buffer_segment_count(odp_buffer_t buf);
> +
> +/**
> + * Get the segment identifier for a buffer segment by index
> + *
> + * @param[in] buf Buffer handle
> + * @param[in] ndx Segment index of segment of interest
> + *
> + * @return Segment identifier or ODP_SEGMENT_INVALID if the
> + * supplied ndx is out of range.
> + */
> +odp_buffer_segment_t odp_buffer_segment_by_index(odp_buffer_t buf, size_t
> ndx);
> +
> +/**
> + * Get the next segment identifier for a buffer segment
> + *
> + * @param[in] buf Buffer handle
> + * @param[in] seg Segment identifier of the previous segment
> +
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
>From the buffer design doc (p. 8-9):
Buffer Pool Options
The odp_buffer_opts_e enum is used to specify additional options relating
to the buffer pool. Buffer pool options defined are:
-
ODP_BUFFER_OPTS_NONE
-
ODP_BUFFER_OPTS_UNSEGMENTED
These options are additive so an application can simply specify a buf_opts
by ORing together the options needed. Note that buffer pool options are
themselves OPTIONAL and a given implementation MAY fail the buffer pool
creation request with an appropriate errno if the requested option is not
supported by the underlying ODP implementation, with the exception that
UNSEGMENTED pools MUST be supported for non-packet types and for packet
types as long as the requested size is less than the implementation-defined
native packet segment size.
Use ODP_BUFFER_OPTS_NONE to specify default buffer pool options with no
additions. The ODP_BUFFER_OPTS_UNSEGMENTED option specifies that the
buffer pool should be unsegmented.
So unsegmented buffer pool support is available. As far as RAW buffers go,
again from the doc (p. 14):
ODP_BUFFER_TYPE_RAWThis is the “basic” buffer type which simply consists of
a single fixed-sized block of contiguous memory. Buffers of this type do
not support user meta data and the only built-in meta data supported for
this type of buffer are those that are statically computable, such as pool
and size. This type of buffer is entirely under application control and
most of the buffer APIs defined in this document are not available. APIs
for this type of buffer are described in this document.
So RAW buffers are always unsegmented. The intent is that Packets are by
default segmented but can be unsegmented while the other buffer types are
by default unsegmented but (with the exception of RAW buffers) can be made
segmented. This is because all buffers start out as a single segment and
hence are unsegmented until they are expanded to overflow that single
segment.
Hope that clarifies things. Again, this is all very straightforward and
only comes into play when actually needed.
On Wed, Oct 8, 2014 at 4:03 AM, Jacob, Jerin wrote:
> If there is no valid use case for supporting segmentation for raw
> buffers then lets drop it. At least it will reduce the effort of
>
> implementing and testing/verification buffer APIs on different platforms.
>
>
> --
> *From:* lng-odp-boun...@lists.linaro.org
> on behalf of Ola Liljedahl
> *Sent:* Wednesday, October 8, 2014 1:37 PM
> *To:* Balasubramanian Manoharan
> *Cc:* lng-odp@lists.linaro.org
> *Subject:* Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
>
> As I wrote in my comment to the architecture discussion yesterday, I am
> against segmentation for buffers. Or at least there must be the possibility
> to create a buffer pool with guaranteed non-segmented buffers. Segmented
> packets are OK but not all usages for buffers relate to packets. A lot of
> internal usages (timeouts, SW messages, internal data structures) will not
> be able to handle segmented buffers so *you must be able to force the
> creation of buffer pools with non-segmented buffers.*
>
> -- Ola
>
>
> On 8 October 2014 09:50, Balasubramanian Manoharan <
> bala.manoha...@linaro.org> wrote:
>
>> This patch contains ODP Buffer Management missing APIs
>> The intent of this patch is to port the missing APIs from Buffer
>> Management design document into Linux-generic repo.
>> The dummy functions will be replaced during linux-generic implementation.
>>
>> Signed-off-by: Balasubramanian Manoharan
>> ---
>> platform/linux-generic/include/api/odp_buffer.h| 203
>> -
>> .../linux-generic/include/api/odp_buffer_pool.h| 30 +++
>> platform/linux-generic/odp_buffer.c| 120
>> platform/linux-generic/odp_buffer_pool.c | 7 +
>> 4 files changed, 351 insertions(+), 9 deletions(-)
>>
>> diff --git a/platform/linux-generic/include/api/odp_buffer.h
>> b/platform/linux-generic/include/api/odp_buffer.h
>> index d8577fd..aeb75ed 100644
>> --- a/platform/linux-generic/include/api/odp_buffer.h
>> +++ b/platform/linux-generic/include/api/odp_buffer.h
>> @@ -28,8 +28,34 @@ extern "C" {
>> */
>> typedef uint32_t odp_buffer_t;
>>
>> -#define ODP_BUFFER_INVALID (0x) /**< Invalid buffer */
>> +/**
>> +* ODP buffer segment
>> +*/
>> +typedef uint32_t odp_buffer_segment_t;
>>
>> +/**
>> +* ODP buffer type
>> +*/
>> +typedef enum odp_buffer_type {
>> + ODP_BUFFER_TYPE_INVALID = -1, /**< Buffer type invalid */
>> + ODP_BUFFER_TYPE_ANY = 0,/**< Buffer that can hold any
>> other
>> +
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
If there is no valid use case for supporting segmentation for raw buffers then
lets drop it. At least it will reduce the effort of
implementing and testing/verification buffer APIs on different platforms.
From: lng-odp-boun...@lists.linaro.org on
behalf of Ola Liljedahl
Sent: Wednesday, October 8, 2014 1:37 PM
To: Balasubramanian Manoharan
Cc: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
As I wrote in my comment to the architecture discussion yesterday, I am against
segmentation for buffers. Or at least there must be the possibility to create a
buffer pool with guaranteed non-segmented buffers. Segmented packets are OK but
not all usages for buffers relate to packets. A lot of internal usages
(timeouts, SW messages, internal data structures) will not be able to handle
segmented buffers so you must be able to force the creation of buffer pools
with non-segmented buffers.
-- Ola
On 8 October 2014 09:50, Balasubramanian Manoharan
mailto:bala.manoha...@linaro.org>> wrote:
This patch contains ODP Buffer Management missing APIs
The intent of this patch is to port the missing APIs from Buffer Management
design document into Linux-generic repo.
The dummy functions will be replaced during linux-generic implementation.
Signed-off-by: Balasubramanian Manoharan
mailto:bala.manoha...@linaro.org>>
---
platform/linux-generic/include/api/odp_buffer.h| 203 -
.../linux-generic/include/api/odp_buffer_pool.h| 30 +++
platform/linux-generic/odp_buffer.c| 120
platform/linux-generic/odp_buffer_pool.c | 7 +
4 files changed, 351 insertions(+), 9 deletions(-)
diff --git a/platform/linux-generic/include/api/odp_buffer.h
b/platform/linux-generic/include/api/odp_buffer.h
index d8577fd..aeb75ed 100644
--- a/platform/linux-generic/include/api/odp_buffer.h
+++ b/platform/linux-generic/include/api/odp_buffer.h
@@ -28,8 +28,34 @@ extern "C" {
*/
typedef uint32_t odp_buffer_t;
-#define ODP_BUFFER_INVALID (0x) /**< Invalid buffer */
+/**
+* ODP buffer segment
+*/
+typedef uint32_t odp_buffer_segment_t;
+/**
+* ODP buffer type
+*/
+typedef enum odp_buffer_type {
+ ODP_BUFFER_TYPE_INVALID = -1, /**< Buffer type invalid */
+ ODP_BUFFER_TYPE_ANY = 0,/**< Buffer that can hold any other
+ buffer type */
+ ODP_BUFFER_TYPE_RAW = 1,/**< Raw buffer,
+ no additional metadata */
+ ODP_BUFFER_TYPE_PACKET = 2, /**< Packet buffer */
+ ODP_BUFFER_TYPE_TIMEOUT = 3 /**< Timeout buffer */
+} odp_buffer_type_e;
+
+/**
+* ODP buffer options
+*/
+typedef enum odp_buffer_opts {
+ ODP_BUFFER_OPTS_NONE,
+ ODP_BUFFER_OPTS_UNSEGMENTED
+} odp_buffer_opts_e;
+
+#define ODP_BUFFER_INVALID (0x) /**< Invalid buffer */
+#define ODP_SEGMENT_INVALID (0x) /**< Invalid segment */
/**
* Buffer start address
@@ -58,14 +84,6 @@ size_t odp_buffer_size(odp_buffer_t buf);
*/
int odp_buffer_type(odp_buffer_t buf);
-#define ODP_BUFFER_TYPE_INVALID (-1) /**< Buffer type invalid */
-#define ODP_BUFFER_TYPE_ANY 0 /**< Buffer that can hold any other
- buffer type */
-#define ODP_BUFFER_TYPE_RAW 1 /**< Raw buffer, no additional metadata */
-#define ODP_BUFFER_TYPE_PACKET2 /**< Packet buffer */
-#define ODP_BUFFER_TYPE_TIMEOUT 3 /**< Timeout buffer */
-
-
/**
* Tests if buffer is valid
*
@@ -76,6 +94,110 @@ int odp_buffer_type(odp_buffer_t buf);
int odp_buffer_is_valid(odp_buffer_t buf);
/**
+ * Tests if buffer is segmented
+ *
+ * @param[in] buf Buffer handle
+ *
+ * @return 1 if buffer has more than one segment,
+ * otherwise 0
+ */
+
+int odp_buffer_is_segmented(odp_buffer_t buf);
+
+/**
+ * Get address and size of user meta data associated with a buffer
+ *
+ * @param[in] buf Buffer handle
+ * @param[out] udata_size Number of bytes of user meta data available
+ * at the returned address
+ * @return Address of the user meta data for this buffer
+ * or NULL if the buffer has no user meta data.
+ */
+void *odp_buffer_udata(odp_buffer_t buf, size_t *udata_size);
+
+/**
+ * Get address of user meta data associated with a buffer
+ *
+ * @param[in] buf Buffer handle
+ *
+ * @return Address of the user meta data for this buffer
+ * or NULL if the buffer has no user meta data.
+ */
+void *odp_buffer_udata_addr(odp_buffer_t buf);
+
+/**
+ * Get count of number of segments in a buffer
+ *
+ * @param[in] buf Buffer handle
+ *
+ * @return Count of the number of segments in buf
+ */
+size_t odp_buffer_segment_count(odp_buffer_t buf);
Re: [lng-odp] [ODP/PATCH v1] ODP Buffer Segment Support API
As I wrote in my comment to the architecture discussion yesterday, I am
against segmentation for buffers. Or at least there must be the possibility
to create a buffer pool with guaranteed non-segmented buffers. Segmented
packets are OK but not all usages for buffers relate to packets. A lot of
internal usages (timeouts, SW messages, internal data structures) will not
be able to handle segmented buffers so *you must be able to force the
creation of buffer pools with non-segmented buffers.*
-- Ola
On 8 October 2014 09:50, Balasubramanian Manoharan <
bala.manoha...@linaro.org> wrote:
> This patch contains ODP Buffer Management missing APIs
> The intent of this patch is to port the missing APIs from Buffer
> Management design document into Linux-generic repo.
> The dummy functions will be replaced during linux-generic implementation.
>
> Signed-off-by: Balasubramanian Manoharan
> ---
> platform/linux-generic/include/api/odp_buffer.h| 203
> -
> .../linux-generic/include/api/odp_buffer_pool.h| 30 +++
> platform/linux-generic/odp_buffer.c| 120
> platform/linux-generic/odp_buffer_pool.c | 7 +
> 4 files changed, 351 insertions(+), 9 deletions(-)
>
> diff --git a/platform/linux-generic/include/api/odp_buffer.h
> b/platform/linux-generic/include/api/odp_buffer.h
> index d8577fd..aeb75ed 100644
> --- a/platform/linux-generic/include/api/odp_buffer.h
> +++ b/platform/linux-generic/include/api/odp_buffer.h
> @@ -28,8 +28,34 @@ extern "C" {
> */
> typedef uint32_t odp_buffer_t;
>
> -#define ODP_BUFFER_INVALID (0x) /**< Invalid buffer */
> +/**
> +* ODP buffer segment
> +*/
> +typedef uint32_t odp_buffer_segment_t;
>
> +/**
> +* ODP buffer type
> +*/
> +typedef enum odp_buffer_type {
> + ODP_BUFFER_TYPE_INVALID = -1, /**< Buffer type invalid */
> + ODP_BUFFER_TYPE_ANY = 0,/**< Buffer that can hold any other
> + buffer type */
> + ODP_BUFFER_TYPE_RAW = 1,/**< Raw buffer,
> + no additional metadata */
> + ODP_BUFFER_TYPE_PACKET = 2, /**< Packet buffer */
> + ODP_BUFFER_TYPE_TIMEOUT = 3 /**< Timeout buffer */
> +} odp_buffer_type_e;
> +
> +/**
> +* ODP buffer options
> +*/
> +typedef enum odp_buffer_opts {
> + ODP_BUFFER_OPTS_NONE,
> + ODP_BUFFER_OPTS_UNSEGMENTED
> +} odp_buffer_opts_e;
> +
> +#define ODP_BUFFER_INVALID (0x) /**< Invalid buffer */
> +#define ODP_SEGMENT_INVALID (0x) /**< Invalid segment */
>
> /**
> * Buffer start address
> @@ -58,14 +84,6 @@ size_t odp_buffer_size(odp_buffer_t buf);
> */
> int odp_buffer_type(odp_buffer_t buf);
>
> -#define ODP_BUFFER_TYPE_INVALID (-1) /**< Buffer type invalid */
> -#define ODP_BUFFER_TYPE_ANY 0 /**< Buffer that can hold any other
> - buffer type */
> -#define ODP_BUFFER_TYPE_RAW 1 /**< Raw buffer, no additional
> metadata */
> -#define ODP_BUFFER_TYPE_PACKET2 /**< Packet buffer */
> -#define ODP_BUFFER_TYPE_TIMEOUT 3 /**< Timeout buffer */
> -
> -
> /**
> * Tests if buffer is valid
> *
> @@ -76,6 +94,110 @@ int odp_buffer_type(odp_buffer_t buf);
> int odp_buffer_is_valid(odp_buffer_t buf);
>
> /**
> + * Tests if buffer is segmented
> + *
> + * @param[in] buf Buffer handle
> + *
> + * @return 1 if buffer has more than one segment,
> + * otherwise 0
> + */
> +
> +int odp_buffer_is_segmented(odp_buffer_t buf);
> +
> +/**
> + * Get address and size of user meta data associated with a buffer
> + *
> + * @param[in] buf Buffer handle
> + * @param[out] udata_size Number of bytes of user meta data available
> + * at the returned address
> + * @return Address of the user meta data for this
> buffer
> + * or NULL if the buffer has no user meta
> data.
> + */
> +void *odp_buffer_udata(odp_buffer_t buf, size_t *udata_size);
> +
> +/**
> + * Get address of user meta data associated with a buffer
> + *
> + * @param[in] buf Buffer handle
> + *
> + * @return Address of the user meta data for this buffer
> + * or NULL if the buffer has no user meta data.
> + */
> +void *odp_buffer_udata_addr(odp_buffer_t buf);
> +
> +/**
> + * Get count of number of segments in a buffer
> + *
> + * @param[in] buf Buffer handle
> + *
> + * @return Count of the number of segments in buf
> + */
> +size_t odp_buffer_segment_count(odp_buffer_t buf);
> +
> +/**
> + * Get the segment identifier for a buffer segment by index
> + *
> + * @param[in] buf Buffer handle
> + * @param[in] ndx Segment index of segment of interest
> + *
> + * @return Segment identifier or ODP_SEGMENT_INVALID if the
> + * supplied ndx is out of range.
> + */
> +odp_buffer_segment_t odp_buffer_segmen
