In the current API the odp_packet_alloc() function always takes "len" as input parameter and hence it is not required to support any default size.
In case of odp_buffer_alloc() the default value of allocation will be equal to the "size" parameter which will be the value given during odp_pool_create() function as part of odp_pool_params_t variable. If this value is given as "0" then the HW will chose the default segment size supported by the HW. This value will be the value of the segment with which the pools are getting created by default in the HW. Regards, Bala On 26 May 2015 at 16:25, Zoltan Kiss <[email protected]> wrote: > Which value? I've mentioned seg_len and seg_size, but the latter actually > doesn't exist. I guess I meant 'len'. The trouble with them, that you can > set both of them to 0 to ask for the default, so even if you look up the > params with odp_pool_info(), you can end up with both values 0. > So how do you figure out what length should be used by odp_buffer_alloc? > With the current API definition it will probably end up using pkt.len, just > by accident. > And the same applies to odp_packet_alloc, although I think it's also a bug > that when the user requested a 0 length buffer (plus headroom and tailroom), > it gets one with the default values. > > Zoli > > On 23/05/15 03:00, Bill Fischofer wrote: >> >> In linux-generic that value represents the default allocation length. >> >> On Friday, May 22, 2015, Zoltan Kiss <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi, >> >> While fixing up things in the DPDK implementation I've found that >> linux-generic might have some troubles too. odp_buffer_alloc() and >> odp_packet_alloc() uses >> odp_pool_to_entry(pool_hdl)->s.params.buf.size, but if it's a packet >> pool (which is always true in case of odp_packet_alloc(), and might >> be true with odp_buffer_alloc()). >> My first idea would be to use s.params.pkt.seg_len in that case, but >> it might be 0. Maybe s.seg_size would be the right value? >> If anyone has time to come up with a patch to fix this, feel free, I >> probably won't have time to work on this in the near future. >> >> Zoli >> _______________________________________________ >> lng-odp mailing list >> [email protected] >> https://lists.linaro.org/mailman/listinfo/lng-odp >> > _______________________________________________ > lng-odp mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/lng-odp _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
