Re: [lng-odp] odp_packet API queries
It's an implementation decision as to how to store metadata. Some implementations may choose to store it in hidden buffer prefixes or suffixes while others may choose to store it elsewhere. The linux-generic implementation is an example of the latter. The reason for doing it this way is that this allows the application full control over the alignment of the buffer data it deals with since that area isn't being used also for metadata, and means that metadata can be added or removed as the APIs evolve without affecting other data alignments. On Tue, Jan 20, 2015 at 9:11 AM, Jerin Jacob wrote: > On Mon, Jan 19, 2015 at 10:17:22AM -0600, Bill Fischofer wrote: > > On Mon, Jan 19, 2015 at 10:00 AM, Jerin Jacob < > > jerin.ja...@caviumnetworks.com> wrote: > > > > > On Mon, Jan 19, 2015 at 09:26:08AM -0600, Bill Fischofer wrote: > > > > On Mon, Jan 19, 2015 at 7:22 AM, Jerin Jacob < > > > jerin.ja...@caviumnetworks.com > > > > > wrote: > > > > > > > > > On Mon, Jan 19, 2015 at 06:09:34AM -0600, Bill Fischofer wrote: > > > > > > I think Petri should weigh in on these questions. For the first > one, > > > > > what > > > > > > problems do you anticipate some platforms having with that > equation? > > > > > > > > > > I have two issues around the unit test case, > > > > > 1) packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - > > > ODP_CONFIG_PACKET_HEADROOM > > > > > - > > > > > ODP_CONFIG_PACKET_TAILROOM creates two segments in my platform and > > > > > tailroom/headroom expects > > > > > to work within a segment ? > > > > > > > > > > > > > Can you elaborate on why this is the case? The intent here was to > define > > > > what constituted a single segment so if it's not accomplishing that > goal > > > it > > > > would be useful to understand why not. > > > > > > OK. We have segment specific meta data(as I mentioned in beginning of > the > > > mail thread) > > > in each segment that can't be counted in > > > ODP_CONFIG_PACKET_HEADROOM and/or ODP_CONFIG_PACKET_TAILROOM. > > > > > > > If it's metadata then is doesn't come out of either of these. Regardless > of > > how a platform stores metadata it is not addressable by the application > as > > part of the packet and hence not included in > > ODP_CONFIG_PACKET_BUF_LEN_MIN. So the equation should still hold. > > ODP_CONFIG_PACKET_BUF_LEN_MIN has special hardware constraints(like size > should be > multiple of cache line size etc). If we are changing the > ODP_CONFIG_PACKET_BUF_LEN_MIN > to hold the equations the it will create hole(unused space in buffer) for > no reason. For example, if > segment specific meta data is 8 bytes and cache size 128 byte..in this > case each buffer will waste > around 120 bytes. > > > > > > > You're articulating why applications neither know nor care about physical > > segment sizes used by implementations. The only thing applications can > see > > are the logical segments exposed by the ODP APIs. > > > > > > > > > > > > > > > > > > > > > > > > 2) pool creation with number of buffers as one and creating a > segmented > > > > > buffers as > > > > > packet_len is more than one segment. > > > > > > > > > > > > > A packet (I use that term here since in our current definition only > > > packets > > > > can support segmentation or headroom) is an object that consists of > > > packet > > > > metadata plus packet data. Packet data is stored in one or more > > > segments, > > > > depending on how the pool it is allocated from is created, but > > > independent > > > > of the number of segments used to store this data it is still a > single > > > > packet. So num_bufs (which will presumably be num_packets in the new > > > pool > > > > definitions) always has a precise meaning. > > > > > > but it has to be num_bufs == num_packet segments > > > > > > And why is that? They are logically different concepts. Conflating them > > only leads to confusion. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think the cleanest solution would be to have the platform > segment > > > size > > > > > > for a given pool accessible as pool metadata, e.g., > > > > > > odp_pool_seg_size(pool), but the real issue is why does the > > > application > > > > > > want this information? If an application wants to ensure that > > > packets > > > > > are > > > > > > unsegmented then the simplest solution is to re-introduce the > notion > > > of > > > > > > unsegmented pools. If an application creates an unsegmented pool > > > then by > > > > > > definition any object allocated from that pool will only consist > of a > > > > > > single segment. By contrast, if the application is designed to > > > support > > > > > > segments then it shouldn't care. > > > > > > > > > > IMO, its simple to add a ODP_CONFIG or odp_packet_alloc of len == > 0 for > > > > > default packet size > > > > > > > > > > > > > ODP_CONFIG is how we're doing things now. More specific > configurations > > > > should be doable on a per-pool basis (subject to implementation > > > > restrictions) giv
Re: [lng-odp] odp_packet API queries
On Mon, Jan 19, 2015 at 10:17:22AM -0600, Bill Fischofer wrote: > On Mon, Jan 19, 2015 at 10:00 AM, Jerin Jacob < > jerin.ja...@caviumnetworks.com> wrote: > > > On Mon, Jan 19, 2015 at 09:26:08AM -0600, Bill Fischofer wrote: > > > On Mon, Jan 19, 2015 at 7:22 AM, Jerin Jacob < > > jerin.ja...@caviumnetworks.com > > > > wrote: > > > > > > > On Mon, Jan 19, 2015 at 06:09:34AM -0600, Bill Fischofer wrote: > > > > > I think Petri should weigh in on these questions. For the first one, > > > > what > > > > > problems do you anticipate some platforms having with that equation? > > > > > > > > I have two issues around the unit test case, > > > > 1) packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - > > ODP_CONFIG_PACKET_HEADROOM > > > > - > > > > ODP_CONFIG_PACKET_TAILROOM creates two segments in my platform and > > > > tailroom/headroom expects > > > > to work within a segment ? > > > > > > > > > > Can you elaborate on why this is the case? The intent here was to define > > > what constituted a single segment so if it's not accomplishing that goal > > it > > > would be useful to understand why not. > > > > OK. We have segment specific meta data(as I mentioned in beginning of the > > mail thread) > > in each segment that can't be counted in > > ODP_CONFIG_PACKET_HEADROOM and/or ODP_CONFIG_PACKET_TAILROOM. > > > > If it's metadata then is doesn't come out of either of these. Regardless of > how a platform stores metadata it is not addressable by the application as > part of the packet and hence not included in > ODP_CONFIG_PACKET_BUF_LEN_MIN. So the equation should still hold. ODP_CONFIG_PACKET_BUF_LEN_MIN has special hardware constraints(like size should be multiple of cache line size etc). If we are changing the ODP_CONFIG_PACKET_BUF_LEN_MIN to hold the equations the it will create hole(unused space in buffer) for no reason. For example, if segment specific meta data is 8 bytes and cache size 128 byte..in this case each buffer will waste around 120 bytes. > > You're articulating why applications neither know nor care about physical > segment sizes used by implementations. The only thing applications can see > are the logical segments exposed by the ODP APIs. > > > > > > > > > > > > > > > > > 2) pool creation with number of buffers as one and creating a segmented > > > > buffers as > > > > packet_len is more than one segment. > > > > > > > > > > A packet (I use that term here since in our current definition only > > packets > > > can support segmentation or headroom) is an object that consists of > > packet > > > metadata plus packet data. Packet data is stored in one or more > > segments, > > > depending on how the pool it is allocated from is created, but > > independent > > > of the number of segments used to store this data it is still a single > > > packet. So num_bufs (which will presumably be num_packets in the new > > pool > > > definitions) always has a precise meaning. > > > > but it has to be num_bufs == num_packet segments > > > And why is that? They are logically different concepts. Conflating them > only leads to confusion. > > > > > > > > > > > > > > > > > > > > > > I think the cleanest solution would be to have the platform segment > > size > > > > > for a given pool accessible as pool metadata, e.g., > > > > > odp_pool_seg_size(pool), but the real issue is why does the > > application > > > > > want this information? If an application wants to ensure that > > packets > > > > are > > > > > unsegmented then the simplest solution is to re-introduce the notion > > of > > > > > unsegmented pools. If an application creates an unsegmented pool > > then by > > > > > definition any object allocated from that pool will only consist of a > > > > > single segment. By contrast, if the application is designed to > > support > > > > > segments then it shouldn't care. > > > > > > > > IMO, its simple to add a ODP_CONFIG or odp_packet_alloc of len == 0 for > > > > default packet size > > > > > > > > > > ODP_CONFIG is how we're doing things now. More specific configurations > > > should be doable on a per-pool basis (subject to implementation > > > restrictions) given an expanded odp_pool_param_t definition. > > > > > > > > > > > > > > > > > > > > On Mon, Jan 19, 2015 at 3:27 AM, Jerin Jacob < > > > > jerin.ja...@caviumnetworks.com > > > > > > wrote: > > > > > > > > > > > On Sat, Jan 17, 2015 at 09:45:12AM -0600, Bill Fischofer wrote: > > > > > > > Application-visible sizes refer to application-visible data. > > > > Metadata is > > > > > > > always implementation-specific and not included in such counts. > > > > Metadata > > > > > > > is "off books" data that is associated with the packet but is not > > > > part of > > > > > > > any addressable packet storage. The advantage of having a packet > > > > object > > > > > > is > > > > > > > that the packet APIs can refer to the packet independent of any > > > > > > > implementation and not to how the packet may be represented in > > > > storage > >
Re: [lng-odp] odp_packet API queries
On Mon, Jan 19, 2015 at 10:00 AM, Jerin Jacob < jerin.ja...@caviumnetworks.com> wrote: > On Mon, Jan 19, 2015 at 09:26:08AM -0600, Bill Fischofer wrote: > > On Mon, Jan 19, 2015 at 7:22 AM, Jerin Jacob < > jerin.ja...@caviumnetworks.com > > > wrote: > > > > > On Mon, Jan 19, 2015 at 06:09:34AM -0600, Bill Fischofer wrote: > > > > I think Petri should weigh in on these questions. For the first one, > > > what > > > > problems do you anticipate some platforms having with that equation? > > > > > > I have two issues around the unit test case, > > > 1) packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - > ODP_CONFIG_PACKET_HEADROOM > > > - > > > ODP_CONFIG_PACKET_TAILROOM creates two segments in my platform and > > > tailroom/headroom expects > > > to work within a segment ? > > > > > > > Can you elaborate on why this is the case? The intent here was to define > > what constituted a single segment so if it's not accomplishing that goal > it > > would be useful to understand why not. > > OK. We have segment specific meta data(as I mentioned in beginning of the > mail thread) > in each segment that can't be counted in > ODP_CONFIG_PACKET_HEADROOM and/or ODP_CONFIG_PACKET_TAILROOM. > If it's metadata then is doesn't come out of either of these. Regardless of how a platform stores metadata it is not addressable by the application as part of the packet and hence not included in ODP_CONFIG_PACKET_BUF_LEN_MIN. So the equation should still hold. You're articulating why applications neither know nor care about physical segment sizes used by implementations. The only thing applications can see are the logical segments exposed by the ODP APIs. > > > > > > > > > > 2) pool creation with number of buffers as one and creating a segmented > > > buffers as > > > packet_len is more than one segment. > > > > > > > A packet (I use that term here since in our current definition only > packets > > can support segmentation or headroom) is an object that consists of > packet > > metadata plus packet data. Packet data is stored in one or more > segments, > > depending on how the pool it is allocated from is created, but > independent > > of the number of segments used to store this data it is still a single > > packet. So num_bufs (which will presumably be num_packets in the new > pool > > definitions) always has a precise meaning. > > but it has to be num_bufs == num_packet segments And why is that? They are logically different concepts. Conflating them only leads to confusion. > > > > > > > > > > > > > > > I think the cleanest solution would be to have the platform segment > size > > > > for a given pool accessible as pool metadata, e.g., > > > > odp_pool_seg_size(pool), but the real issue is why does the > application > > > > want this information? If an application wants to ensure that > packets > > > are > > > > unsegmented then the simplest solution is to re-introduce the notion > of > > > > unsegmented pools. If an application creates an unsegmented pool > then by > > > > definition any object allocated from that pool will only consist of a > > > > single segment. By contrast, if the application is designed to > support > > > > segments then it shouldn't care. > > > > > > IMO, its simple to add a ODP_CONFIG or odp_packet_alloc of len == 0 for > > > default packet size > > > > > > > ODP_CONFIG is how we're doing things now. More specific configurations > > should be doable on a per-pool basis (subject to implementation > > restrictions) given an expanded odp_pool_param_t definition. > > > > > > > > > > > > > > > On Mon, Jan 19, 2015 at 3:27 AM, Jerin Jacob < > > > jerin.ja...@caviumnetworks.com > > > > > wrote: > > > > > > > > > On Sat, Jan 17, 2015 at 09:45:12AM -0600, Bill Fischofer wrote: > > > > > > Application-visible sizes refer to application-visible data. > > > Metadata is > > > > > > always implementation-specific and not included in such counts. > > > Metadata > > > > > > is "off books" data that is associated with the packet but is not > > > part of > > > > > > any addressable packet storage. The advantage of having a packet > > > object > > > > > is > > > > > > that the packet APIs can refer to the packet independent of any > > > > > > implementation and not to how the packet may be represented in > > > storage > > > > > on a > > > > > > particular platform. > > > > > > > > > > But coming back to my question, How an application can create a one > > > segment > > > > > full length packet ? > > > > > Following equation may not be correct in all platforms > > > > > packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - > > > ODP_CONFIG_PACKET_HEADROOM - > > > > > ODP_CONFIG_PACKET_TAILROOM; > > > > > > > > > > > > > > > > > > > > > > Trying to reason about buffers that are used to store packet > data is > > > > > > inherently non-portable and should be discouraged. Hopefully the > > > switch > > > > > to > > > > > > events will help move us in that direction since packets are no > > > longer a > > > > > > type of buf
Re: [lng-odp] odp_packet API queries
On Mon, Jan 19, 2015 at 09:26:08AM -0600, Bill Fischofer wrote: > On Mon, Jan 19, 2015 at 7:22 AM, Jerin Jacob > wrote: > > > On Mon, Jan 19, 2015 at 06:09:34AM -0600, Bill Fischofer wrote: > > > I think Petri should weigh in on these questions. For the first one, > > what > > > problems do you anticipate some platforms having with that equation? > > > > I have two issues around the unit test case, > > 1) packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - ODP_CONFIG_PACKET_HEADROOM > > - > > ODP_CONFIG_PACKET_TAILROOM creates two segments in my platform and > > tailroom/headroom expects > > to work within a segment ? > > > > Can you elaborate on why this is the case? The intent here was to define > what constituted a single segment so if it's not accomplishing that goal it > would be useful to understand why not. OK. We have segment specific meta data(as I mentioned in beginning of the mail thread) in each segment that can't be counted in ODP_CONFIG_PACKET_HEADROOM and/or ODP_CONFIG_PACKET_TAILROOM. > > > > > 2) pool creation with number of buffers as one and creating a segmented > > buffers as > > packet_len is more than one segment. > > > > A packet (I use that term here since in our current definition only packets > can support segmentation or headroom) is an object that consists of packet > metadata plus packet data. Packet data is stored in one or more segments, > depending on how the pool it is allocated from is created, but independent > of the number of segments used to store this data it is still a single > packet. So num_bufs (which will presumably be num_packets in the new pool > definitions) always has a precise meaning. but it has to be num_bufs == num_packet segments > > > > > > > > > > I think the cleanest solution would be to have the platform segment size > > > for a given pool accessible as pool metadata, e.g., > > > odp_pool_seg_size(pool), but the real issue is why does the application > > > want this information? If an application wants to ensure that packets > > are > > > unsegmented then the simplest solution is to re-introduce the notion of > > > unsegmented pools. If an application creates an unsegmented pool then by > > > definition any object allocated from that pool will only consist of a > > > single segment. By contrast, if the application is designed to support > > > segments then it shouldn't care. > > > > IMO, its simple to add a ODP_CONFIG or odp_packet_alloc of len == 0 for > > default packet size > > > > ODP_CONFIG is how we're doing things now. More specific configurations > should be doable on a per-pool basis (subject to implementation > restrictions) given an expanded odp_pool_param_t definition. > > > > > > > > > > On Mon, Jan 19, 2015 at 3:27 AM, Jerin Jacob < > > jerin.ja...@caviumnetworks.com > > > > wrote: > > > > > > > On Sat, Jan 17, 2015 at 09:45:12AM -0600, Bill Fischofer wrote: > > > > > Application-visible sizes refer to application-visible data. > > Metadata is > > > > > always implementation-specific and not included in such counts. > > Metadata > > > > > is "off books" data that is associated with the packet but is not > > part of > > > > > any addressable packet storage. The advantage of having a packet > > object > > > > is > > > > > that the packet APIs can refer to the packet independent of any > > > > > implementation and not to how the packet may be represented in > > storage > > > > on a > > > > > particular platform. > > > > > > > > But coming back to my question, How an application can create a one > > segment > > > > full length packet ? > > > > Following equation may not be correct in all platforms > > > > packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - > > ODP_CONFIG_PACKET_HEADROOM - > > > > ODP_CONFIG_PACKET_TAILROOM; > > > > > > > > > > > > > > > > > > Trying to reason about buffers that are used to store packet data is > > > > > inherently non-portable and should be discouraged. Hopefully the > > switch > > > > to > > > > > events will help move us in that direction since packets are no > > longer a > > > > > type of buffer using the new nomenclature. > > > > > > > > Should we remove odp_buffer_size(buf) == odp_packet_buf_len(pkt)) test > > > > case > > > > or wait for event rework to happen ? > > > > > > > > > > > > > > On Sat, Jan 17, 2015 at 5:52 AM, Jacob, Jerin < > > > > > jerin.ja...@caviumnetworks.com> wrote: > > > > > > > > > > > Some odp_packet API queries based on exiting odp packet unit test > > case, > > > > > > > > > > > > 1) In exiting odp packet unit test case, In order to create one > > full > > > > > > length packet in one segment, > > > > > > We have used following formula, > > > > > > packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - > > > > ODP_CONFIG_PACKET_HEADROOM - > > > > > > ODP_CONFIG_PACKET_TAILROOM; > > > > > > > > > > > > This may not be valid in all platform if the packet segment has > > segment > > > > > > specific meta data. > > > > > > I think, we need to create either new ODP_CONFIG to defin
Re: [lng-odp] odp_packet API queries
On Mon, Jan 19, 2015 at 7:22 AM, Jerin Jacob wrote: > On Mon, Jan 19, 2015 at 06:09:34AM -0600, Bill Fischofer wrote: > > I think Petri should weigh in on these questions. For the first one, > what > > problems do you anticipate some platforms having with that equation? > > I have two issues around the unit test case, > 1) packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - ODP_CONFIG_PACKET_HEADROOM > - > ODP_CONFIG_PACKET_TAILROOM creates two segments in my platform and > tailroom/headroom expects > to work within a segment ? > Can you elaborate on why this is the case? The intent here was to define what constituted a single segment so if it's not accomplishing that goal it would be useful to understand why not. > > 2) pool creation with number of buffers as one and creating a segmented > buffers as > packet_len is more than one segment. > A packet (I use that term here since in our current definition only packets can support segmentation or headroom) is an object that consists of packet metadata plus packet data. Packet data is stored in one or more segments, depending on how the pool it is allocated from is created, but independent of the number of segments used to store this data it is still a single packet. So num_bufs (which will presumably be num_packets in the new pool definitions) always has a precise meaning. > > > > > I think the cleanest solution would be to have the platform segment size > > for a given pool accessible as pool metadata, e.g., > > odp_pool_seg_size(pool), but the real issue is why does the application > > want this information? If an application wants to ensure that packets > are > > unsegmented then the simplest solution is to re-introduce the notion of > > unsegmented pools. If an application creates an unsegmented pool then by > > definition any object allocated from that pool will only consist of a > > single segment. By contrast, if the application is designed to support > > segments then it shouldn't care. > > IMO, its simple to add a ODP_CONFIG or odp_packet_alloc of len == 0 for > default packet size > ODP_CONFIG is how we're doing things now. More specific configurations should be doable on a per-pool basis (subject to implementation restrictions) given an expanded odp_pool_param_t definition. > > > > > On Mon, Jan 19, 2015 at 3:27 AM, Jerin Jacob < > jerin.ja...@caviumnetworks.com > > > wrote: > > > > > On Sat, Jan 17, 2015 at 09:45:12AM -0600, Bill Fischofer wrote: > > > > Application-visible sizes refer to application-visible data. > Metadata is > > > > always implementation-specific and not included in such counts. > Metadata > > > > is "off books" data that is associated with the packet but is not > part of > > > > any addressable packet storage. The advantage of having a packet > object > > > is > > > > that the packet APIs can refer to the packet independent of any > > > > implementation and not to how the packet may be represented in > storage > > > on a > > > > particular platform. > > > > > > But coming back to my question, How an application can create a one > segment > > > full length packet ? > > > Following equation may not be correct in all platforms > > > packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - > ODP_CONFIG_PACKET_HEADROOM - > > > ODP_CONFIG_PACKET_TAILROOM; > > > > > > > > > > > > > > Trying to reason about buffers that are used to store packet data is > > > > inherently non-portable and should be discouraged. Hopefully the > switch > > > to > > > > events will help move us in that direction since packets are no > longer a > > > > type of buffer using the new nomenclature. > > > > > > Should we remove odp_buffer_size(buf) == odp_packet_buf_len(pkt)) test > > > case > > > or wait for event rework to happen ? > > > > > > > > > > > On Sat, Jan 17, 2015 at 5:52 AM, Jacob, Jerin < > > > > jerin.ja...@caviumnetworks.com> wrote: > > > > > > > > > Some odp_packet API queries based on exiting odp packet unit test > case, > > > > > > > > > > 1) In exiting odp packet unit test case, In order to create one > full > > > > > length packet in one segment, > > > > > We have used following formula, > > > > > packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - > > > ODP_CONFIG_PACKET_HEADROOM - > > > > > ODP_CONFIG_PACKET_TAILROOM; > > > > > > > > > > This may not be valid in all platform if the packet segment has > segment > > > > > specific meta data. > > > > > I think, we need to create either new ODP_CONFIG to define the > default > > > > > packet size > > > > > or odp_packet_alloc of len == 0 can be used to create default > packet > > > size. > > > > > > > > > > 2) If buffer is NOT aware of segmentation then > odp_buffer_size(buf) of > > > > > packet should be ODP_CONFIG_PACKET_BUF_LEN_MIN > > > > > instead of odp_buffer_size(buf) == odp_packet_buf_len(pkt)) . > > > > > > > > > > Any thoughts ? > > > > > > > > > > - Jerin > > > > > ___ > > > > > lng-odp mailing list > > > > > lng-odp@lists.linaro.org > > > > >
Re: [lng-odp] odp_packet API queries
On Mon, Jan 19, 2015 at 06:09:34AM -0600, Bill Fischofer wrote: > I think Petri should weigh in on these questions. For the first one, what > problems do you anticipate some platforms having with that equation? I have two issues around the unit test case, 1) packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - ODP_CONFIG_PACKET_HEADROOM - ODP_CONFIG_PACKET_TAILROOM creates two segments in my platform and tailroom/headroom expects to work within a segment ? 2) pool creation with number of buffers as one and creating a segmented buffers as packet_len is more than one segment. > > I think the cleanest solution would be to have the platform segment size > for a given pool accessible as pool metadata, e.g., > odp_pool_seg_size(pool), but the real issue is why does the application > want this information? If an application wants to ensure that packets are > unsegmented then the simplest solution is to re-introduce the notion of > unsegmented pools. If an application creates an unsegmented pool then by > definition any object allocated from that pool will only consist of a > single segment. By contrast, if the application is designed to support > segments then it shouldn't care. IMO, its simple to add a ODP_CONFIG or odp_packet_alloc of len == 0 for default packet size > > On Mon, Jan 19, 2015 at 3:27 AM, Jerin Jacob > wrote: > > > On Sat, Jan 17, 2015 at 09:45:12AM -0600, Bill Fischofer wrote: > > > Application-visible sizes refer to application-visible data. Metadata is > > > always implementation-specific and not included in such counts. Metadata > > > is "off books" data that is associated with the packet but is not part of > > > any addressable packet storage. The advantage of having a packet object > > is > > > that the packet APIs can refer to the packet independent of any > > > implementation and not to how the packet may be represented in storage > > on a > > > particular platform. > > > > But coming back to my question, How an application can create a one segment > > full length packet ? > > Following equation may not be correct in all platforms > > packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - ODP_CONFIG_PACKET_HEADROOM - > > ODP_CONFIG_PACKET_TAILROOM; > > > > > > > > > > Trying to reason about buffers that are used to store packet data is > > > inherently non-portable and should be discouraged. Hopefully the switch > > to > > > events will help move us in that direction since packets are no longer a > > > type of buffer using the new nomenclature. > > > > Should we remove odp_buffer_size(buf) == odp_packet_buf_len(pkt)) test > > case > > or wait for event rework to happen ? > > > > > > > > On Sat, Jan 17, 2015 at 5:52 AM, Jacob, Jerin < > > > jerin.ja...@caviumnetworks.com> wrote: > > > > > > > Some odp_packet API queries based on exiting odp packet unit test case, > > > > > > > > 1) In exiting odp packet unit test case, In order to create one full > > > > length packet in one segment, > > > > We have used following formula, > > > > packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - > > ODP_CONFIG_PACKET_HEADROOM - > > > > ODP_CONFIG_PACKET_TAILROOM; > > > > > > > > This may not be valid in all platform if the packet segment has segment > > > > specific meta data. > > > > I think, we need to create either new ODP_CONFIG to define the default > > > > packet size > > > > or odp_packet_alloc of len == 0 can be used to create default packet > > size. > > > > > > > > 2) If buffer is NOT aware of segmentation then odp_buffer_size(buf) of > > > > packet should be ODP_CONFIG_PACKET_BUF_LEN_MIN > > > > instead of odp_buffer_size(buf) == odp_packet_buf_len(pkt)) . > > > > > > > > Any thoughts ? > > > > > > > > - Jerin > > > > ___ > > > > lng-odp mailing list > > > > lng-odp@lists.linaro.org > > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] odp_packet API queries
I think Petri should weigh in on these questions. For the first one, what problems do you anticipate some platforms having with that equation? I think the cleanest solution would be to have the platform segment size for a given pool accessible as pool metadata, e.g., odp_pool_seg_size(pool), but the real issue is why does the application want this information? If an application wants to ensure that packets are unsegmented then the simplest solution is to re-introduce the notion of unsegmented pools. If an application creates an unsegmented pool then by definition any object allocated from that pool will only consist of a single segment. By contrast, if the application is designed to support segments then it shouldn't care. On Mon, Jan 19, 2015 at 3:27 AM, Jerin Jacob wrote: > On Sat, Jan 17, 2015 at 09:45:12AM -0600, Bill Fischofer wrote: > > Application-visible sizes refer to application-visible data. Metadata is > > always implementation-specific and not included in such counts. Metadata > > is "off books" data that is associated with the packet but is not part of > > any addressable packet storage. The advantage of having a packet object > is > > that the packet APIs can refer to the packet independent of any > > implementation and not to how the packet may be represented in storage > on a > > particular platform. > > But coming back to my question, How an application can create a one segment > full length packet ? > Following equation may not be correct in all platforms > packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - ODP_CONFIG_PACKET_HEADROOM - > ODP_CONFIG_PACKET_TAILROOM; > > > > > > Trying to reason about buffers that are used to store packet data is > > inherently non-portable and should be discouraged. Hopefully the switch > to > > events will help move us in that direction since packets are no longer a > > type of buffer using the new nomenclature. > > Should we remove odp_buffer_size(buf) == odp_packet_buf_len(pkt)) test > case > or wait for event rework to happen ? > > > > > On Sat, Jan 17, 2015 at 5:52 AM, Jacob, Jerin < > > jerin.ja...@caviumnetworks.com> wrote: > > > > > Some odp_packet API queries based on exiting odp packet unit test case, > > > > > > 1) In exiting odp packet unit test case, In order to create one full > > > length packet in one segment, > > > We have used following formula, > > > packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - > ODP_CONFIG_PACKET_HEADROOM - > > > ODP_CONFIG_PACKET_TAILROOM; > > > > > > This may not be valid in all platform if the packet segment has segment > > > specific meta data. > > > I think, we need to create either new ODP_CONFIG to define the default > > > packet size > > > or odp_packet_alloc of len == 0 can be used to create default packet > size. > > > > > > 2) If buffer is NOT aware of segmentation then odp_buffer_size(buf) of > > > packet should be ODP_CONFIG_PACKET_BUF_LEN_MIN > > > instead of odp_buffer_size(buf) == odp_packet_buf_len(pkt)) . > > > > > > Any thoughts ? > > > > > > - Jerin > > > ___ > > > lng-odp mailing list > > > lng-odp@lists.linaro.org > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] odp_packet API queries
On Sat, Jan 17, 2015 at 09:45:12AM -0600, Bill Fischofer wrote: > Application-visible sizes refer to application-visible data. Metadata is > always implementation-specific and not included in such counts. Metadata > is "off books" data that is associated with the packet but is not part of > any addressable packet storage. The advantage of having a packet object is > that the packet APIs can refer to the packet independent of any > implementation and not to how the packet may be represented in storage on a > particular platform. But coming back to my question, How an application can create a one segment full length packet ? Following equation may not be correct in all platforms packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - ODP_CONFIG_PACKET_HEADROOM - ODP_CONFIG_PACKET_TAILROOM; > > Trying to reason about buffers that are used to store packet data is > inherently non-portable and should be discouraged. Hopefully the switch to > events will help move us in that direction since packets are no longer a > type of buffer using the new nomenclature. Should we remove odp_buffer_size(buf) == odp_packet_buf_len(pkt)) test case or wait for event rework to happen ? > > On Sat, Jan 17, 2015 at 5:52 AM, Jacob, Jerin < > jerin.ja...@caviumnetworks.com> wrote: > > > Some odp_packet API queries based on exiting odp packet unit test case, > > > > 1) In exiting odp packet unit test case, In order to create one full > > length packet in one segment, > > We have used following formula, > > packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - ODP_CONFIG_PACKET_HEADROOM - > > ODP_CONFIG_PACKET_TAILROOM; > > > > This may not be valid in all platform if the packet segment has segment > > specific meta data. > > I think, we need to create either new ODP_CONFIG to define the default > > packet size > > or odp_packet_alloc of len == 0 can be used to create default packet size. > > > > 2) If buffer is NOT aware of segmentation then odp_buffer_size(buf) of > > packet should be ODP_CONFIG_PACKET_BUF_LEN_MIN > > instead of odp_buffer_size(buf) == odp_packet_buf_len(pkt)) . > > > > Any thoughts ? > > > > - Jerin > > ___ > > lng-odp mailing list > > lng-odp@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/lng-odp > > ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
Re: [lng-odp] odp_packet API queries
Application-visible sizes refer to application-visible data. Metadata is always implementation-specific and not included in such counts. Metadata is "off books" data that is associated with the packet but is not part of any addressable packet storage. The advantage of having a packet object is that the packet APIs can refer to the packet independent of any implementation and not to how the packet may be represented in storage on a particular platform. Trying to reason about buffers that are used to store packet data is inherently non-portable and should be discouraged. Hopefully the switch to events will help move us in that direction since packets are no longer a type of buffer using the new nomenclature. On Sat, Jan 17, 2015 at 5:52 AM, Jacob, Jerin < jerin.ja...@caviumnetworks.com> wrote: > Some odp_packet API queries based on exiting odp packet unit test case, > > 1) In exiting odp packet unit test case, In order to create one full > length packet in one segment, > We have used following formula, > packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - ODP_CONFIG_PACKET_HEADROOM - > ODP_CONFIG_PACKET_TAILROOM; > > This may not be valid in all platform if the packet segment has segment > specific meta data. > I think, we need to create either new ODP_CONFIG to define the default > packet size > or odp_packet_alloc of len == 0 can be used to create default packet size. > > 2) If buffer is NOT aware of segmentation then odp_buffer_size(buf) of > packet should be ODP_CONFIG_PACKET_BUF_LEN_MIN > instead of odp_buffer_size(buf) == odp_packet_buf_len(pkt)) . > > Any thoughts ? > > - Jerin > ___ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp > ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
[lng-odp] odp_packet API queries
Some odp_packet API queries based on exiting odp packet unit test case, 1) In exiting odp packet unit test case, In order to create one full length packet in one segment, We have used following formula, packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - ODP_CONFIG_PACKET_HEADROOM - ODP_CONFIG_PACKET_TAILROOM; This may not be valid in all platform if the packet segment has segment specific meta data. I think, we need to create either new ODP_CONFIG to define the default packet size or odp_packet_alloc of len == 0 can be used to create default packet size. 2) If buffer is NOT aware of segmentation then odp_buffer_size(buf) of packet should be ODP_CONFIG_PACKET_BUF_LEN_MIN instead of odp_buffer_size(buf) == odp_packet_buf_len(pkt)) . Any thoughts ? - Jerin ___ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
