Hi, I would propose to remove this odp_packet_unshared_length(), from an implementation point of view this API will require additional software overhead as this feature is not inherently supported in the HW and there are concerns when creating multiple references. If we do not foresee any serious application use-case we should remove this API.
Regards, Bala On 5 October 2017 at 09:27, Bill Fischofer <[email protected]> wrote: > The intent behind odp_packet_unshared_len() is not to provide complete > accuracy but rather to let an application know areas that are known to be > safe to update, so it can be maintained conservatively. > > While an application may know precisely what it is doing (at least > initially) the issue is what about libraries like OFP? When they are passed > an odp_packet_t they likely have no idea whether they've been passed a > reference or a "normal" packet. odp_packet_has_ref() answers that question > at a high level, but doesn't say anything about what's OK to modify. > odp_packet_unshared_len() is designed to provide a simple answer to that > question in such cases. It's OK if that's a lower-bound, as long as it's > guaranteed that the data length returned is indeed unshared. > > So in the case of multi-refs you may get an answer that's lower than it > theoretically should be, but that's of lesser importance. And of course if > future implementations can handle more sophisticated use cases more > efficiently then they are free to do so. > > I'd be interested in hearing from Bala and Nikhil on this point. > > On Thu, Oct 5, 2017 at 8:36 AM, Savolainen, Petri (Nokia - FI/Espoo) < > [email protected]> wrote: > >> Hi, >> >> I propose that we'd remove the odp_packet_unshared_len() call. >> >> The rationale is: >> * Application rarely needs this to be maintained by ODP (never ?) >> * Application may maintain offsets/lengths e.g. in packet user area >> * Application may utilize knowledge about the context: >> e.g. in this pipeline stage all UDP payload is multi-referenced, etc >> * It's not practical for ODP to maintain accurate byte counts when >> multiple references point into to the same packet (or reference of it) in >> different locations. Accurate book keeping would require that >> packet_free(ref) would update unshared_len on other references as well. >> >> For example, three references to a packet. >> >> ref1 ref2 ref3 >> | | | >> v v v >> +--------------------+ >> | | B | A | >> +--------------------+ >> >> For ref1, unshared_len is "packet_len - (A + B)". When ref2 is freed, >> unshared_len of ref1 should change to "packet_len - A". Additional book >> keeping and synchronization would be needed just for that to happen. A HW >> based pool would not do such update either. Currently, I leave it unchanged >> until all references are freed. >> >> It's easy to imagine more complex examples using references of references, >> or race conditions. E.g. during free of ref2, another thread creates new >> reference between ref1 and ref2, so unshared_len of ref1 should be updated >> to "packet_len - (A + C)", instead of "packet_len - A". >> >> >> -Petri >> >>
